On Sun, Mar 4, 2018 at 8:49 AM, yary <not....@gmail.com> wrote:

> In that spirit, I'd expect numeric comparison in general, and epsilon
> specifically, to be set so these return True:
> > pi == pi.Rat # Does Num to Rat conversion keep its precision?
> False
> > pi.Str.Num == pi # Does Num survive string round-trip? - Nothing to do
> with epsilon
> False
Why on earth would you want to do this?

I mean that quite literally.  The only reason I can see for directly
comparing a Num and a Rat for equality is to check and see if the Rat has
the same precision as the Num.  In practice, it's well-known you generally
shouldn't use equality tests on floating point numbers.  Converting one
side of the equation to a Rat just makes it make even less sense.

I've just been playing around with Num to Rat conversion, and here are some
quick notes.

1) You can pass 0 as the epsilon for the Rat constructor, which seems to be
equivalent to very very small values of epsilon.

2)  pi.Rat(0) + exp(1).Rat(0) is a Rat, but pi.Rat(0) + exp(1).Rat(0) +
sin(.2).Rat(0) is a Num.  (On the other hand, pi.Rat() + exp(1).Rat() +
sin(.2).Rat() is still a Rat.)

3) Remember (I had forgotten!) that Nums can represent numbers much smaller
than a Rat can.  1e-100 is a perfectly reasonable Num, but (were Rat
behaving properly) the closest possible Rat value is 0.

4) That said, if you actually do (1e-100).Rat(0), it gives you (1
Needless to say, that's not actually a legal Rat.  Surprisingly (to me,
anyway) it is accurate to better than 1e-110.

5) Somewhat more distressingly, (1e+100).Rat gives you
1).  That's only accurate to 10**83.  Which is to say, it's as accurate as
a double gets -- 16-17 digits.   (BTW, that is a legal Rat.)

I admit don't really know what to do with this.

Solomon Foster: colo...@gmail.com
HarmonyWare, Inc: http://www.harmonyware.com

Reply via email to