Re: [sage-devel] Should RR coerce into RIF?

[Jakob Kroeker]

the ticket https://trac.sagemath.org/ticket/15114 seems orphan now...

Am Donnerstag, 20. März 2014 12:58:30 UTC+1 schrieb Marco Streng:
>
> Thanks for all the replies. It seems that everybody here agrees to 
> disallow coercions from RR to RIF, which is all that ticket 
> http://trac.sagemath.org/ticket/15114 is about, so that ticket can 
> proceed. 
>
> As for conversions or coercions RIF to RR, there doesn't seem to be 
> anybody strongly in favour having them, and it is not clear how it 
> should work, so I won't touch them. 
>
>
>
>
> 2014-03-19 16:39 GMT+01:00 Robert Bradshaw  >: 
> > +1 to all of this, specifically 
> > 
> > 1) allow 
> > 2) allow for point intervals (maybe) 
> > 3)  dissallow 
> > 
> > On Tue, Mar 18, 2014 at 3:02 PM, David Roe  > wrote: 
> >> Marc Mezzarobba wrote: 
> >>>Marco Streng wrote: 
>  So the choices are: 
>  
>  1) explicit conversion RR --> RIF: allow / disallow 
>  2) explicit conversion RIF --> RR: allow / disallow 
>  3) automatic coercisions: disallow / (RR-->RIF) / (RIF-->RR) 
> >>>[...] 
> >> 
>  My vote is: 
>  1) allow 
>  2) allow 
>  3) from RIF to RR 
> >>> 
> >>>Mine is: 
> >>> 1) allow 
> >> 
> >>> 2) allow for point intervals, require the use of explicit method calls 
> >>>(e.g., center()) for general intervals 
> >>> 3) disallow (but see below) 
> >>> 
> >>> Regarding 3), and in response to Thomas Coffee's arguments, I would be 
> >> 
> >>> in favor of also having "non-rigorous intervals", living in a separate 
> >>> parent, with a coercion from RR. In fact, one also needs intervals 
> with 
> >>> integer, rational or even symbolic endpoints from time to time. So 
> >>> unless I'm missing something, these "non-rigorous interval" could 
> simply 
> >>> be the elements of Intervals(RR), where Intervals(C) would work for 
> more 
> >>> or less arbitrary C. (And there could perhaps be a coercion from RIF 
> to 
> >>> Intervals(RR), but certainly not in the other direction.) 
> >> 
> >> I agree with Marc, though I note that C needs at least a partial 
> ordering, 
> >> which most rings don't come with. 
> >> 
> >> On Tue, Mar 18, 2014 at 2:16 PM, Thierry  > 
> >> wrote: 
> >>> 
> >>> 
> >>> It seems there are more precise cases to consider: 
> >>> 
> >>> - How do you plan to coerce a RIF element with non-trivial diameter to 
> a 
> >>>   RR element ? 
> >> 
> >> 
> >> I would say you don't even allow conversion in this case, let alone 
> >> coercion. 
> >> 
> >>> 
> >>> - How do you plan to convert 
> >>>   - from RealIntervalField(2) to RealField(100) ? 
> >> 
> >> If you start with a point interval, there's no problem.  Otherwise, 
> >> disallowed. 
> >>> 
> >>>   - from RealIntervalField(100) to RealField(2) ? 
> >> 
> >> Conversion should work as long as the upper and lower endpoints are the 
> same 
> >> in RealField(2). 
> >>> 
> >>>   - from RealField(100) to RealIntervalField(2) ? 
> >> 
> >> Smallest interval containing the input. 
> >>> 
> >>>   - from RealField(2) to RealIntervalField(100) ? 
> >> 
> >> Here you can use a point interval as the image. 
> >> 
> >> Of course, none of these should be coercions. 
> >> 
> >>> 
> >>> - How do you mix both (do you plan to deal with possible compensations 
> >>>   between number of bits of precision of the field and the diameter of 
> >>>   the intervals) ? 
> >> 
> >> 
> >> I would say yes: you can mix a change in precision with a change in 
> >> precision type. 
> >> 
> >>> 
> >>> For example, in which case do you allow (silent) coercion, and what 
> >>> should be the result of the (explicit) conversion: 
> >>> 
> >>> - RIF(-1,1) -> RR 
> >> 
> >> Coercion and conversion should both fail. 
> >>> 
> >>> - RealIntervalField(100)(1.1,1.2)) -> RealField(2) 
> >> 
> >> Coercion and conversion should both fail. 
> >>> 
> >>> - RealField(2)(pi) -> RIF  [which diameter, which endpoints ?] 
> >> 
> >> A point interval (3.0, 3.0) 
> >>> 
> >>> 
> >>> 
> >>> As for me, 
> >>> - it is clear that RIF(pi) should be coerced to RR(pi) 
> >> 
> >> I think that this actually isn't clear, since RIF(pi) is not a point 
> >> interval.  Of course, we could make a special case when the length of 
> the 
> >> interval is the minimum possible, and use the rounding mode of RR to 
> >> determine which endpoint to pick (though I don't know what we should do 
> in 
> >> the default 'RNDN' 
> >>> 
> >>> - i agree with coercing from x in RealIntervalField(a) to RealField(b) 
> >>>   when the endpoints of x are the same in RealField(b) 
> >> 
> >> Coercion needs to be defined on the whole domain.  This rule works for 
> >> conversion though. 
> >>> 
> >>> - i have no problem for explicit conversion from RIF(-1,1) to RR, but 
> it 
> >>>   should be well specified in the doc, since there is no canonical 
> way. 
> >> 
> >> I think it should be disallowed, since there are already functions to 
> get 
> 

Re: [sage-devel] Should RR coerce into RIF?

[Daniel Krenn]

Am 2014-03-18 18:28, schrieb Clemens Heuberger:
 I'd really hate if a computation that I believe to be exact using RIF
 gets inadvertently inexact by overlooking an automatic coercion
 RR-RIF.
 
 On the other hand, I would not have an automatic coercion from RIF to
 RR (to which element of RR do you map some rather large interval in
 RIF?). I'd have to choose whether I'd like to have the center or
 something else. In my view, RIF and RR are not different
 implementations of the same exact mathematical object real numbers,
 but RIF are _intervals_ of real numbers (or rather: intervals of real
 numbers with (some) rational endpoints).
 
 Therefore, my vote is
 
 On Tuesday, March 18 2014 16:22:44 UTC+1 Marco Streng wrote:
 1) explicit conversion RR -- RIF: allow / disallow 2) explicit
 conversion RIF -- RR: allow / disallow 3) automatic coercisions:
 disallow / (RR--RIF) / (RIF--RR)
 
 1) allow 2) disallow 3) disallow

