On May 31, 2:56 pm, Henryk Trappmann <[EMAIL PROTECTED]> wrote: > On May 31, 10:55 pm, Carl Witty <[EMAIL PROTECTED]> wrote: > > IMHO, giving a+b the precision of the less-precise operand is better > > than using the more-precise operand, because the latter has too much > > chance of confusing people who don't understand floating point. For > > instance, if 1.3+RealField(500)(pi) gave a 500-bit number, I'll bet a > > lot of people would assume that this number matched 13/10+pi to almost > > 500 bits. > > Hm, yes, but this binary decimal conversion is another topic, I mean > nobody would assume that 0.3333333 coerced to 500 *decimal* digits > matches 1/3 to 500 digits? I anyway wondered why one can not specify a > base in RealField, or did I merely overlook the opportunity?
Oh, that would be very cool! Probably the basic reason is that RealField is based on MPFR, and MPFR operates in binary. Also, specifying a base, and doing it "right" (so that floating-point results were correctly rounded to values of the specified number of digits in that base) would probably be much slower in non-power-of-2 bases (at least I can't think how to do the basic operations as quickly as in binary). > > Of course, maybe there are other choices that are better than either > > of these. We could throw away RealField and always use > > RealIntervalField instead; but that's slower, has less special > > functions implemented, and has counterintuitive semantics for > > comparisons. We could do pseudo-interval arithmetic, and say that > > 1e6+R2(3) should be a 20-bit number, because we know about 20 bits of > > the answer; but to be consistent, we should do similar psuedo-interval > > arithmetic even if both operands are the same precision, > > At least RR would then be a ring ;) Well, I just made up this pseudo-interval arithmetic, so I'm not sure what the exact rules might be, but the rules I was envisioning would not suffice to make RR a ring. > > and then RR > > becomes less useful for people who do understand how floating point > > works and want to take advantage of it. > > Ya, I dont want to change floating point, it just seems somewhat > arbitrary to me to coerce down precision, while coercing up precision > with integers. Of course if you consider integer with precision > infinity (as indeed there are no rounding errors and it is an exact > ring) then this makes sense again. Here's another way to see that this might be the right thing to do. Consider the sum of the power series (1 + O(x^5)) and (1 + O(x^6)). Clearly, the sum should be (2 + O(x^5)), not (2+ O(x^6)) -- that is, we are effectively "rounding" (1 + O(x^6)) to (1 + O(x^5)) before we perform the addition. > But if so then I want to have something like SymbolicNumber which is > the subset of SymbolicRing that does not contain variables. And that > this SymbolicNumber is coerced automatically down when used with > RealField. That would be nice, but as Gary points out, it would be difficult to make Sage work like this. Carl --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
