[CentralOH] Plucking Digits From Float

[Brian Costlow]

The (very few) hobby things I have done return ints of some type from the
hardware, but it's not something I'm terribly familiar with.

And that was an off-the-top-of-my-head starting point. There's a couple
issues with my code, including an unnecessary str conversion and not
setting the context correctly.


On Mon, Dec 9, 2013 at 10:35 AM, Joe Shaw <joe at joeshaw.org> wrote:

> Hi,
>
> Yep, good call.  I wasn't familiar with the Decimal library and hadn't
> caught up to your other message on the thread. It definitely looks
> like it'll fit the bill.
>
> I would be a bit surprised if the hardware returned floats... most
> small embedded components don't have FPUs or IEEE-754 implementations.
>  (And for things like medical devices, they'd more likely use some
> fixed point implementation to avoid these kinds of rounding errors.)
>
> Joe
>
> 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/e68b5b66/attachment.html>