SV: [DGD] Float precision loss

[Troels Therkelsen]

> > I have run into a behaviour that looks very much like a bug to
> me.  I am
> > running DGD 1.2.96 and just wanted to hear if there is a known
> fix to this
> > in later released versions?
> >
> > This is what I get:
> >
> > <> eval 4.3 + 5.0 - 4.3 - 5.0
> > $6 = 5.8207661e-11
>
> This has already been answered, but notice the difference with
>
>     (4.3 + 5.0) - (4.3 + 5.0)
>
> There is usually a way to reorganize the expression to get the result
> (closer to what) you want.
>
> In some cases, DGD masks underlying representation problems.  For example,
> try evaluating
>
>     1.1
>
> in LPC and in Python.

A bit of an OT, but Python distinguishes between "representation" and
"output".
In this manner, yes, if you type 1.1 at the interactive Python prompt you
will
get 1.100<etc>001, because the interactive interpreter wraps that in repr()
for
you.  If you decide to output the value, eg. with a print (which will do an
implicit str() on the value) you will get the 'expected' result, namely 1.1
(at least Python has done this for a while, can't remember at which Python
version str() began to do precision rounding).

(And yes, this is a frequent question on the Python newsgroup, too ;-)

/Troels Therkelsen