maxima-discuss — Maxima discussion list

[Maxima-discuss] Inconsistent output for --list-avail

[Raymond T. <toy...@gm...>]

I almost always run maxima-local with the -g option. So I tried 
|maxima-local -g --list-avail|. No available lisps were printed, even 
though I obviously had one compiled. Then I tried |maxima-local 
--list-avail|, All of the available lisps were printed out, but the 
version was 21f, the version of cmucl that I used as the default lisp.

Also, I see that the lisp function |list-avail-action| is what is 
failing to show any available lisps because it's looking for lisps in 
"/home/toy/src/sourceforge/maxima/lib/maxima/branch_5_47_base_1935_g3d6e3e13e_dirty/", 
which doesn't exist when running maxima-local.

So two questions here. First, shouldn't we print out 
"branch_5_47_base_1935_g3d6e3e13e_dirty" as the version instead of the 
version from the default lisp? That's pretty easy to fix.

Second, should |list-avail-action| actually work when running 
maxima-local? I assume we just need to tweak the path that's being used 
in maxima-local to search for available lisps.

Oh, one more. Why does maxima-local parse |--list-avail| anyway? 
Shouldn't this all go to lisp?

​

Re: [Maxima-discuss] proof of concept for iterating over hash tables

[Stavros M. <mac...@gm...>]

I suppose it's that user's fault if they have

uu: [4,5]$
uu[8]: 23$

The nasty part is that the hasharray is global is I'm not mistaken and not
shadowed by a local variable:

vv[8]: 23$
block( [vv: [4,5]], for i in vv ... )

(typed on phone; please forgive errors)



On Tue, Nov 18, 2025, 13:37 Michel Talon <ta...@lp...> wrote:

>
> Le 18/11/2025 à 08:49, Robert Dodier a écrit :
>
> Here's a proof of concept implementation for iterating over a hash
> table using for-loop syntax.
>
> For sure the syntax is very nice, should we say pythonic?
>
>
> --
> Michel Talon
>
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>

Re: [Maxima-discuss] proof of concept for iterating over hash tables

[Michel T. <ta...@lp...>]

Le 18/11/2025 à 08:49, Robert Dodier a écrit :
> Here's a proof of concept implementation for iterating over a hash
> table using for-loop syntax.

For sure the syntax is very nice, should we say pythonic?


-- 
Michel Talon

[Maxima-discuss] proof of concept for iterating over hash tables

[Robert D. <rob...@gm...>]

Here's a proof of concept implementation for iterating over a hash
table using for-loop syntax. See the PS for a patch.

First create a Maxima hash table (undeclared array).

(%i1) foo[a, b]: 111 $
(%i2) foo[c, d]: 222 $
(%i3) foo[e, f]: 333 $

Now iterate over the key, value pairs. Variable kv holds both key and value.

(%i4) for kv in foo do print (kv[1], "-->", kv[2]);
[a, b] --> 111
[c, d] --> 222
[e, f] --> 333
(%o4)                               done

k is the key and v is the value. This makes use of the destructuring
assignment mechanism, which does things like [a, b]: [111, 222] to
assign 111 to a and 222 to b.

(%i5) for [k, v] in foo do print (k, "-->", v);
[a, b] --> 111
[c, d] --> 222
[e, f] --> 333
(%o5)                               done

Destructuring assignment again, but this time assign each of two keys
individually. Note that [[a, b], c]: [[11, 22], 33] assigns a: 11, b:
22, and c: 33.

(%i6) for [[k1, k2], v] in foo do print (k1, "and", k2, "-->", v);
a and b --> 111
c and d --> 222
e and f --> 333
(%o6)                               done

The code also works for value hash tables, as created by
make_array(hashed, ...) and use_fast_arrays: true.

What does anyone think of this stuff?

Robert

PS. Here's the patch. I wish to emphasize that THIS CODE IS FOR
DISCUSSION ONLY. IT MAY HAVE VARIOUS FLAWS AND CERTAINLY WILL NOT BE
COMMITTED WITHOUT FURTHER WORK. Anyway here it is.

