[CentralOH] Plucking Digits From Float

[Brian Costlow]

If you are doing string manipulation, this is where it gets tricky, and
where we are unclear what you are trying to do.

If input is 1.2346 the output is 1.2345 (from your examples)

But if the input is 12346.0, what is your expected output? Based on the
0.0005 step, I would expect it stays 12346.0

But wait, if we get 1234.6 what do we do? If we are just manipulating the
last 2 digits of a string, we end up with 1234.5

Which of those would be correct? What if it's 1234.60 in the string, which
is the same numeric value as 1234.6.

To avoid those issues, you need a bunch more string manipulation. This is
why we are asking you to step back and give a high level description of the
problem without being fixated on your algorithm.




On Mon, Dec 9, 2013 at 10:32 AM, Louis Bogdan <looiebwv at gmail.com> wrote:

> If my number 1.2346 was 12346.0, could I still do what I do in my proposed
> function?  What I would be doing is multiplying everything by 10000 to
> convert to integers. The end result would still be tbe same.   lou
>
>
> On Mon, Dec 9, 2013 at 10:21 AM, Brian Costlow <brian.costlow at gmail.com>wrote:
>
>> There is an existing Decimal library in the standard library, which can
>> be used for a lot of this kind of work. It's designed to avoid these kind
>> of issues (mostly).
>>
>> http://docs.python.org/2/library/decimal.html
>>
>> Although since he is working with hardware, if the boundary can only pass
>> floats into Python, he still will have potential issues. But using Decimal
>> you can actually trap instances of inexact conversion and deal with them,
>> instead of having them sneak by.
>>
>>
>>
>>
>>
>>
>> On Mon, Dec 9, 2013 at 9:57 AM, Joe Shaw <joe at joeshaw.org> wrote:
>>
>>> Hi,
>>>
>>> It's worth pointing out also that floating point values are an
>>> approximation.  This is one reason why you should never do direct
>>> comparisons with floating point numbers, but it could also bite you
>>> here.  It's possible that 1.2346 (or any value you choose) cannot be
>>> precisely represented as you wish, and so converting it to a string
>>> and taking the negative index might be very, very wrong.
>>>
>>> 0.1 is one such number, and it can be demonstrated in python on some
>>> platforms.  Go into the Python REPL and type "0.1" and you might get
>>> "0.10000000000000001" back.
>>>
>>> If this is really important you can store your values as integers --
>>> which are exactly precise -- and handle the decimals yourself.  (In
>>> other words, your own implemention of fixed point values.)
>>>
>>> Joe
>>>
>>> On Sun, Dec 8, 2013 at 2:40 PM,  <jep200404 at columbus.rr.com> wrote:
>>> > On Sun, 8 Dec 2013 14:36:01 -0500, Louis Bogdan <looiebwv at gmail.com>
>>> wrote:
>>> >
>>> >> num is calculated value 1.2346
>>> >> a=num(-1) is indicating the numeral "6" with negative indexing
>>> notation.
>>> >> b=num(-2) is indicating the numeral "4"   "         "
>>> >
>>> > I question the sanity of do so. Nonetheless.
>>> >
>>> > num = 1.2346
>>> > a = str(num)[-1]
>>> > b = str(num)[-2]
>>> >
>>> > print num, a, b
>>> >
>>> > _______________________________________________
>>> > 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
>>>
>>
>>
>> _______________________________________________
>> 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/20131209/8582834f/attachment-0001.html>