Hi Nils, > Given how few properties a "conversion map" is actually guaranteed to > have, wouldn't it be sufficient to just have a callable represent the > conversion and not demand it's a map? >
This sounds like a good idea if conversion remain the low-level things it is (i.e. possibly without any mathematical interpretation). If at some point it is decided that conversions should have some nice properties (e.g. being actual maps with some mathematical meaning, or (partial) sections of them), then it would make more sense to make them some map-like type, but that wouldn't really be the concept that is now called conversion. I don't think we really need domain and codomain anyway. It also means that > in a lot of cases, one could simply store to codomain rather than a map > wrapping a call to the codomain. > Except that currently (if A is the codomain) A.__call__() looks for a conversion and calls it, where the default conversion consists of calling A._element_constructor_(), so just letting the conversion f be the callable A itself instead would create a circularity (A(x) = A.__call__(x) = f(x) = A(x) = ...). To implement your proposal, one could return "lambda x: return A._element_constructor_(x)" as the conversion. Peter -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
