# [CentralOH] Better Problem Description.

Joe Shaw joe at joeshaw.org
Tue Dec 10 16:31:48 CET 2013

```Hi,

To put it into pseudocode:

if last_digit < 3:
last_digit = 0
elif last_digit < 8:
last_digit = 5
else:
last_digit = 0
next_to_last_digit += 1

Is that correct?

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.
>
>
>
> _______________________________________________
> CentralOH mailing list
> CentralOH at python.org
> https://mail.python.org/mailman/listinfo/centraloh
>
```