+1

Daniel

-- 
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/d/optout.

Re: [sage-devel] Should RR coerce into RIF?

[Marco Streng]

2014-03-18 19:16 GMT+01:00 Thierry sage-googlesu...@lma.metelu.net:
 Is Sage able to allow a coercion from A to B, but the coercion map is
 not the same as the conversion map there (i mean, could the coercion be
 a partial map of the conversion) ?

In Sage/python, you can do whatever you want, but this will make
people very unhappy. The rules for coercions are: if a coercion from A
to B exists, then it has to be a map on all elements of A, and has to
equal the conversion from A to B.
http://www.sagemath.org/doc/thematic_tutorials/coercion_and_categories.html#the-four-axioms-requested-for-coercions

-- 
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/d/optout.

Re: [sage-devel] Should RR coerce into RIF?

[Marco Streng]

Thanks for all the replies. It seems that everybody here agrees to
disallow coercions from RR to RIF, which is all that ticket
http://trac.sagemath.org/ticket/15114 is about, so that ticket can
proceed.

As for conversions or coercions RIF to RR, there doesn't seem to be
anybody strongly in favour having them, and it is not clear how it
should work, so I won't touch them.




2014-03-19 16:39 GMT+01:00 Robert Bradshaw rober...@math.washington.edu:
 +1 to all of this, specifically

 1) allow
 2) allow for point intervals (maybe)
 3)  dissallow

 On Tue, Mar 18, 2014 at 3:02 PM, David Roe roed.m...@gmail.com wrote:
 Marc Mezzarobba wrote:
