Subject: Re: Rounding numbers from copy expert
To: John Abraham <jea@hbaspecto.com>
Cc: psycopg@postgresql.org
References: <8DC745DF-DDF9-4697-BAAF-23ABE78A1EB9@hbaspecto.com>
 <fb01e8ae-597d-5ccf-f71f-75dd4e00e338@aklaver.com>
 <046E2360-462C-4B55-8034-160E4612E493@hbaspecto.com>
From: Adrian Klaver <adrian.klaver@aklaver.com>
Message-ID: <07979616-0e6d-411f-9cb4-5c7b9fd8c1bf@aklaver.com>
Date: Wed, 24 Jul 2019 17:48:44 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.7.2
MIME-Version: 1.0
In-Reply-To: <046E2360-462C-4B55-8034-160E4612E493@hbaspecto.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 7/24/19 5:35 PM, John Abraham wrote:
> 
>> On Jul 24, 2019, at 4:33 PM, Adrian Klaver <adrian.klaver@aklaver.com> wrote:
>>
>>> On 7/24/19 4:28 PM, John Abraham wrote:
>>> Hmm, I have two machines connecting to the same database running the same query inside copy_expert.
>>> Both seem to have psycopg2 2.7.5 (based on pip3 freeze).
>>> One seems to be rounding the double precision number 696538951.985381 to 6.96538944E8 whereas the other machine isn't rounding it.
>>
>> First:
>>
>> https://www.postgresql.org/docs/11/datatype-numeric.html#DATATYPE-FLOAT
>>
>> 8.1.3. Floating-Point Types
>> "The data types real and double precision are inexact, variable-precision numeric types. ...
>>
>> Inexact means that some values cannot be converted exactly to the internal format and are stored as approximations, so that storing and retrieving a value might show slight discrepancies. Managing these errors and how they propagate through calculations is the subject of an entire branch of mathematics and computer science and will not be discussed here, except for the following points: ..."
> 
> 
> One of my proudest moments in my very first job in the late 80s was solving in just a few minutes a lack-of-precision problem my boss was fighting with for more than a day because he was subtracting two similar floating point numbers. I’m enjoying the irony of fighting a similar problem now, myself, 30 years later.
> 
> Anyway, in this case it’s not the precision, it’s the repeatability.  If you run the same program twice on two computers with the same software, you *should* get *exactly* the same answer.
> 
>>
>> Second:
>>
>> Where are you actually 'looking' at the values?
> 
> I’m seeing the difference in a .CSV file produced by copy_expert, which as far as I can tell just streams the stdout from a database ‘copy to stdout’ command to a text file. I’m trying to figure out why the ‘copy to stdout’ SQL command would give different interpretations of a number.

Not sure that it makes a difference, but in your OP you said you where 
doing:

"... why copy_expert (which basically does a 'copy to stdin' query) ..."

So how similar/dissimilar are the two computers you are doing this on?:

1) OS and version?

2) Machine architecture?

3) Python version and build?

> 
>>
>>
>>> This is causing auditability/repeatability problems, as the difference is actually significant in this context.
>>> Is there some thing about the way psycopg2 connects to the database, or the way psycopg2 is configured, that could be causing this rounding? Is there some way to express a preference for scientific notation?
>>> I'm at a complete loss as to why copy_expert (which basically does a 'copy to stdin' query) would be different when called from different machines. My next step in the madness is to see if the locale has an effect, one is set to en_CA.UTF-8 and the other is set to en_US.UTF-8.   But, perhaps someone else has a better idea.
>>> Thanks for any help.
>>> --
>>> John Abraham
>>> jea@hbaspecto.com <mailto:jea@hbaspecto.com>
>>> 403-232-1060
>>
>>
>> -- 
>> Adrian Klaver
>> adrian.klaver@aklaver.com
> 
> 
> —
> John Abraham
> 


-- 
Adrian Klaver
adrian.klaver@aklaver.com