> > If this is true (i never met maxima before, but i did met "==" > > before...) then i really don't see why "==" in some context creates an > > equation. Except that now it would likely be difficult to change, > > since some code may depend on it. > > When you make two *purely* symbolic expressions, and compare them, is > it unreasonable for this to create a symbolic equation? What is a more > natural way to create symbolic equations and inequalities? We chose > this since triple equals seemed ridiculous. Double equals existed in > python so no preparsing was required. It did not even break anything > like hash table lookups since we could override __nonzero__. > > If not ==, what would you propose for creating symbolic expression > objects? The other obvious choice is eq(f, g), but I think that this > is inferior since it is much harder to guess.
Let me chime in this thread as well. Right know we are dealing with the exact same issue in SymPy. Actually we are dealing with this for months already. :) The == returning an equation *is* confusing to me. However, we thought, ok, it's a nice syntax, let's use it, so we use it in SymPy too. But then there is a speed issue. If you want to read all the deatils, go here: http://code.google.com/p/sympy/issues/detail?id=135 In short, in Python, the == operator is used a lot internally, so returning a class instead of True/False does slow things down. Some of the problems can be overcomed, some not. So, in SymPy, we want to do things easily, pythonic and fast too. Given these constraints, it's not at all clear, which way to choose for ==, there are good arguments for both possibilities. You may argument for example, that you want to do things mathematically correct in Sage (whatever it means). But speed is important too, you can search archives to find some examples, where Sage+maxima is currently slower than even pure python SymPy (and sympy can still be sped up by at least a factor of 10x while staying in pure Python), imho all due to conversions between Sage and maxima etc. It can imho be improved to some extent, but I think the right solution is to do it in Python (+ Cython), which is what we are trying, but this has the disadvantage, that it is not as robust yet as maxima, which has decades of testing behind it. Anyway, I am not giving any answer to this, as I don't know the answer. CCing sage-devel, as I think this is a design-development question. Ondrej --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
