[CentralOH] Better Problem Description.

Louis Bogdan looiebwv at gmail.com
Tue Dec 10 16:31:49 CET 2013


Oops:
The third paragraph should read:
In like manner, IF THE RIGHT HAND DIGIT IS <3,


On Tue, Dec 10, 2013 at 10:24 AM, Louis Bogdan <looiebwv at gmail.com> wrote:

> It seems that I'm having a problem in getting my point across as to what I
> would like to do, so let's try another approach.
>
> I have a number, 1.2348 and it is of no consequence or interest where it
> came from, etc.  I would like to manipulate the right hand most digit so
> that if it is greater that 7, I would increment it by 2 to 0 and end up
> with the number being either 1.2350 or 1.2351.
>
> In like manner I would just change the right hand most digit to 0 as this
> would have no effect on any other digits, I would end up with the number
> being 1.2340.
>
> Now if the right hand digit was not greater than 7 nor less than 3, it
> fall into the range of 3-8 and digits 3, 4, 5 ,6 &7 I change to digit 5
>
> The end result of the above I will have a number whose right hand digit
> will be either  0 or 5.  And here again, what happens next is of no
> consequence or interest to anyone but me.  But to satisfy some people's
> curiosity, the above number was derived from a keypad input, two integer
> four decimal, and manipulated by an internal equation.  The finally derived
> number will then manipulated into an integer which will the number of steps
> required to make a linear movement equal to the above number of inches.
>
> NOW!! HOW DO I SAY THAT IN PYTHON?
>
>
>
>
> On Tue, Dec 10, 2013 at 8:22 AM, Neil Ludban <nludban at columbus.rr.com>wrote:
>
>> On Mon, 9 Dec 2013 18:59:01 -0500
>> Louis Bogdan <looiebwv at gmail.com> wrote:
>> ...
>> > > On Mon, Dec 9, 2013 at 12:56 PM, Louis Bogdan <looiebwv at gmail.com>
>> wrote:
>> > >> Now I know that Python does rounding which I don't understand and
>> have
>> > >> not found any decent, understandable explanation how it does it.  I
>> > >> understand rounding, even way back when I was proficient with the
>> abacus.
>>
>> It's really quantization errors, not rounding.  If binary integers
>> are expressed as a sum of numbers from the set {1, 2, 4, 8, 16, ...}
>> then binary floating point numbers (from a very simplistic viewpoint)
>> add to that set the fractions {1/2, 1/4, 1/8, 1/16, ...}.  64-bit
>> doubles (the typical Python "float" type) enables 53 consecutive
>> values from that combined set:
>>
>> http://en.wikipedia.org/wiki/Double_precision_floating-point_format
>>
>> So numbers like 1, 1+1/2, 1+1/4, 1+1/8, can be represented exactly
>> in decimal and binary (the minus sign is added here to force the
>> bin function to output all 64 bits):
>>
>> --> import struct
>> --> bin(struct.unpack('Q', struct.pack('d', float('-1.0000')))[0])
>> '0b1011111111110000000000000000000000000000000000000000000000000000'
>> --> bin(struct.unpack('Q', struct.pack('d', float('-1.5000')))[0])
>> '0b1011111111111000000000000000000000000000000000000000000000000000'
>> --> bin(struct.unpack('Q', struct.pack('d', float('-1.2500')))[0])
>> '0b1011111111110100000000000000000000000000000000000000000000000000'
>> --> bin(struct.unpack('Q', struct.pack('d', float('-1.1250')))[0])
>> '0b1011111111110010000000000000000000000000000000000000000000000000'
>>
>>
>> 1+1/10 works in decimal, but is a repeating pattern in binary:
>> --> bin(struct.unpack('Q', struct.pack('d', float('-1.1000')))[0])
>> '0b1011111111110001100110011001100110011001100110011001100110011010'
>>
>>
>> 1+1/3 repeats in both decimal and binary:
>> --> -4/3.
>> -1.3333333333333333
>> --> bin(struct.unpack('Q', struct.pack('d', float(-4/3.)))[0])
>> '0b1011111111110101010101010101010101010101010101010101010101010101'
>>
>>
>> And then there's the weird stuff that may concern you:
>>
>> --> bin(struct.unpack('Q', struct.pack('d', float(-4/3. * 1000 /
>> 1000)))[0])
>> '0b1011111111110101010101010101010101010101010101010101010101010101'
>> --> bin(struct.unpack('Q', struct.pack('d', float(-4/3. + 1000 -
>> 1000)))[0])
>> '0b1011111111110101010101010101010101010101010101010101011000000000'
>> --> -4/3. + 1000 - 1000
>> -1.3333333333333712
>>
>> The result of the last example can vary depending on the compiler
>> and optimization flags, whether the code runs on the main FPU or
>> vector coprocessor (eg, MMX), level of IEEE-754 compliance (which
>> varies from none for early Crays to partly for early NVIDIA GPUs to
>> full for most modern desktops), and any non-standard options (eg,
>> rounding mode and denormal truncation) which other parts of your
>> application or supporting libraries may have set...
>>
>>
>> Hope that helps.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/centraloh/attachments/20131210/81d7cac8/attachment.html>


More information about the CentralOH mailing list