Dirk wrote: > > > On Sep 9, 2:42 pm, Jason Grout <jason-s...@creativetrax.com> wrote: >> Dirk wrote: >>> I do not understand the behaviour below. >>> sage: x=RIF(3+10/71,3+1/7) >>> sage: x >>> 3.15? >>> sage: x.str(style='brackets') >>> '[3.1408450704225350 .. 3.1428571428571433]' >>> Both endpoints start with 3.14, both endpoints round to 3.14. >>> Surely the display should rather be '3.14?'. >> Have you read the documentation for this? > Actually, I did so, yes. I was particularly impressed by the example > sage: pi_appr.str(style='brackets') > '[3.1415926535897931 .. 3.1428571428571433]' > sage: pi_appr.str() > '3.142?' > which looks perfectly reasonable. > >> The documentation is very verbose (which is a good thing). > Unfortunately "very verbose" is not synonymous with "very clear". > At least one reader succeeded in misunderstanding it.
Okay, good point. > >> When there are two possible results of equal precision and with the same >> error width, then we pick the one which is farther from zero. (For >> instance, RIF(0, 123) with two error digits could print as 61.?62 or >> 62.?62. We prefer the latter because it makes it clear that the interval >> is known not to be negative.) >> > I agree that for the interval (0,123), 61 and 62 both have error 62. > Fine. > In the example I quote, though, 3.14 has error 0.0029 and 3.15 has > error 0.0091, > so there seems to be a good case for preferring the more accurate > value. I agree that there seems to be a good case for it. I was trying to answer your original question, which I saw as a question about a bug in the code, rather than a question about a design decision. I'm sorry for misunderstanding! > > Since it has the documentation has received such an impassioned > defence, > I have made a strenuous attempt to assume that (a) the printing > routine does something > eminently logical, even if counter-intuitive (b) the documentation > describes what > that something is. > > Here goes. > > 1. Since the third digit agter the decimal point differs by more than > 1 between the two > endpoints, only two digits after the point get printed. > 2. The notation 3.14? means a subinterval of [3.13,3.15], and 3.15? > means a subinterval > of [3.14,3.16]. Since these intervals have the same length, we regard > 3.14? and 3.15? > as two possible results of equal precision. > 3. As soon as we have identified 3.14? and 3.15? as candidates to be > printed, we are no > longer interested in which one has its centre closer to the endpoints > of the original interval. > 4. We pick the one furthest from the origin because when the original > interval does > not contain zero, this choice is guaranteed to have that property too. > > That's it? > That's how I understand it from the documentation. Wow, I really like your explanation. Would you care if we included that in the documentation? Are you comfortable submitting a patch to the documentation? On the other hand, how would you change the above design to be better? Maybe this could just be a patch making the code better, rather than a patch to the documentation. I do think that the point from the documentation that we like intervals away from zero is valid, though it may be more valid for intervals that are close to zero, compared to your example which is far from zero. I don't feel very qualified to comment on design decisions in interval arithmetic. However, there are plenty of people here that would be comfortable doing so. Thanks, Jason --~--~---------~--~----~------------~-------~--~----~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
