On Monday, October 27, 2014 5:32:12 PM UTC, Nils Bruin wrote: > > I don't think this would be easy to do with the current preparser. >
As you said, we'll need to look at the AST. That is part of IPython's preprocessing framework, trivial to implement. Furthermore, I think it is a strength of computer algebra systems such as > sage, magma, maple that their interface language is also used for large > parts of their libraries. This already doesn't quite hold true for sage, > but apart from "1/2" and "2^3" it's confined to syntax that produces errors > in straight python. I suspect that changing the semantics of "==" between > interface and library will be much more subtle and hence more problematic > (because casual testing may well not find differences). I don't think its that difficult. Library generally works with elements of the same type, so you'll probably get away with not coercing in a lot of places. It is mostly useful for handling user input, where you might want to convert anyways. And if you don't then it will be rather obvious, if Integer(1) works but int(1) doesn't then your comparison was too strict. Doctesting can check that. Really its just a matter of replacing a == b in the library code with is_isomorphic(a, b) in the right places. If we are smart about the transition (supporting both old- and new-style comparison for a while) then we could add that pretty gradually. The alternative is to not have caching and associative containers for padics. That means you can never write Buchberger's algorithm for polynomials with padic coefficients, say. I find that much more worrisome. -- 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.
