Substitution order and zero-divide

[rtoy]

Imported from SourceForge on 2024-07-08 21:16:43 Created by macrakis on 2022-08-03 00:29:18 Original: https://sourceforge.net/p/maxima/bugs/4011

---

subst([k=0,l=0],k/l) => 0   << as expected
subst([l=0,k=0],k/l) => ERR << as expected; order matters
psubst([a=0,b=0],b/a) => ERR << as expected
psubst([a=0,b=0],a/b) => 0  << ??? should be ERR

declare([k,l],integer$
sin(k*%pi)/sin(l*%pi) => ERR << as expected; sins simplified to 0

ey: sin(K*%pi)/sin(L*%pi)$
ez: sin(N*%pi)/sin(M*%pi)$
declare([K,L,M,N],integer)$
expand(ey,0,0) => 0           << ??? should be ERR
expand(ez,0,0) => ERR.        << correctly gives error

Tested in Maxima 5.46.0 SBCL 2.2.5 MacOS

[rtoy]

Imported from SourceForge on 2024-07-08 21:16:44 Created by robert_dodier on 2022-08-03 17:02:38 Original: https://sourceforge.net/p/maxima/bugs/4011/#7ce1

---

Hmm, that's a good one. Looks like that behavior is coming out of SIMPTIMES, not psubst.

(%i5) :lisp (defun f ()  '((mtimes) 0 ((mexpt) 0 -1)))
F
(%i6) ?f();
  0: (MAXIMA::SIMPTIMES ((MAXIMA::MTIMES) 0 ((MAXIMA::MEXPT) 0 -1)) 1 NIL)
  0: SIMPTIMES returned 0
(%o6)                                  0

I guess SIMPTIMES sees the 0 and stops there, it doesn't continue looking at arguments.

I think a more correct behavior would be to look at the rest of the arguments when a 0 is found, and return 0 only if there are no simplification errors. I guess that could be expensive in some cases, but maybe it's worth trying.

[rtoy]

Imported from SourceForge on 2024-07-08 21:16:47 Created by macrakis on 2022-08-03 22:51:28 Original: https://sourceforge.net/p/maxima/bugs/4011/#64db

---

Yes. Related simplifya/simptimes problems: ((mtimes) 0 0.0) => 0 <<< float is supposed to be contagious ((mtimes) 0.0 0) => 0.0 <<< correct Similarly with bfloat 0.