And there is now a patch awaiting review.
I see no point in allowing mathematically meaningless conversions
between number fields. Nobody ever wants to do this. I will sometimes do
it accidentally (by mixing up variable names), and then I want to be
notified of it (by an Error) immediately.
Lifting elements from GF(2) to ZZ by explicitly converting them is fine
with me, but I don't want to allow conversions if there is no natural
map at all in either direction (such as for 2 non-embedded number fields).
I agree with David that this is a bug.
> You received this message because you are subscribed to the Google Groups "sage-nt" group.
> To post to this group, send an email to sag...@googlegroups.com.
> To unsubscribe from this group, send email to sage-nt+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/sage-nt?hl=en-GB.
This is not what is actually happening in the number field code. There
is some code for coercion and *different* code for conversion. So the
check is already done anyway.
Hi David (Roe) and Simon,
Could you explain "intended" a bit more? E.g. is this a design
decision that was made for Sage at some point? Or is it a programming
guideline that holds more generally? Is it documented somewhere?
> There's a mechanism to make this fast for conversions, just as there is for
> coercions. Implement _convert_map_from_ with a morphism
What does "morphism" mean here? Could you point me to an example of a
class where this done? And for example, can we do the following with a
Suppose L is a number field, and K is obtained from L.subfield(...).
Then K is constructed together with a morphism phi. Obviously coercion
from K to L should happen via phi (as in #11876). Conversion from L to
K (if allowed at all) should (in my opinion) be a section of phi. That
is, given x in L, if x==phi(y) for some y in K, then return y,
otherwise raise a ValueError.
p.s. About the patch at #11869: it does contain a lot of complicated
conversions that may take some time. As a bugfix, I would have written
a much shorter patch that would have simply raised ValueError a lot.
On the other hand, all the complicated and possibly time-consuming
additions of Jeroen happen after the point where I would have been
satisfies with a ValueError, so that the time he spends could be
considered free. Or would people prefer ValueError?