Sorry to be so late (10 months late!) in responding to this; I'm
getting back to Sage development and I'm reading through my sage-devel
archives.
Dirk, I don't know if you still care about this... I'm the original
author of the code (and documentation) in question. I basically made
up the behavior based on what made sense to me. Please ignore this
email if you don't care about intervals in Sage any more...
On Wed, Sep 9, 2009 at 10:48 AM, Dirk <dirk.lau...@gmail.com> wrote:
>
>
>
> On Sep 9, 6:17 pm, Jason Grout <jason-s...@creativetrax.com> wrote:
>
>> 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?
> Not really, in view of my response to the next suggestion.
>
>> 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.
> Now you're talking.
>
> If I understand you right, the notation 3.14? is a convenience and
> nothing will break if it is changed. I suggest that it should mean
> the half-open interval [3.14,3.15).
> Advantages:
> (a) No need for a tie-breaking rule.
> (b) Half the length of [3.13,3.15].
> (c) The displayed digits are guaranteed to be correct, in the sense
> that any number in that interval starts out with them.
> (d) Easy to explain to an idiot.
The problem is that it's easy to know a lot about an interval while
knowing very few digits. For example, consider the interval [0.999999
.. 1.000001]. With the current definition, we can print this as
1.000000?; with your suggestion, we'd have to print it as 0.?e1
(meaning that the number is between 0 and 10 -- we know that the 10s
digit is 0).
> Extension to error digits: rather than having one pair of error digit
> sequences giving the width of the interval of uncertainty in units
> that require a bit of thought, give two pairs that actually specify
> the possibilities.
>
> I.e. for the Archimedes interval x=RIF(3+10/71,3+1/7) , it would be
> nice to have
> sage: x.str(error_digits=2)
> 3.14?08..29
> In the GUI as opposed to the command line, the 08 could appear as a
> subscript and the 29 as a superscript: $3.14_{08}^{29}$ in TeX
> notation.
> The fact that 08..29 is left-closed and right-open is very Pythonic
> too.
Again, how does this work for [0.999999 .. 1.000001]? I could imagine
something like 0.9999?99..01 (where the fact that the 99..01 is in the
"wrong" order indicates that the upper endpoint has actually wrapped
to 1.000001), but I think that's more confusing than the present
system.
> Related: if I say "style='brackets'", error_digits is ignored. Why
> not allow:
> sage: x.str(error_digits=2,style="brackets")
> [ 3.1408 .. 3.1429 ]
> Two error digits might even be the default for brackets. After all,
> if a number is correct to so few digits, who wants to see sixteen
> decimals of it?
So, for [0.123 .. 456.0] would you print [0.12 .. 460.0]? Or [0.0 ..
460.0]? I wouldn't object to either of these changes, although I
wouldn't implement it myself.
The thread start seemed to suggest that in the question-mark notation,
if we have multiple choices, we should use the choice that's closer to
the midpoint of the interval. Again, this is reasonable, but I
wouldn't implement it myself.
I do have a reason to prefer the current definition (pick the choice
farther from zero): it can be computed quickly and exactly. If the
docstring said that the choice closer to the midpoint of the interval
was chosen, I think that requires either: some potentially very slow
code, some very tricky code that is usually fast but occasionally
slow, or that we sometimes give the wrong answer according to the
specification.
Carl
--
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
URL: http://www.sagemath.org