Marco Streng wrote:
 So the choices are:

 1) explicit conversion RR -- RIF: allow / disallow
 2) explicit conversion RIF -- RR: allow / disallow
 3) automatic coercisions: disallow / (RR--RIF) / (RIF--RR)
[...]

 My vote is:
 1) allow
 2) allow
 3) from RIF to RR

Mine is:
 1) allow

 2) allow for point intervals, require the use of explicit method calls
(e.g., center()) for general intervals
 3) disallow (but see below)

 Regarding 3), and in response to Thomas Coffee's arguments, I would be

 in favor of also having non-rigorous intervals, living in a separate
 parent, with a coercion from RR. In fact, one also needs intervals with
 integer, rational or even symbolic endpoints from time to time. So
 unless I'm missing something, these non-rigorous interval could simply
 be the elements of Intervals(RR), where Intervals(C) would work for more
 or less arbitrary C. (And there could perhaps be a coercion from RIF to
 Intervals(RR), but certainly not in the other direction.)

 I agree with Marc, though I note that C needs at least a partial ordering,
 which most rings don't come with.

 On Tue, Mar 18, 2014 at 2:16 PM, Thierry sage-googlesu...@lma.metelu.net
 wrote:


 It seems there are more precise cases to consider:

 - How do you plan to coerce a RIF element with non-trivial diameter to a
   RR element ?


 I would say you don't even allow conversion in this case, let alone
 coercion.


 - How do you plan to convert
   - from RealIntervalField(2) to RealField(100) ?

 If you start with a point interval, there's no problem.  Otherwise,
 disallowed.

   - from RealIntervalField(100) to RealField(2) ?

 Conversion should work as long as the upper and lower endpoints are the same
 in RealField(2).

   - from RealField(100) to RealIntervalField(2) ?

 Smallest interval containing the input.

   - from RealField(2) to RealIntervalField(100) ?

 Here you can use a point interval as the image.

 Of course, none of these should be coercions.


 - How do you mix both (do you plan to deal with possible compensations
   between number of bits of precision of the field and the diameter of
   the intervals) ?


 I would say yes: you can mix a change in precision with a change in
 precision type.


 For example, in which case do you allow (silent) coercion, and what
 should be the result of the (explicit) conversion:

 - RIF(-1,1) - RR

 Coercion and conversion should both fail.

 - RealIntervalField(100)(1.1,1.2)) - RealField(2)

 Coercion and conversion should both fail.

 - RealField(2)(pi) - RIF  [which diameter, which endpoints ?]

 A point interval (3.0, 3.0)



 As for me,
 - it is clear that RIF(pi) should be coerced to RR(pi)

 I think that this actually isn't clear, since RIF(pi) is not a point
 interval.  Of course, we could make a special case when the length of the
 interval is the minimum possible, and use the rounding mode of RR to
 determine which endpoint to pick (though I don't know what we should do in
 the default 'RNDN'

 - i agree with coercing from x in RealIntervalField(a) to RealField(b)
   when the endpoints of x are the same in RealField(b)

 Coercion needs to be defined on the whole domain.  This rule works for
 conversion though.

 - i have no problem for explicit conversion from RIF(-1,1) to RR, but it
   should be well specified in the doc, since there is no canonical way.

 I think it should be disallowed, since there are already functions to get
 the lower, upper and center.

 - i am not sure wether RIF(-1,1) should coerce to RR

 Definitely not.


 Is Sage able to allow a coercion from A to B, but the coercion map is
 not the same as the conversion map there (i mean, could the coercion be
 a partial map of the conversion) ?

 No.  If a coercion exists, it must be defined on all of A and must agree
 with the conversion map from A to B.


 As for me, i am against RR - RIF coercion because some Sage code (not
 user code) could convert from RIF to RR because of some internal
 multiplication, and then silently back to RIF (if the coercion RR-RIF
 were allowed), leading to a false sense of precision and even the
 experienced user will not noticing it (no none can be assumed to know
 all Sage source code), and will not be able to hand-check this as
 suggested in the comment, since not all computations are done by the
 user.


 +1


 BUT, 

Re: [sage-devel] Should RR coerce into RIF?

[Robert Bradshaw]

+1 to all of this, specifically

1) allow
2) allow for point intervals (maybe)
3)  dissallow

