[CentralOH] Better Problem Description.

Tue Dec 10 17:16:26 CET 2013

Almost, pertneer, just a little tweeking.

I think it should read

if last _digit <3                # this takes care of a 1 or 2
    last_digit=0
elif last_digit >7              # this takes care of an 8 or 9
    last_digit = 0
    next_last _digit +=1
else last_digit_<8          # this takes care of everything else
    last_digit + 5

I think the "everything else" should be last and also if last digit is
already 0, don't mess with it.

I guess if you put it in simple terms, it's easy to understand.  Thanks
much!!! lou

On Tue, Dec 10, 2013 at 10:31 AM, Joe Shaw <joe at joeshaw.org> wrote:

> 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
> >
> _______________________________________________
> CentralOH mailing list
> CentralOH at python.org
> https://mail.python.org/mailman/listinfo/centraloh
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/centraloh/attachments/20131210/2c70980a/attachment.html>