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 10000000000000000159028911097599180468360808563945281389781327557747838772170381060813469985856815104). 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 (10000000000000000159028911097599180468360808563945281389781327557747838772170381060813469985856815104 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