It seems like everyone agrees that coercions from RR to RIF should be
removed, so I created
http://trac.sagemath.org/ticket/15114
2013/8/26 Vincent Delecroix <20100.delecr...@gmail.com>
> I am strongly against conversion from floating-point to interval
> field. Floatting point arithmetic is approximate whereas interval
> arithmetic is guaranteed. Moreover, the conversion between non exact
> rings in Sage are always from "more precision" to "less precision".
> For these reasons the conversion should be from RIF to RR and from CIF
> to CC and not the other way around.
>
> I agree that there are trivial conversions from RR to RIF and CC to
> CIF but I do not want them as coercions.
>
> An example: if I is an interval and try {{{sage: I.cos()}}} you know
> that the image of I by the (mathematical) function cos is contained in
> the result. Now if you allow the coercion to the real numbers you
> assume that {{{sage: RR(I).cos()}}} is a good answer for the same
> computation which is not! It might even be out of the image of I by
> the (mathematical) function cos.
>
> A counter example: If x is a real number and I is an interval what do
> we want for the result of I+x? I would prefer to obtain an interval,
> but I think of this operation as a right action of RR on RIF by
> translations of the intervals and **not** as an addition.
>
> Best,
> Vincent
>
> 2013/8/26 Marco Streng <marco.str...@gmail.com>:
> >
> >
> >
> > 2013/8/26 Marc Mezzarobba <m...@mezzarobba.net>
> >>
> >> Hi,
> >>
> >> Sage happily coerces floating-point numbers (e.g., elements of RR) into
> >> intervals (e.g., elements of RIF), subject to some conditions on the
> >> precision of the source and destination rings.
> >>
> >> The relevant portion of the coercion graph looks like this:
> >>
> >> ( +---> RDF )
> >> | |
> >> Exact v
> >> real ---> RLF ---> RR
> >> fields |
> >> | v
> >> +---> RIF
> >>
> >> The coercions RLF --> RIF and RLF --> RR --> RIF violate the requirement
> >> that coercions should form a commutative diagram. Right now, it is not
> >> too much of an issue in practice, because coercions X --> RIF are
> >> constructed based on the existing coercions X --> RR and direct
> >> coercions like RLF --> RIF always(?) end up being preferred to variants
> >> going through RR.
> >>
> >> But this is of course pretty fragile to changes in the coercion system.
> >> If a coercion path of the form X --> RR --> RIF is ever chosen for some
> >> exact ring X (whose elements are not exactly representable by elements
> >> of RR!), arithmetic operations between elements of X and intervals will
> >> yield mathematically incorrect results. Besides, things like
> >>
> >> sage: iv = 1 + 2^(-55) + 0. + RIF(1)
> >> sage: iv.lower(), iv.upper()
> >> (2.00000000000000, 2.00000000000000)
> >>
> >> can already make for subtle bugs in the current situation.
> >>
> >> The same issue exists for CC, CIF and friends.
> >>
> >> I see little value in having mixed operations between floating-point
> >> numbers and intervals work automatically, so I would be in favor of
> >> removing the coercions from floating-point rings to interval rings
> >> altogether. What do you think?
> >
> >
> > +1
> > When I use interval arithmetic, I do that because I want a proof that a
> > number is in an interval. But I also know that I can make a mistake of
> the
> > form of your example above. We can allow explicit conversions both ways,
> but
> > it makes more sense to me if automatic coercions don't go from RealField
> to
> > RealIntervalField.
> >
> >>
> >>
> >> --
> >> Marc
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> Groups
> >> "sage-devel" group.
> >> To unsubscribe from this group and stop receiving emails from it, send
> an
> >> email to sage-devel+unsubscr...@googlegroups.com.
> >> To post to this group, send email to sage-devel@googlegroups.com.
> >> Visit this group at http://groups.google.com/group/sage-devel.
> >> For more options, visit https://groups.google.com/groups/opt_out.
> >
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "sage-devel" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to sage-devel+unsubscr...@googlegroups.com.
> > To post to this group, send email to sage-devel@googlegroups.com.
> > Visit this group at http://groups.google.com/group/sage-devel.
> > For more options, visit https://groups.google.com/groups/opt_out.
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/groups/opt_out.
>
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.
