<div dir="ltr"><div><div><div><div><div><div><div><div>Almost, pertneer, just a little tweeking.  <br><br></div>I think it should read<br><br></div><div>if last _digit <3                # this takes care of a 1 or 2<br>
</div><div>    last_digit=0<br></div>elif last_digit >7              # this takes care of an 8 or 9<br></div>    last_digit = 0<br></div>    next_last _digit +=1<br></div>else last_digit_<8          # this takes care of everything else<br>
</div>    last_digit + 5<br>                                      <br></div>I think the "everything else" should be last and also if last digit is already 0, don't mess with it. <br><br></div>I guess if you put it in simple terms, it's easy to understand.  Thanks much!!! lou<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Dec 10, 2013 at 10:31 AM, Joe Shaw <span dir="ltr"><<a href="mailto:joe@joeshaw.org" target="_blank">joe@joeshaw.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
To put it into pseudocode:<br>
<br>
if last_digit < 3:<br>
    last_digit = 0<br>
elif last_digit < 8:<br>
    last_digit = 5<br>
else:<br>
    last_digit = 0<br>
    next_to_last_digit += 1<br>
<br>
Is that correct?<br>
<div class="im"><br>
On Tue, Dec 10, 2013 at 10:24 AM, Louis Bogdan <<a href="mailto:looiebwv@gmail.com">looiebwv@gmail.com</a>> wrote:<br>
</div><div><div class="h5">> It seems that I'm having a problem in getting my point across as to what I<br>
> would like to do, so let's try another approach.<br>
><br>
> I have a number, 1.2348 and it is of no consequence or interest where it<br>
> came from, etc.  I would like to manipulate the right hand most digit so<br>
> that if it is greater that 7, I would increment it by 2 to 0 and end up with<br>
> the number being either 1.2350 or 1.2351.<br>
><br>
> In like manner I would just change the right hand most digit to 0 as this<br>
> would have no effect on any other digits, I would end up with the number<br>
> being 1.2340.<br>
><br>
> Now if the right hand digit was not greater than 7 nor less than 3, it fall<br>
> into the range of 3-8 and digits 3, 4, 5 ,6 &7 I change to digit 5<br>
><br>
> The end result of the above I will have a number whose right hand digit will<br>
> be either  0 or 5.  And here again, what happens next is of no consequence<br>
> or interest to anyone but me.  But to satisfy some people's curiosity, the<br>
> above number was derived from a keypad input, two integer four decimal, and<br>
> manipulated by an internal equation.  The finally derived number will then<br>
> manipulated into an integer which will the number of steps required to make<br>
> a linear movement equal to the above number of inches.<br>
><br>
> NOW!! HOW DO I SAY THAT IN PYTHON?<br>
><br>
><br>
><br>
><br>
> On Tue, Dec 10, 2013 at 8:22 AM, Neil Ludban <<a href="mailto:nludban@columbus.rr.com">nludban@columbus.rr.com</a>><br>
> wrote:<br>
>><br>
>> On Mon, 9 Dec 2013 18:59:01 -0500<br>
>> Louis Bogdan <<a href="mailto:looiebwv@gmail.com">looiebwv@gmail.com</a>> wrote:<br>
>> ...<br>
>> > > On Mon, Dec 9, 2013 at 12:56 PM, Louis Bogdan <<a href="mailto:looiebwv@gmail.com">looiebwv@gmail.com</a>><br>
>> > > wrote:<br>
>> > >> Now I know that Python does rounding which I don't understand and<br>
>> > >> have<br>
>> > >> not found any decent, understandable explanation how it does it.  I<br>
>> > >> understand rounding, even way back when I was proficient with the<br>
>> > >> abacus.<br>
>><br>
>> It's really quantization errors, not rounding.  If binary integers<br>
>> are expressed as a sum of numbers from the set {1, 2, 4, 8, 16, ...}<br>
>> then binary floating point numbers (from a very simplistic viewpoint)<br>
>> add to that set the fractions {1/2, 1/4, 1/8, 1/16, ...}.  64-bit<br>
>> doubles (the typical Python "float" type) enables 53 consecutive<br>
>> values from that combined set:<br>
>><br>
>> <a href="http://en.wikipedia.org/wiki/Double_precision_floating-point_format" target="_blank">http://en.wikipedia.org/wiki/Double_precision_floating-point_format</a><br>
>><br>
>> So numbers like 1, 1+1/2, 1+1/4, 1+1/8, can be represented exactly<br>
>> in decimal and binary (the minus sign is added here to force the<br>
>> bin function to output all 64 bits):<br>
>><br>
>> --> import struct<br>
>> --> bin(struct.unpack('Q', struct.pack('d', float('-1.0000')))[0])<br>
>> '0b1011111111110000000000000000000000000000000000000000000000000000'<br>
>> --> bin(struct.unpack('Q', struct.pack('d', float('-1.5000')))[0])<br>
>> '0b1011111111111000000000000000000000000000000000000000000000000000'<br>
>> --> bin(struct.unpack('Q', struct.pack('d', float('-1.2500')))[0])<br>
>> '0b1011111111110100000000000000000000000000000000000000000000000000'<br>
>> --> bin(struct.unpack('Q', struct.pack('d', float('-1.1250')))[0])<br>
>> '0b1011111111110010000000000000000000000000000000000000000000000000'<br>
>><br>
>><br>
>> 1+1/10 works in decimal, but is a repeating pattern in binary:<br>
>> --> bin(struct.unpack('Q', struct.pack('d', float('-1.1000')))[0])<br>
>> '0b1011111111110001100110011001100110011001100110011001100110011010'<br>
>><br>
>><br>
>> 1+1/3 repeats in both decimal and binary:<br>
>> --> -4/3.<br>
>> -1.3333333333333333<br>
>> --> bin(struct.unpack('Q', struct.pack('d', float(-4/3.)))[0])<br>
>> '0b1011111111110101010101010101010101010101010101010101010101010101'<br>
>><br>
>><br>
>> And then there's the weird stuff that may concern you:<br>
>><br>
>> --> bin(struct.unpack('Q', struct.pack('d', float(-4/3. * 1000 /<br>
>> 1000)))[0])<br>
>> '0b1011111111110101010101010101010101010101010101010101010101010101'<br>
>> --> bin(struct.unpack('Q', struct.pack('d', float(-4/3. + 1000 -<br>
>> 1000)))[0])<br>
>> '0b1011111111110101010101010101010101010101010101010101011000000000'<br>
>> --> -4/3. + 1000 - 1000<br>
>> -1.3333333333333712<br>
>><br>
>> The result of the last example can vary depending on the compiler<br>
>> and optimization flags, whether the code runs on the main FPU or<br>
>> vector coprocessor (eg, MMX), level of IEEE-754 compliance (which<br>
>> varies from none for early Crays to partly for early NVIDIA GPUs to<br>
>> full for most modern desktops), and any non-standard options (eg,<br>
>> rounding mode and denormal truncation) which other parts of your<br>
>> application or supporting libraries may have set...<br>
>><br>
>><br>
>> Hope that helps.<br>
><br>
><br>
><br>
</div></div>> _______________________________________________<br>
> CentralOH mailing list<br>
> <a href="mailto:CentralOH@python.org">CentralOH@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/centraloh" target="_blank">https://mail.python.org/mailman/listinfo/centraloh</a><br>
><br>
_______________________________________________<br>
CentralOH mailing list<br>
<a href="mailto:CentralOH@python.org">CentralOH@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/centraloh" target="_blank">https://mail.python.org/mailman/listinfo/centraloh</a><br>
</blockquote></div><br></div>