On Tue, Mar 18, 2014 at 3:02 PM, David Roe roed.m...@gmail.com wrote:
 Marc Mezzarobba wrote:
Marco Streng wrote:
 So the choices are:

 1) explicit conversion RR -- RIF: allow / disallow
 2) explicit conversion RIF -- RR: allow / disallow
 3) automatic coercisions: disallow / (RR--RIF) / (RIF--RR)
[...]

 My vote is:
 1) allow
 2) allow
 3) from RIF to RR

Mine is:
 1) allow

 2) allow for point intervals, require the use of explicit method calls
(e.g., center()) for general intervals
 3) disallow (but see below)

 Regarding 3), and in response to Thomas Coffee's arguments, I would be

 in favor of also having non-rigorous intervals, living in a separate
 parent, with a coercion from RR. In fact, one also needs intervals with
 integer, rational or even symbolic endpoints from time to time. So
 unless I'm missing something, these non-rigorous interval could simply
 be the elements of Intervals(RR), where Intervals(C) would work for more
 or less arbitrary C. (And there could perhaps be a coercion from RIF to
 Intervals(RR), but certainly not in the other direction.)

 I agree with Marc, though I note that C needs at least a partial ordering,
 which most rings don't come with.

 On Tue, Mar 18, 2014 at 2:16 PM, Thierry sage-googlesu...@lma.metelu.net
 wrote:


 It seems there are more precise cases to consider:

 - How do you plan to coerce a RIF element with non-trivial diameter to a
   RR element ?


 I would say you don't even allow conversion in this case, let alone
 coercion.


 - How do you plan to convert
   - from RealIntervalField(2) to RealField(100) ?

 If you start with a point interval, there's no problem.  Otherwise,
 disallowed.

   - from RealIntervalField(100) to RealField(2) ?

 Conversion should work as long as the upper and lower endpoints are the same
 in RealField(2).

   - from RealField(100) to RealIntervalField(2) ?

 Smallest interval containing the input.

   - from RealField(2) to RealIntervalField(100) ?

 Here you can use a point interval as the image.

 Of course, none of these should be coercions.


 - How do you mix both (do you plan to deal with possible compensations
   between number of bits of precision of the field and the diameter of
   the intervals) ?


 I would say yes: you can mix a change in precision with a change in
 precision type.


 For example, in which case do you allow (silent) coercion, and what
 should be the result of the (explicit) conversion:

 - RIF(-1,1) - RR

 Coercion and conversion should both fail.

 - RealIntervalField(100)(1.1,1.2)) - RealField(2)

 Coercion and conversion should both fail.

 - RealField(2)(pi) - RIF  [which diameter, which endpoints ?]

 A point interval (3.0, 3.0)



 As for me,
 - it is clear that RIF(pi) should be coerced to RR(pi)

 I think that this actually isn't clear, since RIF(pi) is not a point
 interval.  Of course, we could make a special case when the length of the
 interval is the minimum possible, and use the rounding mode of RR to
 determine which endpoint to pick (though I don't know what we should do in
 the default 'RNDN'

 - i agree with coercing from x in RealIntervalField(a) to RealField(b)
   when the endpoints of x are the same in RealField(b)

 Coercion needs to be defined on the whole domain.  This rule works for
 conversion though.

 - i have no problem for explicit conversion from RIF(-1,1) to RR, but it
   should be well specified in the doc, since there is no canonical way.

 I think it should be disallowed, since there are already functions to get
 the lower, upper and center.

 - i am not sure wether RIF(-1,1) should coerce to RR

 Definitely not.


 Is Sage able to allow a coercion from A to B, but the coercion map is
 not the same as the conversion map there (i mean, could the coercion be
 a partial map of the conversion) ?

 No.  If a coercion exists, it must be defined on all of A and must agree
 with the conversion map from A to B.


 As for me, i am against RR - RIF coercion because some Sage code (not
 user code) could convert from RIF to RR because of some internal
 multiplication, and then silently back to RIF (if the coercion RR-RIF
 were allowed), leading to a false sense of precision and even the
 experienced user will not noticing it (no none can be assumed to know
 all Sage source code), and will not be able to hand-check this as
 suggested in the comment, since not all computations are done by the
 user.


 +1


 BUT, i find the second example of tcoffee quite convincing (i am also
 doing some RIF stuff to understand the loss of precision along a
 computation), so perhaps could there be an easy way to let the user tune
 such a convenient coercion easily at her own risks, and a way to learn
 about this. Or perhaps could there be a special parent for this kind of
 experiments.


 I think Marc's suggestion of a different parent is the best one, though of
 course 

Re: [sage-devel] Should RR coerce into RIF?

[Marco Streng]

It looks like this discussion just started again on trac, so maybe we 
should continue the discussion here and/or vote.

To summarize: the consensus on this thread was that automatic coercions 
should to from RIF to RR, not from RR to RIF. The reason was that elements 
of RIF represent guaranteed intervals, while elements of RR represent 
approximations that are expected to have some rounding errors, so if you 
combine them, then a RIF result will be incorrect. Because of this, trac 
ticket 15114 was opened, which contains an example of a calculation with an 
incorrect answer.

On that ticket, the user tcoffee mentions two applications that get broken 
by removing or inverting the coercion RR -- RIF: the use of exact power of 
2 from RR and mixing them with RIF to get elements of RIF, and the use of 
RIF for representing ranges of inexact floating point numbers and mixing 
those with regular floating point numbers. For details, see the track 
ticket.

So the choices are:

1) explicit conversion RR -- RIF: allow / disallow
2) explicit conversion RIF -- RR: allow / disallow
3) automatic coercisions: disallow / (RR--RIF) / (RIF--RR)

