Stavros Macrakis

Good point! Silly of me to overlook that! Indeed, '(if false then 1/0) gives an error because the arguments to if are being simplified even if the expression is not evaluated. This feels wrong, even if I understand what is happening. I would be happier if it simplified to '(if false then 1/0). That should, I think, be a straightforward change to simp-mcond -- if a clause causes an error while simplifying, just keep it as is. The other case given in the example is worse. It seems that the simplifier...

Good point! Silly of me to overlook that! Indeed,* '(if false then 1/0) gives an error because the arguments to if are being simplified even if the expression is not evaluated. This feels wrong, even if I understand what is happening. I would be happier if it simplified to '(if false then 1/0)*. That should, I think, be a straightforward change to *simp-mcond *-- if a clause causes an error while simplifying, just keep it as is. The other case given in the example is worse. It seems that the simplifier...

plot2d premature evaluation

Thanks for doing all that work just to correct my memory! I still think it's problematic that a=b does not imply f(a)=f(b) for all f, but pragmatically, I agree that staying with the status quo makes sense.

I am surprised about the cases you mention. I thought I remembered the opposite, and specifically I think Barton and I discussed this when we were implementing the set package. I may be remembering incorrectly, but maybe someone could run a git bisect to see if it changed at some point? Fundamentally, Maxima the programming language (independently of symbolic calculations) needs to have some primitive for checking whether two things are the same value (like equal in Lisp). This is different from...

How do you define great so that sort([a, rat(a), a]) produces a predictable result? How do you distinguish rat(a+b,a) from rat(a+b,b)? They display differently, but disrep to the same thing. I'd think that is(a=rat(a)) should be false, just as is(0=0.0) is false, and T[a] should be distinct from T[rat(a)]. On Sat, Oct 3, 2026, 07:43 David Scherfgen via Maxima-bugs maxima-bugs@lists.sourceforge.net wrote: I have a patch for this. With it, is(x = y), the set functions, member, delete and assoc treat...

I am on my phone only for another week, so can't look into this in detail. But if you trace alike1, you'll see that rat(a} has been disrepped by the time it gets to alike1 in is/=, setify, and for that matter sort. So it can't distinguish them. On Fri, Oct 2, 2026, 21:22 Robert Dodier via Maxima-bugs maxima-bugs@lists.sourceforge.net wrote: I think it's a bug; "=" for sets should be defined in terms of "=" for elements, so if elements are equivalent under "=", then so are the sets, I think. It appears...

to_poly_solve results are hard to handle programmatically mostly because it handles many more cases correctly and completely, notably periodic functions. I agree that the form of its results can appear complicated and so be off-putting -- can we find a simpler way of expressing the same semantics? For example, we should be able to replace isnonnegative_p(x) with x>=0?