Stavros Macrakis

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?

This is an interesting one. Although csc(x) and cot(x) are undefined at x=0, csc(x)-cot(x) is 0 by analytic continuation at x=0. Maxima generally ignores isolated singularities like this, for example it simplifies x/x to 1. So it's unclear whether this is a bug. BTW, %solve(csc(x)-cot(x),x) => %union([x = 2 %pi %z874])

Lisp didn't have multiple value returns when I wrote risplit (1971 or so), and memory was considered expensive, hence the dotted pair. Multiple values seem like the right way to do it today, and are even more efficient! Also, dotted pairs of Maxima expressions don't print very nicely.

Internal code should be using risplit (the other bug report). Not sure why Lisp code would be calling $num/$denom, which as you point out are expensive because they first format the expression. But of course both of these are possible, just as it's possible that Lisp code isn't following other conventions like always returning simplified expressions. I suppose that you have been cleaning up a lot of these taking advantage of Claude.