git diff -- src/mlisp.lisp
diff --git a/src/mlisp.lisp b/src/mlisp.lisp
index e9a0bcd..6df019e 100644
--- a/src/mlisp.lisp
+++ b/src/mlisp.lisp
@@ -471,9 +471,9 @@ wrapper for this."
                            (cons (ncons fnname) lamvars))
                        (cons '(mlist) fnargs)))))
     (let ((var (car vars)))
-      (if (not (symbolp var))
+      #+nil (if (not (symbolp var))
          (merror (intl:gettext "Only symbols can be bound; found: ~M") var))
-      (let ((value (if (boundp var)
+      (let ((value #-nil (meval var) #+nil (if (boundp var)
                        (if (eq var '$errormsg)
                            ;; Do not take the actual value of $errormsg. It is
                            ;; always NIL at this point, but the value which
@@ -2229,11 +2229,31 @@ wrapper for this."
                        (merror (intl:gettext "do loop: illegal
'return': ~M") (car val)))
                       (t (return (car val))))))))

+(defun key-value-pairs-given-key-lists (x key-lists)
+  (mapcar (lambda (l) (list '(mlist) l (mfuncall '$arrayapply x l)))
key-lists))
+
+(defun key-value-pairs-for-hashed-array (x)
+  (let*
+    ((1-d-hash-table (gethash 'dim1 x))
+     (info (mfuncall '$arrayinfo x))
+     (keys-raw (cdddr info))
+     (key-lists (if 1-d-hash-table (mapcar (lambda (y) (cons '(mlist)
(list y))) keys-raw) keys-raw)))
+    (key-value-pairs-given-key-lists x key-lists)))
+
+(defun key-value-pairs-for-undeclared-array (x)
+  (let*
+    ((info (mfuncall '$arrayinfo x))
+     (key-lists (cdddr info)))
+    (key-value-pairs-given-key-lists x key-lists)))
+
 (defmspec mdoin (form)
   (setq form (cdr form))
   (funcall #'(lambda  (mdop my-var set test action)
               (setq set (if ($atom (setq set (format1 (meval (cadr form)))))
-                            (merror (intl:gettext "do loop: 'in'
argument must be a nonatomic expression; found: ~M") set)
+                            (cond
+                              ((hash-table-p set)
(key-value-pairs-for-hashed-array set))
+                              ((safe-mget set 'hashar)
(key-value-pairs-for-undeclared-array set))
+                              (t (merror (intl:gettext "do loop:
atomic 'in' argument must be a hashed or undeclared array; found: ~M")
set)))
                             (margs set))
                     test (list '(mor)
                                (if (car (cddddr form))

Re: [Maxima-discuss] elementary solve() problem

[richard c. <rp...@cl...>]

I also have this following one now...
Is this a problem with solve(), or have I done something wrong?


(%i107)	y: sqrt(4-x**2);
(y)	sqrt(4-x^2)
(%i108)	diff(y,x);
(%o108)	-(x/sqrt(4-x^2))
(%i109)	ev(%,x=-sqrt(2));
(%o109)	1
(%i110)	diff(y,x)=1;
(%o110)	-(x/sqrt(4-x^2))=1
(%i111)	solve(%,x);
(%o111)	[x=-sqrt(4-x^2)]



best, Richard



On 2025-11-13 17:53, Stavros Macrakis wrote:
> As Barton suggests, solve is weak in many ways. His %solve (in
> to_poly_solve) is more powerful in many ways, but not all.
> 
> Some simple cases that neither one handles:
> 
> * x!=0
> * x!=120
> * sin(x)=x
> * 2^x=5^x
> * 7*2^x=5^x
> 
> Many of these have easy solutions and also hard solutions with no
> closed form. (Usually complex, but even some real ones: consider x!
> for x<0 for example.) Many users would be delighted for solve to find
> the easy solutions, even if it can't find the hard solutions.
> 
> Tested in 5.48 SBCL 2.5.7 MacOS
> 
> On Thu, Nov 13, 2025 at 10:39 AM Barton Willis via Maxima-discuss
> <max...@li...> wrote:
> 
>> The Maxima solve function needs improvement. Please don't get the
>> impression that setting an obscure variable will fix all its
>> shortcomings.
>> Maybe somebody should experiment with making the default of
>> solveradcan true.
>> --Barton
>> 
>> -------------------------
>> 
>> From: richard christian <rp...@cl...>
>> Sent: Thursday, November 13, 2025 5:33 AM
>> To: Barton Willis <wi...@un...>
>> Cc: max...@li...
>> <max...@li...>
>> Subject: Re: [Maxima-discuss] elementary solve() problem
>> 
>> Caution: Non-NU Email
>> 
>> Terrific. Thank you, Barton.
>> And needless to say, apologies for the accidental repetition in the
>> first 6 lines of my example...
>> 
>> rc
>> 
>> On 2025-11-13 11:23, Barton Willis wrote:
>>> Try setting the option variable solveradcan to true before
>> solving:
>>> 
>>> (%i1) solveradcan : true$
>>> 
>>> (%i2) solve(n*10^(n-1)=2*n*5^(n-1),n);
>>> (%o2) [n=0,n=2]
>>> 
>>> Alternatively, apply radcan before solving:
>>> 
>>> (%i1) radcan(n*10^(n-1)=2*n*5^(n-1));
>>> (%o1) 2^(n-1)*5^(n-1)*n=2*5^(n-1)*n
>>> 
>>> (%i2) solve(%,n);
>>> (%o2) [n=0,n=2]
>>> 
>>> For a list of additional option variables (and a bunch of other
>>> stuff) that affect how solve works, try
>>> 
>>> (%i3) apropos (solve);
>>> 
>>> 
>> 
> (%o3) [desolve,funcsolve,globalsolve,linsolve,linsolve_by_lu,linsolve_params,linsolvewarn,solve,solve_congruences,solvedecomposes,solveexplicit,solvefactors,
>>> 
>>> Solvenullwarn,solveradcan,solvetrigwarn,tmlinsolve,to_poly_solve]
>>> 
>>> Thanks for your interest in Maxima! If you have more questions,
>> feel
>>> free to ask.
>>> 
>>> --Barton
>>> 
>>> -------------------------
>>> 
>>> From: richard christian <rp...@cl...>
>>> Sent: Thursday, November 13, 2025 3:57 AM
>>> To: max...@li...
>>> <max...@li...>
>>> Subject: [Maxima-discuss] elementary solve() problem
>>> 
>>> Caution: Non-NU Email
>>> 
>>> Apologies for this very novice question, but what am I doing wrong
>>> here?
>>> Why isn't Maxima giving n=2?
>>> 
>>> (%i18)  s: t**n;
>>> (s)     t^n
>>> (%i19)  diff(s,t);
>>> (%o19)  n*t^(n-1)
>>> (%i20)  s: t**n;
>>> (s)     t^n
>>> (%i21)  diff(s,t);
>>> (%o21)  n*t^(n-1)
>>> (%i23)  ev(%,t=10) = 2*ev(%,t=5);
>>> (%o23)  n*10^(n-1)=2*n*5^(n-1)
>>> (%i24)  solve(%,n);
>>> (%o24)  [n=0,10^(n-1)=2*5^(n-1)]
>>> 
>>> Many thanks, Richard
>>> 
>>> _______________________________________________
>>> Maxima-discuss mailing list
>>> Max...@li...
>>> 

Re: [Maxima-discuss] (get 'msetq 'mfexpr*)

[Raymond T. <toy...@gm...>]

On 11/17/25 7:39 AM, Eduardo Ochs wrote:

> Hi all,
>
> if we do this
>
>   to_lisp();
>     (describe 'msetq)
>     (get 'msetq 'mfexpr*)
>     (to-maxima)
>
> we see that the property `mfexpr*' of `msetq' (a.k.a. `:') is a
> function, that is printed as:
>
>   #<FUNCTION (LAMBDA (L) :IN
>    "/home/edrx/bigsrc/maxima/src/mlisp.lisp") {52C9D3DB}>
>
> Where is the code that sets that property?

You mean how does |msetq| get the property |mfexpr*|? If so, I think the 
only way is to grep the source code. I did |grep mfexpr src/*.lisp|. Of 
the many hits, I looked at |defmacro defmspec| in maxmac.lisp. This 
macro automatically sets the |mfexpr*| property.

In mlisp.lisp, there’s a |defmspec msetq|, so I think that’s what sets 
the property you’re looking for.

>
> Sorry for the weird question... I just learned how to single-step
> through Maxima functions using Slime, and I was trying to understand
> how lvalues work in cases like this one...
>
>   a1 : make_array(hashed);
>   a1[2]:3;
>
> ...by curiosity, and I couldn't find the answer by tracing and
> grepping...

Yeah, I always have problems tracing these kinds of things. But in this 
case if you look at the |defmspec| for |msetq|, you can see it calls 
|mset|. Thus, I’d trace |mset| instead. Thus:

|(%i24) :lisp (trace mset) (MSET) (%i24) a1:make_array(hashed); 0: (MSET 
$A1 #&lt;HASH-TABLE :TEST EQUAL :WEAK-P NIL :COUNT 1 {605B6F8D}&gt;) 0: 
MSET returned #&lt;HASH-TABLE :TEST EQUAL :WEAK-P NIL :COUNT 1 
{605B6F8D}&gt; (%o24) {Lisp Array: #&lt;HASH-TABLE :TEST EQUAL :WEAK-P 
NIL :COUNT 1 {605B6F8D}&gt;} (%i25) a1[2]:3; 0: (MSET (($A1 SIMP ARRAY) 
2) 3) 0: MSET returned 3 (%o25) 3 |

&#8203;

Re: [Maxima-discuss] probable bug in sqrt

[Michel T. <ta...@lp...>]

To substantiate prof. Fateman comment, i have slightly modified the 
original program to obtain the one attached below.

The only modifications are that the variables are called a,b,c,d,e,f  
and the variable d is renamed to u, for visibility. Of course this 
doesn't change anything, the bug is still here.  However i have also 
converted 4*sqrt(3)-7 to a new variable rad and  104*sqrt(3)-181 to 
rad2. Note that both are slightly negative, this may be part of the 
problem.  Anyways with these substitutions the program then works, 
either with the ordinary gcd or with subres, irrespective of the values 
of rad and rad2. One can observe that subres is much slower.

(%i1) batch("bug.mac");

read and interpret /home/michel/bug.mac
(%i2) kill(all)
(%i1) domain:complex
(%i2) eqs:[-(6*c*sqrt(rad2-rad*u))-3^(3/2)*g*u+4*g*u+(-71)*u+26*3^(3/2)*g
                                   +(-104)*g+544,
5*c*sqrt(rad2-rad*u)-6*b*sqrt(rad2-rad*u)+(-g)*sqrt(rad)*u
+(-3^(3/2))*f*u+4*f*u+26*u+26*g*sqrt(rad)
                                +26*3^(3/2)*f+(-104)*f+115,
-(c*sqrt(rad2-rad*u))+5*b*sqrt(rad2-rad*u)+(-6)*a*sqrt(rad2-rad*u)
+(-f)*sqrt(rad)*u+(-3^(3/2))*e*u+4*e*u-u
+26*f*sqrt(rad)+26*3^(3/2)*e+(-104)*e+66,
-(b*sqrt(rad2-rad*u))+5*a*sqrt(rad2-rad*u)+(-e)*sqrt(rad)*u
+(-3^(3/2))*d*u+4*d*u+(-2)*u+26*e*sqrt(rad)
                                 +26*3^(3/2)*d+(-104)*d-7,
            -(a*sqrt(rad2-rad*u))-d*sqrt(rad)*u+26*d*sqrt(rad)+2]
(%i3) unks:[e,d,c,b,a]
(%i4) sol:linsolve(eqs,unks)
(%i5) ze:ratsimp(subst(sol,eqs))
(%o5)                           [0, 0, 0, 0, 0]
(%o6)                        /home/michel/bug.mac

Le 11/11/2025 à 14:53, Richard Fateman a écrit :
> It is not that
> there is a bug in sqrt, but a complication resulting from how programs 
> deal with algebraic dependencies.

-- 
Michel Talon

Re: [Maxima-discuss] elementary solve() problem

[Stavros M. <mac...@gm...>]

load(to_poly_solve)$
%solve(...) is much better with roots

On Mon, Nov 17, 2025, 19:04 richard christian <rp...@cl...>
wrote:

>
> I also have this following one now...
> Is this a problem with solve(), or have I done something wrong?
>
>
> (%i107) y: sqrt(4-x**2);
> (y)     sqrt(4-x^2)
> (%i108) diff(y,x);
> (%o108) -(x/sqrt(4-x^2))
> (%i109) ev(%,x=-sqrt(2));
> (%o109) 1
> (%i110) diff(y,x)=1;
> (%o110) -(x/sqrt(4-x^2))=1
> (%i111) solve(%,x);
> (%o111) [x=-sqrt(4-x^2)]
>
>
>
> best, Richard
>
>
>
> On 2025-11-13 17:53, Stavros Macrakis wrote:
> > As Barton suggests, solve is weak in many ways. His %solve (in
> > to_poly_solve) is more powerful in many ways, but not all.
> >
> > Some simple cases that neither one handles:
> >
> > * x!=0
> > * x!=120
> > * sin(x)=x
> > * 2^x=5^x
> > * 7*2^x=5^x
> >
> > Many of these have easy solutions and also hard solutions with no
> > closed form. (Usually complex, but even some real ones: consider x!
> > for x<0 for example.) Many users would be delighted for solve to find
> > the easy solutions, even if it can't find the hard solutions.
> >
> > Tested in 5.48 SBCL 2.5.7 MacOS
> >
> > On Thu, Nov 13, 2025 at 10:39 AM Barton Willis via Maxima-discuss
> > <max...@li...> wrote:
> >
> >> The Maxima solve function needs improvement. Please don't get the
> >> impression that setting an obscure variable will fix all its
> >> shortcomings.
> >> Maybe somebody should experiment with making the default of
> >> solveradcan true.
> >> --Barton
> >>
> >> -------------------------
> >>
> >> From: richard christian <rp...@cl...>
> >> Sent: Thursday, November 13, 2025 5:33 AM
> >> To: Barton Willis <wi...@un...>
> >> Cc: max...@li...
> >> <max...@li...>
> >> Subject: Re: [Maxima-discuss] elementary solve() problem
> >>
> >> Caution: Non-NU Email
> >>
> >> Terrific. Thank you, Barton.
> >> And needless to say, apologies for the accidental repetition in the
> >> first 6 lines of my example...
> >>
> >> rc
> >>
> >> On 2025-11-13 11:23, Barton Willis wrote:
> >>> Try setting the option variable solveradcan to true before
> >> solving:
> >>>
> >>> (%i1) solveradcan : true$
> >>>
> >>> (%i2) solve(n*10^(n-1)=2*n*5^(n-1),n);
> >>> (%o2) [n=0,n=2]
> >>>
> >>> Alternatively, apply radcan before solving:
> >>>
> >>> (%i1) radcan(n*10^(n-1)=2*n*5^(n-1));
> >>> (%o1) 2^(n-1)*5^(n-1)*n=2*5^(n-1)*n
> >>>
> >>> (%i2) solve(%,n);
> >>> (%o2) [n=0,n=2]
> >>>
> >>> For a list of additional option variables (and a bunch of other
> >>> stuff) that affect how solve works, try
> >>>
> >>> (%i3) apropos (solve);
> >>>
> >>>
> >>
> > (%o3)
> [desolve,funcsolve,globalsolve,linsolve,linsolve_by_lu,linsolve_params,linsolvewarn,solve,solve_congruences,solvedecomposes,solveexplicit,solvefactors,
> >>>
> >>> Solvenullwarn,solveradcan,solvetrigwarn,tmlinsolve,to_poly_solve]
> >>>
> >>> Thanks for your interest in Maxima! If you have more questions,
> >> feel
> >>> free to ask.
> >>>
> >>> --Barton
> >>>
> >>> -------------------------
> >>>
> >>> From: richard christian <rp...@cl...>
> >>> Sent: Thursday, November 13, 2025 3:57 AM
> >>> To: max...@li...
> >>> <max...@li...>
> >>> Subject: [Maxima-discuss] elementary solve() problem
> >>>
> >>> Caution: Non-NU Email
> >>>
> >>> Apologies for this very novice question, but what am I doing wrong
> >>> here?
> >>> Why isn't Maxima giving n=2?
> >>>
> >>> (%i18)  s: t**n;
> >>> (s)     t^n
> >>> (%i19)  diff(s,t);
> >>> (%o19)  n*t^(n-1)
> >>> (%i20)  s: t**n;
> >>> (s)     t^n
> >>> (%i21)  diff(s,t);
> >>> (%o21)  n*t^(n-1)
> >>> (%i23)  ev(%,t=10) = 2*ev(%,t=5);
> >>> (%o23)  n*10^(n-1)=2*n*5^(n-1)
> >>> (%i24)  solve(%,n);
> >>> (%o24)  [n=0,10^(n-1)=2*5^(n-1)]
> >>>
> >>> Many thanks, Richard
> >>>
> >>> _______________________________________________
> >>> Maxima-discuss mailing list
> >>> Max...@li...
> >>>
>

[Maxima-discuss] (get 'msetq 'mfexpr*)

[Eduardo O. <edu...@gm...>]

Hi all,

if we do this

  to_lisp();
    (describe 'msetq)
    (get 'msetq 'mfexpr*)
    (to-maxima)

we see that the property `mfexpr*' of `msetq' (a.k.a. `:') is a
function, that is printed as:

  #<FUNCTION (LAMBDA (L) :IN
   "/home/edrx/bigsrc/maxima/src/mlisp.lisp") {52C9D3DB}>

Where is the code that sets that property?

Sorry for the weird question... I just learned how to single-step
through Maxima functions using Slime, and I was trying to understand
how lvalues work in cases like this one...

  a1 : make_array(hashed);
  a1[2]:3;

...by curiosity, and I couldn't find the answer by tracing and
grepping...

  Thanks in advance! =)
    Eduardo

Re: [Maxima-discuss] Help

[Jaime V. <vi...@fe...>]

Hello,

"Define" does not exist. You must write it as "define". And you don't 
need to use eval, just do tg(5,5)

Regards,

Jaime

On 11/17/25 14:59, Allan Payne wrote:
> Hi Folks
> I have small procedure. I expect it to give a number result for 
> tg(5,5) but get none. What have I done wrong?
>
> k:1;
> b:1;
> r1:1;
> r2:10;
> Define 
> (tg(r,t),((100*%pi*exp(2*k*t))/(b)*((1/(r1^(2))-1/(r^(2)))*log((r+r1)/(r-r1))+(1/(r*r1)-1/(r*r2))+(-1/(2*r1^(2))+1/(2*r2^(2))))));
> eval( tg,[5,5]);
>
> Thank you for your help.
> Rgds Allan Payne
>
>
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss

[Maxima-discuss] Help

[Allan P. <all...@gm...>]

Hi Folks
I have small procedure. I expect it to give a number result for tg(5,5) but
get none. What have I done wrong?

k:1;
b:1;
r1:1;
r2:10;
Define
(tg(r,t),((100*%pi*exp(2*k*t))/(b)*((1/(r1^(2))-1/(r^(2)))*log((r+r1)/(r-r1))+(1/(r*r1)-1/(r*r2))+(-1/(2*r1^(2))+1/(2*r2^(2))))));
eval( tg,[5,5]);

Thank you for your help.
Rgds Allan Payne

[Maxima-discuss] proposal for iterating over a hash table, was: How do I get the keys of a hash table in Maxima?

[Robert D. <rob...@gm...>]

On Fri, Nov 14, 2025 at 4:41 AM Stavros Macrakis <mac...@gm...> wrote:

> But that's pretty ugly. We should really have an easy way of iterating over a hasharray.

I think a suitable syntax for iterating over a hash table (either a
Lisp hash table, created by Maxima make_array(hashed), or a Maxima
hash table, i.e., a so-called undeclared array) is

for [k, v] in foo do ...

where foo is the hash table in question, and k and v are one key-value
pair. This is currently an error so implementing this doesn't change
any existing working code.

Expanding "for" to handle this case is no big deal. I will come up
with a proof of concept implementation.

There is also the possibility of creating a new function, say
maphash(lambda([k, v], ...), foo), but I would only want to do that if
we intend that maphash would return a new hash table, to make it
consistent with other Maxima map functions. Yes, I know, Common Lisp
MAPHASH doesn't act that way. It is much, much more important to make
a would-be maphash function consistent with other Maxima functions.

I think it is less common to want a new hash table returned, so I'm
leaning towards for [k, v] in foo do ... . Anyway creating a new hash
table is easy enough via for [k, v] in foo do bar[k]: somefunc(v), for
example.

What does anyone think about that?

Robert

Re: [Maxima-discuss] INSTALL.lisp: --end-toplevel-options not recognized

[Michel T. <ta...@lp...>]

I don't know but i see in man sbcl:

        Note  that  when running SBCL with the --core option, using a 
core file
        created by a user call to the  SB-EXT:SAVE-LISP-AND-DIE, the  
toplevel
        options  may  be  under the control of user code passed as 
arguments to
        SB-EXT:SAVE-LISP-AND-DIE. For this purpose, the 
--end-toplevel-options
        option  itself can be considered a toplevel option, i.e. the 
user core,
        at its option, may not support it.

Le 15/11/2025 à 23:37, Eduardo Ochs a écrit :
>
> The standard core recognizes all the command-line options but the
> custom one doesn't - and I don't know how to fix that myself.

-- 
Michel Talon

[Maxima-discuss] INSTALL.lisp: --end-toplevel-options not recognized

[Eduardo O. <edu...@gm...>]

Hi list,

the file INSTALL.lisp - a.k.a.
<https://sourceforge.net/p/maxima/code/ci/master/tree/INSTALL.lisp> -
says "User feedback on this procedure would be greatly appreciated",
so here it goes...

I tried to follow its instructions to build a maxima.core with
Quicklisp and some packages preloaded to save me some seconds
on startup, and the instructions worked modulo a small bug at
the end. Here are the details. I ran this, where the
`(find-maximagitfile ...)'s in comments are elisp hyperlinks
to positions to INSTALL.lisp to remind me where I am, so just
ignore them...:


--snip--snip--
cd ~/bigsrc/maxima/
sbcl
  ;; (find-maximagitfile "INSTALL.lisp" "(2)" "(3)" "(4)")
  (load "configure.lisp")
  (configure :interactive nil)
  (quit)

cd ~/bigsrc/maxima/src/
sbcl
  ;; (find-maximagitfile "INSTALL.lisp" "(5)" "(6)" "(7)")
  (load "maxima-build.lisp")
  (maxima-compile)
  (quit)

cd ~/bigsrc/maxima/src/
sbcl
  ;; (find-maximagitfile "INSTALL.lisp" "(8)" "(9a)" "(9b)")
  (load "maxima-build.lisp")
  (maxima-load)
  (cl-user::run)
  to_lisp();
    (in-package :common-lisp-user)
    ;;
    ;; Optional: load quicklisp and some packages
    (load #P"~/quicklisp/setup.lisp")
    (ql:quickload :cffi)
    (ql:quickload "str")
    ;;
    (in-package :maxima)
    (common-lisp-user::maxima-dump)

~/bigsrc/maxima/bin/src/maxima --directories
~/bigsrc/maxima/bin/src/maxima
  to_lisp();
    (describe 'str:join)
    (to-maxima)
  quit();
--snip--snip--


The bug: when I ran ~/bigsrc/maxima/bin/src/maxima it displayed this,


--snip--snip--
/home/edrx/bigsrc/maxima/src(edrx:sc)# ~/bigsrc/maxima/bin/src/maxima
Warning: argument end-toplevel-options not recognized.
Warning: argument eval not recognized.
Loading /home/edrx/.maxima/maxima-init.lisp
Loading /home/edrx/.maxima/maxima-init.mac
Maxima restarted.
(%i2)
--snip--snip--


instead of running `maxima-banner' and displaying this:


--snip--snip--
/home/edrx/e(edrx:sc)# maxima
Loading /home/edrx/.maxima/maxima-init.lisp
Loading /home/edrx/.maxima/maxima-init.mac
Maxima branch_5_48_base_222_g66001dab3 https://maxima.sourceforge.io
using Lisp SBCL 2.1.1.debian
Distributed under the GNU Public License. See the file COPYING.
Dedicated to the memory of William Schelter.
The function bug_report() provides bug reporting information.
(%i1)
--snip--snip--


I checked how ~/bigsrc/maxima/bin/src/maxima was calling SBCL by
running the shell commands below in another terminal while Maxima was
running,


--snip--snip--
(eepitch-shell3)
(eepitch-kill)
(eepitch-shell3)
getpids () { ps -C $1 -o pid=; }
getcmdline () { cat /proc/$1/cmdline | tr '\0' ' '; echo }
getcmdlines () { for i in $(getpids sbcl); do getcmdline $i; done; }
getpids     sbcl
getcmdlines sbcl
--snip--snip--


and what I got, modulo ""s and \\s, was:

  sbcl --core /home/edrx/bigsrc/maxima/src/binary-sbcl/maxima.core \
    --noinform --end-runtime-options --eval "(cl-user::run)" \
    --end-toplevel-options

  sbcl --core \

/usr/local/lib/maxima/branch_5_48_base_222_g66001dab3/binary-sbcl/maxima.core
\
    --noinform --end-runtime-options --eval "(cl-user::run)" \
    --end-toplevel-options

The standard core recognizes all the command-line options but the
custom one doesn't - and I don't know how to fix that myself.

  Cheers! =)
    Eduardo Ochs
    https://anggtwu.net/eev-maxima.html

Re: [Maxima-discuss] sqrt, division by zero, radcan, integrate ..

[Stavros M. <mac...@gm...>]

On Sat, Nov 15, 2025 at 1:45 PM Richard Fateman <fa...@gm...> wrote:

> ...
> 4. You may also  encounter situations where Maxima gives a result for
> sqrt() involving abs.
>   For example sqrt((1-k)^2)  returns |k-1|.  I think this is a  bug,
> others think it is a feature.
>

With *domain=complex*, this simplification isn't performed. This is a bit
confusing, because of course *real* numbers have two square roots, too.

That setting only applies to symbolic arguments. *sqrt(4)* and
*sqrt(-1) *continue
to be *2* and *%i.*

Still, *sqrt(%i) *is *(-1)^(1/4)*, regardless of the setting of *domain*.

*rectform *etc. are forced to choose a branch.

[Maxima-discuss] sqrt, division by zero, radcan, integrate ..

[Richard F. <fa...@gm...>]

Consider d: sqrt(c^2-2*c+1)-c+1.
radcan(d) produces 0.   notice that (1-c)^2 = (c-1)^2=  c^2-2*c+1

d, c=4 returns 0, confirming that result from radcan().

d,c=-4 returns 10, contradicting that result.  (read up about radcan... )

integrate(1/d,c)  gives quotient by zero.
integrate(d,c) gives a large expression E,   radcan(E) produces 1/2.   [
integrate(0,c) produces 0, differs by a constant so it is also OK]

What's going on here?
1. There are two different square roots.  Maxima's radcan() will choose
one, if forced to do so.
2. Division by zero is sometimes concealed initially, but some operations
(like integration, radcan) reveal it.
3.  There are features in Maxima to support computation with algebraic
integers. See tellrat().
4. You may also  encounter situations where Maxima gives a result for
sqrt() involving abs.
  For example sqrt((1-k)^2)  returns |k-1|.  I think this is a  bug, others
think it is a feature.
5. If you really want to compute with algebraic numbers, try to give them
names, say a1, a2, ... and compute
with those names.  You can also use tellrat()  and algebraic:true to
control the simplification.
Just typing in sqrt(), or more generally   E^(p/q)  for rational p/q,
suggests that you have something in mind,
but probably have not conveyed that understanding to Maxima.
A bit of thought.
You may think it is obvious that 1^(1/8) is 1.  Indeed, if you solve
(y=1^(1/8),y) you get y=1.
But solve(y^8=1,1) gives 8 solutions.  One is y=1. This is not the most
general solution. The full set is

[y=(sqrt(2)*%i+sqrt(2))/2,
y=%i,
y=(sqrt(2)*%i-sqrt(2))/2,
y=-1,
y=-((sqrt(2)*%i+sqrt(2))/2),
y=-%i,
y=-((sqrt(2)*%i-sqrt(2))/2),
y=1]

Choosing the first gives you more generality, as y^2, y^3, ... cycle
through the roots.

All this is not to say you must know so much about algebra, but it
sometimes happens that
the answer to a relatively simple question that can be posed in elementary
algebra involves
more advanced math.  Imagine someone who has not yet learned about complex
numbers
asking Maxima sqrt(-1), and not understanding the result... pointing out
that the numerical
math library gives an error message, not %i.

Rjf

Re: [Maxima-discuss] probable bug in sqrt

[Oscar B. <osc...@gm...>]

On Sun, 9 Nov 2025 at 16:44, Igor Pesando <ipe...@gm...> wrote:
>
> Hi*,
>
> I have a linear system of 5 eqs in 7 unknows cA[1]... cA[7]
>
> The system depends also on a parameter d.
>
> I solve the system for 5 unknowns cA[1] .. cA[5].
>
> So the solution depends on cA[6], cA[7] and d.
>
> I substitute back and I do not find zero, one of the reason I cannot
> convince maxima to simplify expressions containing sqrt(7 - 4 *sqrt(3)).
>
> So I substitute some values of d and I still do not get zero.
>
> Since I know the solution of the system for d=26 and I noticed that
> substituting d=26 before solving or after solving yields some sign
> differences

The particular case d=26 is degenerate for this system. If you write
the linear equations as Ax = b with 5x5 matrix A then the determinant
of A is:

72*(45 - 26*sqrt(3))*(d - 26)^2*(d - 19 + 4*sqrt(3))^(3/2)

If either d = 26 or d = 19 - 4*sqrt(3) then the determinant is zero.
Otherwise for generic values of d the determinant is nonzero. I'm not
sure how linsolve handles that case in general but I assume that it
returns a result that gives the unique solution for generic values of
d but is invalid for the degenerate values i.e. not valid for d=26.

You can see a simpler example of this:

(%i8) linsolve([a*x - b], [x]);
(%o8) [x = b/a]

This is valid for a != 0 but invalid in the degenerate case that a = 0.

--
Oscar

Re: [Maxima-discuss] probable bug in sqrt

[Richard F. <fa...@gm...>]

for example,
:lisp (cquotient 2 3)
produces the same message.
Evaluating this in the top-level context may be
why the tag  RAT-ERR  does not exist.
RJF



On Sat, Nov 15, 2025 at 6:02 AM David Scherfgen via Maxima-discuss <
max...@li...> wrote:

> Michel Talon <ta...@lp...>:
>
>> I think there is definitely a bug here: tracing the function cquotient
>> shows there are a lot of calls to cquotient which work OK and then a last
>> one which bombs out. This can be reproduced in a fresh maxima session:
>>
>> (%i1) :lisp(MAXIMA::CQUOTIENT 188021706981212160 -32188114592695296)
>> Maxima encountered a Lisp error:
>>  attempt to THROW to a tag that does not exist: RAT-ERR
>>
> I have difficulty in understanding how this is not a bug in maxima or how
>> this bug is related to algebraic dependencies. Maybe the numbers are too
>> big for some reason.
>>
> This is by design.
> The comment above cquotient says:
>
> ;; If MODULUS is nil, then we work over the ring of integers when A and B
> are
> ;; integers, and raise a RAT-ERROR if A is not divisible by B.
>
> Best regards
> David
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>

Re: [Maxima-discuss] probable bug in sqrt

[David S. <d.s...@go...>]

Michel Talon <ta...@lp...>:

> I think there is definitely a bug here: tracing the function cquotient
> shows there are a lot of calls to cquotient which work OK and then a last
> one which bombs out. This can be reproduced in a fresh maxima session:
>
> (%i1) :lisp(MAXIMA::CQUOTIENT 188021706981212160 -32188114592695296)
> Maxima encountered a Lisp error:
>  attempt to THROW to a tag that does not exist: RAT-ERR
>
I have difficulty in understanding how this is not a bug in maxima or how
> this bug is related to algebraic dependencies. Maybe the numbers are too
> big for some reason.
>
This is by design.
The comment above cquotient says:

;; If MODULUS is nil, then we work over the ring of integers when A and B
are
;; integers, and raise a RAT-ERROR if A is not divisible by B.

Best regards
David

Re: [Maxima-discuss] probable bug in sqrt

[Michel T. <ta...@lp...>]

Le 13/11/2025 à 18:24, Michel Talon a écrit :
>
>
> (%i5) soAT:linsolve(eqsAT, unksAT);
> CQUOTIENT: quotient is not exact
>  -- an error. To debug this try: debugmode(true);
>
> Commenting out domain:complex doesn't help. The message CQUOTIENT: 
> quotient is not exact is produced in rat3a.lisp, and means that the 
> remainder of an euclidean division does not vanish when it should. By 
> the way, the subresultant algorithm for computing gcds is supposed to 
> be absolutely sure if  slower than the standard one.
>
> Le 11/11/2025 à 14:53, Richard Fateman a écrit :
>> The earlier bug reports describe the situation in detail.  It is not that
>> there is a bug in sqrt, but a complication resulting from how 
>> programs deal with algebraic dependencies.


I think there is definitely a bug here: tracing the function cquotient 
shows there are a lot of calls to cquotient which work OK and then a 
last one which bombs out. This can be reproduced in a fresh maxima session:

 > maxima
Loading /home/michel/.maxima/maxima-init.mac
Maxima 5.48.1 https://maxima.sourceforge.io
using Lisp SBCL 2.5.8

(%i1) :lisp(MAXIMA::CQUOTIENT 188021706981212160 -32188114592695296)

Maxima encountered a Lisp error:

  attempt to THROW to a tag that does not exist: RAT-ERR

Automatically continuing.
To enable the Lisp debugger set *debugger-hook* to nil.
(%i1)

I have difficulty in understanding how this is not a bug in maxima or 
how this bug is related to algebraic dependencies. Maybe the numbers are 
too big for some reason.


-- 
Michel Talon

Re: [Maxima-discuss] How do I get the keys of a hash table in Maxima?

[Eduardo O. <edu...@gm...>]

Oops, I missed that! Thanks!

  myhash : make_array(hashed);
  myhash[42] : 420;
  myhash[ab] : "abab";
  myhash[42];                 /* 420 */
  myhash[ab];                 /* "abab" */
  myhash[cd];                 /* false */
  rest(arrayinfo(myhash),2);  /* [42, ab] */

Cheers,
  E. =)

On Fri, 14 Nov 2025 at 09:39, Stavros Macrakis <mac...@gm...> wrote:

> *arrayinfo*
>
> But that's pretty ugly. We should really have an easy way of iterating
> over a hasharray.
>
>
> On Fri, Nov 14, 2025, 02:22 Eduardo Ochs <edu...@gm...> wrote:
>
>> Hi list,
>>
>> how do I get the keys of a hash table in Maxima?
>> Or, more concretely, if we run this,
>>
>>   myhash : make_array(hashed);
>>   myhash[42] : 420;
>>   myhash[ab] : "abab";
>>   myhash[42];           /* 420 */
>>   myhash[ab];           /* "abab" */
>>   myhash[cd];           /* false */
>>   to_lisp();
>>     (loop for k being the hash-keys in #$myhash$
>>           collect k)
>>     (loop for k being the hash-keys in #$myhash$
>>           if (not (eq k 'dim1))
>>           collect k)
>>     (to-maxima)
>>
>> The first LOOP returns (DIM1 42 $AB) and the second one
>> returns (42 $AB)... but is there a standard way to get
>> something like the result of the second loop without using
>> Lisp?
>>
>> Some links:
>>
>> (info "(maxima)make_array")
>>
>> https://maxima.sourceforge.io/docs/manual/Data-Types-and-Structures.html#index-make_005farray
>> https://sourceforge.net/p/maxima/code/ci/master/tree/src/ar.lisp
>>
>> Thanks in advance!
>>   Eduardo Ochs
>>   https://anggtwu.net/eev-maxima.html
>>
>> _______________________________________________
>> Maxima-discuss mailing list
>> Max...@li...
>> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>>
>

Re: [Maxima-discuss] How do I get the keys of a hash table in Maxima?

[Stavros M. <mac...@gm...>]

*arrayinfo*

But that's pretty ugly. We should really have an easy way of iterating over
a hasharray.


On Fri, Nov 14, 2025, 02:22 Eduardo Ochs <edu...@gm...> wrote:

> Hi list,
>
> how do I get the keys of a hash table in Maxima?
> Or, more concretely, if we run this,
>
>   myhash : make_array(hashed);
>   myhash[42] : 420;
>   myhash[ab] : "abab";
>   myhash[42];           /* 420 */
>   myhash[ab];           /* "abab" */
>   myhash[cd];           /* false */
>   to_lisp();
>     (loop for k being the hash-keys in #$myhash$
>           collect k)
>     (loop for k being the hash-keys in #$myhash$
>           if (not (eq k 'dim1))
>           collect k)
>     (to-maxima)
>
> The first LOOP returns (DIM1 42 $AB) and the second one
> returns (42 $AB)... but is there a standard way to get
> something like the result of the second loop without using
> Lisp?
>
> Some links:
>
> (info "(maxima)make_array")
>
> https://maxima.sourceforge.io/docs/manual/Data-Types-and-Structures.html#index-make_005farray
> https://sourceforge.net/p/maxima/code/ci/master/tree/src/ar.lisp
>
> Thanks in advance!
>   Eduardo Ochs
>   https://anggtwu.net/eev-maxima.html
>
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>

[Maxima-discuss] How do I get the keys of a hash table in Maxima?

[Eduardo O. <edu...@gm...>]

Hi list,

how do I get the keys of a hash table in Maxima?
Or, more concretely, if we run this,

  myhash : make_array(hashed);
  myhash[42] : 420;
  myhash[ab] : "abab";
  myhash[42];           /* 420 */
  myhash[ab];           /* "abab" */
  myhash[cd];           /* false */
  to_lisp();
    (loop for k being the hash-keys in #$myhash$
          collect k)
    (loop for k being the hash-keys in #$myhash$
          if (not (eq k 'dim1))
          collect k)
    (to-maxima)

The first LOOP returns (DIM1 42 $AB) and the second one
returns (42 $AB)... but is there a standard way to get
something like the result of the second loop without using
Lisp?

Some links:

(info "(maxima)make_array")
https://maxima.sourceforge.io/docs/manual/Data-Types-and-Structures.html#index-make_005farray
https://sourceforge.net/p/maxima/code/ci/master/tree/src/ar.lisp

Thanks in advance!
  Eduardo Ochs
  https://anggtwu.net/eev-maxima.html

Re: [Maxima-discuss] probable bug in sqrt

[Richard F. <fa...@gm...>]

My belief is the bug is caused by not recognizing algebraic dependencies.
The gcd algorithms are not at fault.  There are no bug examples with simple
variables x,y,z,....
Nor is linsolve at fault with simple variables.

Loo at newvar and friends..
RJF



On Thu, Nov 13, 2025, 12:24 PM Michel Talon <ta...@lp...> wrote:

> In fact i still think there is a bug somewhere. Seeing there is a
> "linsolve" involved, and remembering that there is a problem in linsolve
> related to gcd computations, because it uses a complicated algorithm to
> avoid producing unnecessary huge denominators, i have tried to change the
> gcd algorithm to  other values and i found that the computation then
> crashes - so there is indeed a bug in linsolve in this particular case.
>
> With the same program given by Igor in his first message, adding
> gcd:subres before linsolve i get:
>
>
> (%i3) unksAT:[cA[5],cA[4],cA
> <https://www.google.com/maps/search/5%5D,cA%5B4%5D,cA?entry=gmail&source=g>
> [3],cA[2],cA[1]]$
>
> (%i4) gcd:subres$
>
> (%i5) soAT:linsolve(eqsAT, unksAT);
> CQUOTIENT: quotient is not exact
>  -- an error. To debug this try: debugmode(true);
>
> Commenting out domain:complex doesn't help. The message CQUOTIENT:
> quotient is not exact is produced in rat3a.lisp, and means that the
> remainder of an euclidean division does not vanish when it should. By the
> way, the subresultant algorithm for computing gcds is supposed to be
> absolutely sure if  slower than the standard one.
> Le 11/11/2025 à 14:53, Richard Fateman a écrit :
>
> The earlier bug reports describe the situation in detail.  It is not that
> there is a bug in sqrt, but a complication resulting from how programs
> deal with algebraic dependencies.
>
> --
> Michel Talon
>
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>

Re: [Maxima-discuss] elementary solve() problem

[Stavros M. <mac...@gm...>]

As Barton suggests, *solve* is weak in many ways. His *%solve *(in
*to_poly_solve*) is more powerful in many ways, but not all.

Some simple cases that neither one handles:

* *x!=0*
** x!=120*
* *sin(x)=x*
** 2^x=5^x*
* *7*2^x=5^x*

Many of these have easy solutions and also hard solutions with no closed
form. (Usually complex, but even some real ones: consider *x!* for *x<0* for
example.) Many users would be delighted for *solve *to find the easy
solutions, even if it can't find the hard solutions.

Tested in 5.48 SBCL 2.5.7 MacOS

On Thu, Nov 13, 2025 at 10:39 AM Barton Willis via Maxima-discuss <
max...@li...> wrote:

>
> The Maxima solve function needs improvement. Please don't get the
> impression that setting an obscure variable will fix all its shortcomings.
> Maybe somebody should experiment with making the default of solveradcan
>  true.
> --Barton
>
> ------------------------------
> *From:* richard christian <rp...@cl...>
> *Sent:* Thursday, November 13, 2025 5:33 AM
> *To:* Barton Willis <wi...@un...>
> *Cc:* max...@li... <
> max...@li...>
> *Subject:* Re: [Maxima-discuss] elementary solve() problem
>
> Caution: Non-NU Email
>
>
> Terrific. Thank you, Barton.
> And needless to say, apologies for the accidental repetition in the
> first 6 lines of my example...
>
> rc
>
> On 2025-11-13 11:23, Barton Willis wrote:
> > Try setting the option variable solveradcan to true before solving:
> >
> >  (%i1) solveradcan : true$
> >
> >  (%i2) solve(n*10^(n-1)=2*n*5^(n-1),n);
> >  (%o2) [n=0,n=2]
> >
> >  Alternatively, apply radcan before solving:
> >
> >  (%i1) radcan(n*10^(n-1)=2*n*5^(n-1));
> >  (%o1) 2^(n-1)*5^(n-1)*n=2*5^(n-1)*n
> >
> >  (%i2) solve(%,n);
> >  (%o2) [n=0,n=2]
> >
> >  For a list of additional option variables (and a bunch of other
> > stuff) that affect how solve works, try
> >
> >  (%i3) apropos (solve);
> >
> > (%o3)
> [desolve,funcsolve,globalsolve,linsolve,linsolve_by_lu,linsolve_params,linsolvewarn,solve,solve_congruences,solvedecomposes,solveexplicit,solvefactors,
> >
> >  Solvenullwarn,solveradcan,solvetrigwarn,tmlinsolve,to_poly_solve]
> >
> >  Thanks for your interest in Maxima! If you have more questions, feel
> > free to ask.
> >
> >  --Barton
> >
> > -------------------------
> >
> > From: richard christian <rp...@cl...>
> > Sent: Thursday, November 13, 2025 3:57 AM
> > To: max...@li...
> > <max...@li...>
> > Subject: [Maxima-discuss] elementary solve() problem
> >
> > Caution: Non-NU Email
> >
> > Apologies for this very novice question, but what am I doing wrong
> > here?
> > Why isn't Maxima giving n=2?
> >
> > (%i18)  s: t**n;
> > (s)     t^n
> > (%i19)  diff(s,t);
> > (%o19)  n*t^(n-1)
> > (%i20)  s: t**n;
> > (s)     t^n
> > (%i21)  diff(s,t);
> > (%o21)  n*t^(n-1)
> > (%i23)  ev(%,t=10) = 2*ev(%,t=5);
> > (%o23)  n*10^(n-1)=2*n*5^(n-1)
> > (%i24)  solve(%,n);
> > (%o24)  [n=0,10^(n-1)=2*5^(n-1)]
> >
> > Many thanks, Richard
> >
> > _______________________________________________
> > Maxima-discuss mailing list
> > Max...@li...
> >
> https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/maxima-discuss__;!!PvXuogZ4sRB2p-tU!AHGAk7NlanJPbiPzOCvfT6cKkVSALivLV8W_2kJZ_1zbIZSyVluWjP4HKlQV7DKLKiC8HDD9EecjLylJKPE$
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>