The current situation afaik (Sage 6.0) is:
1) allow
2) disallow
3) from RR to RIF

My vote is:
1) allow
2) allow
3) from RIF to RR

Best,
Marco











Op woensdag 28 augustus 2013 12:00:28 UTC+2 schreef Marco Streng:

 It seems like everyone agrees that coercions from RR to RIF should be 
 removed, so I created
 http://trac.sagemath.org/ticket/15114





-- 
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/d/optout.

Re: [sage-devel] Should RR coerce into RIF?

[Thierry]

Hi,

On Tue, Mar 18, 2014 at 08:22:44AM -0700, Marco Streng wrote:
[...]
 So the choices are:

 1) explicit conversion RR -- RIF: allow / disallow
 2) explicit conversion RIF -- RR: allow / disallow
 3) automatic coercisions: disallow / (RR--RIF) / (RIF--RR)

It seems there are more precise cases to consider: 

- How do you plan to coerce a RIF element with non-trivial diameter to a
  RR element ?

- How do you plan to convert 
  - from RealIntervalField(2) to RealField(100) ?
  - from RealIntervalField(100) to RealField(2) ?
  - from RealField(100) to RealIntervalField(2) ?
  - from RealField(2) to RealIntervalField(100) ?

- How do you mix both (do you plan to deal with possible compensations
  between number of bits of precision of the field and the diameter of
  the intervals) ? 

For example, in which case do you allow (silent) coercion, and what
should be the result of the (explicit) conversion:

- RIF(-1,1) - RR 
- RealIntervalField(100)(1.1,1.2)) - RealField(2)
- RealField(2)(pi) - RIF  [which diameter, which endpoints ?]
- and so on


As for me, 
- it is clear that RIF(pi) should be coerced to RR(pi)
- i agree with coercing from x in RealIntervalField(a) to RealField(b)
  when the endpoints of x are the same in RealField(b)
- i have no problem for explicit conversion from RIF(-1,1) to RR, but it
  should be well specified in the doc, since there is no canonical way.
