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?
> > pi.Str.Num == pi # Does Num survive string round-trip? - Nothing to do
> with epsilon
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
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