I want an epsilon that doesn't confuse newbies and which also is efficient. epsilon=1/2**(mantissa bits-1) fits the bill.
Why I want this- It would be great to have numbers survive round-trip conversions, when feasible. Specifically I have no need to compare Rats and Nums for equality, but I do often deal with "flat" text files full of metrics, and remotely sourced json, and XML. The data types are sometimes unexpected. -y On Wed, Mar 7, 2018 at 5:16 PM, Solomon Foster <colo...@gmail.com> wrote: > 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 > 100000000000000001590289110975991804683608085639452813897813 > 27557747838772170381060813469985856815104). 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 ( > 100000000000000001590289110975991804683608085639452813897813 > 27557747838772170381060813469985856815104 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 >