- i am not sure wether RIF(-1,1) should coerce to RR

Is Sage able to allow a coercion from A to B, but the coercion map is
not the same as the conversion map there (i mean, could the coercion be
a partial map of the conversion) ?

As for me, i am against RR - RIF coercion because some Sage code (not
user code) could convert from RIF to RR because of some internal
multiplication, and then silently back to RIF (if the coercion RR-RIF
were allowed), leading to a false sense of precision and even the
experienced user will not noticing it (no none can be assumed to know
all Sage source code), and will not be able to hand-check this as
suggested in the comment, since not all computations are done by the
user.

BUT, i find the second example of tcoffee quite convincing (i am also
doing some RIF stuff to understand the loss of precision along a
computation), so perhaps could there be an easy way to let the user tune
such a convenient coercion easily at her own risks, and a way to learn
about this. Or perhaps could there be a special parent for this kind of
experiments.

Ciao,
Thierry

-- 
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/d/optout.

Re: [sage-devel] Should RR coerce into RIF?

[Clemens Heuberger]

I'd really hate if a computation that I believe to be exact using RIF gets 
inadvertently inexact by overlooking an automatic coercion RR-RIF.

On the other hand, I would not have an automatic coercion from RIF to RR (to 
which element of RR do you map some rather large interval in RIF?). I'd have to 
choose whether I'd like to have the center or something else. In my view, RIF 
and RR are not different implementations of the same exact mathematical object 
real numbers, but RIF are _intervals_ of real numbers (or rather: intervals 
of real numbers with (some) rational endpoints). 

Therefore, my vote is

On Tuesday, March 18 2014 16:22:44 UTC+1 Marco Streng wrote:
 1) explicit conversion RR -- RIF: allow / disallow
 2) explicit conversion RIF -- RR: allow / disallow
 3) automatic coercisions: disallow / (RR--RIF) / (RIF--RR)

1) allow
2) disallow
3) disallow

Best,

Clemens Heuberger

-- 
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/d/optout.

Re: [sage-devel] Should RR coerce into RIF?

[David Roe]

Marc Mezzarobba wrote:
Marco Streng wrote:
 So the choices are:

 1) explicit conversion RR -- RIF: allow / disallow
 2) explicit conversion RIF -- RR: allow / disallow
 3) automatic coercisions: disallow / (RR--RIF) / (RIF--RR)
[...]
 My vote is:
 1) allow
 2) allow
 3) from RIF to RR

Mine is:
 1) allow
 2) allow for point intervals, require the use of explicit method calls
(e.g., center()) for general intervals
 3) disallow (but see below)

 Regarding 3), and in response to Thomas Coffee's arguments, I would be
 in favor of also having non-rigorous intervals, living in a separate
 parent, with a coercion from RR. In fact, one also needs intervals with
 integer, rational or even symbolic endpoints from time to time. So
 unless I'm missing something, these non-rigorous interval could simply
 be the elements of Intervals(RR), where Intervals(C) would work for more
 or less arbitrary C. (And there could perhaps be a coercion from RIF to
 Intervals(RR), but certainly not in the other direction.)

I agree with Marc, though I note that C needs at least a partial ordering,
which most rings don't come with.

On Tue, Mar 18, 2014 at 2:16 PM, Thierry sage-googlesu...@lma.metelu.netwrote:


 It seems there are more precise cases to consider:

 - How do you plan to coerce a RIF element with non-trivial diameter to a
   RR element ?


I would say you don't even allow conversion in this case, let alone
coercion.


 - How do you plan to convert
   - from RealIntervalField(2) to RealField(100) ?

If you start with a point interval, there's no problem.  Otherwise,
disallowed.

   - from RealIntervalField(100) to RealField(2) ?

Conversion should work as long as the upper and lower endpoints are the
same in RealField(2).

   - from RealField(100) to RealIntervalField(2) ?

Smallest interval containing the input.

   - from RealField(2) to RealIntervalField(100) ?

Here you can use a point interval as the image.

Of course, none of these should be coercions.


 - How do you mix both (do you plan to deal with possible compensations
   between number of bits of precision of the field and the diameter of
   the intervals) ?


I would say yes: you can mix a change in precision with a change in
precision type.


 For example, in which case do you allow (silent) coercion, and what
 should be the result of the (explicit) conversion:

 - RIF(-1,1) - RR

Coercion and conversion should both fail.

 - RealIntervalField(100)(1.1,1.2)) - RealField(2)

Coercion and conversion should both fail.

 - RealField(2)(pi) - RIF  [which diameter, which endpoints ?]

A point interval (3.0, 3.0)



 As for me,
 - it is clear that RIF(pi) should be coerced to RR(pi)

I think that this actually isn't clear, since RIF(pi) is not a point
interval.  Of course, we could make a special case when the length of the
interval is the minimum possible, and use the rounding mode of RR to
determine which endpoint to pick (though I don't know what we should do in
the default 'RNDN'

 - i agree with coercing from x in RealIntervalField(a) to RealField(b)
   when the endpoints of x are the same in RealField(b)

Coercion needs to be defined on the whole domain.  This rule works for
conversion though.

 - i have no problem for explicit conversion from RIF(-1,1) to RR, but it
   should be well specified in the doc, since there is no canonical way.

I think it should be disallowed, since there are already functions to get
the lower, upper and center.

 - i am not sure wether RIF(-1,1) should coerce to RR

Definitely not.


 Is Sage able to allow a coercion from A to B, but the coercion map is
 not the same as the conversion map there (i mean, could the coercion be
 a partial map of the conversion) ?

No.  If a coercion exists, it must be defined on all of A and must agree
with the conversion map from A to B.


 As for me, i am against RR - RIF coercion because some Sage code (not
 user code) could convert from RIF to RR because of some internal
 multiplication, and then silently back to RIF (if the coercion RR-RIF
 were allowed), leading to a false sense of precision and even the
 experienced user will not noticing it (no none can be assumed to know
 all Sage source code), and will not be able to hand-check this as
 suggested in the comment, since not all computations are done by the
 user.


+1


 BUT, i find the second example of tcoffee quite convincing (i am also
 doing some RIF stuff to understand the loss of precision along a
 computation), so perhaps could there be an easy way to let the user tune
 such a convenient coercion easily at her own risks, and a way to learn
 about this. Or perhaps could there be a special parent for this kind of
 experiments.


I think Marc's suggestion of a different parent is the best one, though of
course requires more work.
David


 Ciao,
 Thierry

 --
 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, 

Re: [sage-devel] Should RR coerce into RIF?

[Marco Streng]

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.00, 2.00)
 
  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.

[sage-devel] Should RR coerce into RIF?

[Marc Mezzarobba]

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.00, 2.00)

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?

-- 
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.

Re: [sage-devel] Should RR coerce into RIF?

[Jeroen Demeyer]

It's hard to define what coercion would even mean in this case. The 
manual mentions that it must be a ring homomorphism, but in this case 
(RLF, RR, RIF) the mathematical ring is all the same, namely the real 
numbers. It is only the implementation of the ring which is different.


I don't understand the following either:
sage: RealField(100).has_coerce_map_from(RealField(50))
False
sage: RealField(50).has_coerce_map_from(RealField(100))
True

--
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.

Re: [sage-devel] Should RR coerce into RIF?

[Vincent Delecroix]

2013/8/26 Jeroen Demeyer jdeme...@cage.ugent.be

 It's hard to define what coercion would even mean in this case. The
 manual mentions that it must be a ring homomorphism, but in this case (RLF,
 RR, RIF) the mathematical ring is all the same, namely the real numbers.
 It is only the implementation of the ring which is different.

 I don't understand the following either:
 sage: RealField(100).has_coerce_map_**from(RealField(50))
 False
 sage: RealField(50).has_coerce_map_**from(RealField(100))
 True


This is clearly what we want. If you have an operation involving several
real numbers with different precisions then you want that the result has
the least precision.

-- 
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.

Re: [sage-devel] Should RR coerce into RIF?

[Vincent Delecroix]

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.00, 2.00)

 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.