maxima-discuss — Maxima discussion list

[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
>

Re: [Maxima-discuss] probable bug in sqrt

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

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[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

Re: [Maxima-discuss] Basic simplify question

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

There are lots of ways to get the result you want manually:

*x*multthru(tst/x) *-- Ray's suggestion

*multthru *only operates on the top level of the expression, so is more
"precise" than *expand*

*substpart(multthru(piece),factor(tst),[1,2])*

this post-processes the result of *factor*

*rembox(factor(substpart(box(piece),tst,1,1)))*

this is essentially Fateman's solution, using *box* instead of variable
substitution

*rembox(factor(substpart(box(piece),tst,1,1,2)))*

more narrowly targeted version of the same

There's also the *format* subsystem, though I'm not very familiar with it.


On Mon, Nov 10, 2025 at 10:31 AM Richard Fateman <fa...@gm...> wrote:

>  I agree with Ray on this. Note that
> factor operates on the rational form of tst, and
> rat(tst) produces
>
> (x*%e^cos(x+1)+x)/%e^cos(x+1)
>
> in essence, the exp(-cos(x+1))     is "simplified"   to  1/ exp(cos(x+1))
> before factoring.
>
> If the user wants exp(-cos(x+1))  to be treated as a single unit, then use
> a symbol,
> like emcosxp1   for manipulation,  at least until such time as some
> property
> related to x  or cos ... is needed.
>
> factor( x* emcosxp1+x)  produces what you might expect.
>
> RJF
>
>
> On Mon, Nov 10, 2025 at 9:02 AM Raymond Toy <toy...@gm...> wrote:
>
>>
>> On 11/10/25 1:35 AM, Gunter Königsmann via Maxima-discuss wrote:
>>
>> Dear all,
>>
>> A colleague of mine has asked me how to factor out the x in
>>
>> tst:x*exp(-cos(x+1))+x;
>>
>> factor(tst) factorizes the exp() function, as well, which doesn't meet my
>> colleague's idea of "simple".
>>
>> He wants the result to be `x*(1+exp(-cos(x+1))`?
>>
>> I thought maybe `factorout` would do this, but it doesn't.
>>
>> I've generally given up on finding ways to make Maxima produce the form I
>> want and just accept what Maxima produces.  If I really, really want a
>> certain form, I just do it by hand.  In this case, do `x*expand(tst/x)`.
>> Sometimes it's just easier to do by hand instead of spending minutes or
>> hours trying to figure out how to get Maxima to do it.  Especially if it's
>> just a one-time change.
>>
>>
>> _______________________________________________
>> Maxima-discuss mailing list
>> Max...@li...
>> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>>
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>

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

[Barton W. <wi...@un...>]

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$

Re: [Maxima-discuss] Basic simplify question

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

On 11/11/25 6:01 AM, Michel Talon wrote:

> Fantastic! I have noted that demo(format) doesn't work on maxima 
> 5.48.1 because the search path for demos
>
> doesn't include subdirectories of share/contrib. It would be nice to 
> correct that.
>
> file_search_demo; --> [/usr/local/share/maxima/5.48.1/share/**/*.dem,  ..]
>
> which doesn't match share/contrib/format/format.demo.
>
Ah, we forgot to include the extension "demo" in the search pattern. 
I'll update it soon.

​

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

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

On 11/13/25 3:33 AM, richard christian wrote:

>
> Terrific. Thank you, Barton.
> And needless to say, apologies for the accidental repetition in the 
> first 6 lines of my example...
But do be careful with radcan in other situations. It makes assumptions 
when doing simplifications and can return results with the opposite sign 
of what you might expect.
>
> 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
&#8203;

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

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

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$

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

[Barton W. <wi...@un...>]

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] elementary solve() problem

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

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

Re: [Maxima-discuss] Basic simplify question

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

On Tue, Nov 11, 2025 at 6:03 AM Michel Talon <ta...@lp...> wrote:

> Fantastic! I have noted that demo(format) doesn't work on maxima 5.48.1 because the search path for demos doesn't include subdirectories of share/contrib. It would be nice to correct that.
>
> file_search_demo; --> [/usr/local/share/maxima/5.48.1/share/**/*.dem,  ..]

I dunno -- doesn't the double asterisk indicate all subdirectories, at
any depth?

For the record, I tried demo("format.demo") with 5.48.1 on macOS and
on Ubuntu Linux, and it worked as expected.

HTH

Robert

Re: [Maxima-discuss] alias, reversealias, and carg

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

On 11/9/25 7:37 AM, Raymond Toy wrote:

> On 11/9/25 4:52 AM, Barton Willis wrote:
>
>>  *
>>     Is this with the very latest version? I modified the simplifier
>>     for cabs just a day or two ago.
>>
>>
>> Yes, I did this with a current build—one that uses 
>> |def-simplifier| for |cabs: |
>>
>> (%i2) 'cabs(x*y);
>>
>> 0> Calling (SIMP-%CABS ((%CABS) ((MTIMES SIMP) $X $Y)) 1 NIL)
>> <0 SIMP-%CABS returned ((MABS SIMP) ((MTIMES SIMP) $X $Y))
>> (%o2)                    abs(x y)
>>
>> Maxima 5.47 also has this bug.
>
> Here is an updated cabs simplifier. This passes the testsuite and 
> fixes the above error. I'm not convinced this is the right thing to 
> do, though. I think for this to work, you also have to comment out the 
> defmfun $cabs.
>
I cleaned the simplifier up a bit and think I'll commit the change. It 
doesn't cause any regressions in the test suite and does fix the bug above.

I'm still not sure it's the right thing, but it does make it consistent 
with just about all the other simplifiers, so that's a win.

> |(def-simplifier cabs (z) (flet (($cabs (xx) (cabs xx))) (let ((sgn 
> nil)) (cond ((member (setq sgn ($csign z)) '($complex $imaginary)) 
> (cond ((complex-number-p ($expand z) 'bigfloat-or-number-p) ($cabs z)) 
> (t ($cabs z)))) ((eq sgn '$zero) 0) ((member sgn '($pos $pz)) z) ((eq 
> sgn '$neg) (mul -1 z)) (t ($cabs z)))))) |
>
> This could use a bit of cleanup as well.
>
> &#8203;
&#8203;

Re: [Maxima-discuss] probable bug in sqrt

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

Le 09/11/2025 à 17:42, Igor Pesando a écrit :
> 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
>
> I guess the issue is in sqrt. By the w

By the way, if one fixes explicit values for d, and one adds a ratsimp 
at the end, the program works ok. For example

(%i1) domain:complex$

(%i2) d:1234;
(%o2)                                1234
(%i3) eqsAT: [
....................................
]$

(%i4) unksAT:[cA[5],cA[4],cA[3],cA[2],cA[1]]$

(%i5) soAT:linsolve(eqsAT, unksAT)$

(%i6) zeAT:ratsimp(subst(soAT, eqsAT));
(%o6)                           [0, 0, 0, 0, 0]
(%i7)

I have tried with many values of d it always work OK.


-- 

Michel Talon

[Maxima-discuss] Fwd: probable bug in sqrt

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

To make this suggestion more explicit, the file rat3e.lisp has the lisp
program putonvlist.
It is called when a new kernel variable is put on varlist.
You can see how it is defined, and how it is used, in that file.
 trace(?putonvlist);
[putonvlist]
rat(x+y+sqrt(x*y));

1" Enter "putonvlist" "[x]
1" Exit  "putonvlist" "false
1" Enter "putonvlist" "[y]
1" Exit  "putonvlist" "false
1" Enter "putonvlist" "[sqrt(x*y)]
1" Exit  "putonvlist" "false
sqrt(x*y)+y+x

The first draft of this code (rational function package)
was written by Prof. William Martin at MIT. Subsequently revised by me,
(1968 or so)  and then embroidered by others to add features for
algebraic factoring, tellrat, and related functionality.

Good luck


On Tue, Nov 11, 2025 at 4:33 PM Richard Fateman <fa...@gm...> wrote:

> Here's a suggestion for understanding this problem, and realizing that all
> these various command-level programs have similar basic
> needs.
>
> The program newvar is used to look at an expression E in general form, and
> collect all 'new' variables within E.
> Thus  E=x+y+x^2 results in varlist containing x, y.  not x^2.    E=x^2+y
> similarly collects x, y.
> E=x+sqrt(x)  collects   x, sqrt(x).
>
> My suggestion is to instrument  newvar, newvar1, or some part of it so
> that, if a flag
> "show me new variables"  is set to true,  each time newvar adds a new
> symbol to the varlist, it
> displays for the user some message like
>   now adding sqrt(x+u+3) to the varlist, which currently has u, v, x.  Is
> this new variable algebraically
> dependent on the varlist?  If not, click "ok".  Otherwise click "not_ok"
> and Maxima will return to
> the top level so you can restructure your input.
>
> This should not be too hard.  Unfortunately it doesn't cure the issue,
> which is that computing with
> algebraically dependent variables without understanding the dependencies
> is dangerous.
>
>
> RJF
>
>
>
> On Tue, Nov 11, 2025 at 10:21 AM Michel Talon <ta...@lp...>
> wrote:
>
>> I have run the considered program with all sort of inclusions of
>> sqrtdenest , radcan, etc.  without getting the correct result. However if i
>> convert all equations to floating values, as you advocate, then the program
>> gets correct results.
>>
>> eqsAT:ev(eqsAT,numer,float); ---> yields complicated expressions such as
>> (0.07179676972449123 d - 0.8667160128367755)^0.5
>>
>> soAT:linsolve(eqsAT, unksAT)$
>>
>> zeAT:subst(soAT, eqsAT);  ----> yields complicated expressions, but
>>
>> ratsimp(zeAT);   ---->  yields  [0, 0, 0, 0, 0]
>>
>> So it is quite puzzling that maxima is able to find the simplifications
>> when part of the coefficients have been converted to floats, but not when
>> they are left litteral. From my very modest experience with maxima, maple
>> and mathematica, these programs become very awkward when radicals are
>> involved, and it is the a question of luck to get at results which can be
>> obtained quite easily by hand.
>>
>>
>> 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] probable bug in sqrt

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

Here's a suggestion for understanding this problem, and realizing that all
these various command-level programs have similar basic
needs.

The program newvar is used to look at an expression E in general form, and
collect all 'new' variables within E.
Thus  E=x+y+x^2 results in varlist containing x, y.  not x^2.    E=x^2+y
similarly collects x, y.
E=x+sqrt(x)  collects   x, sqrt(x).

My suggestion is to instrument  newvar, newvar1, or some part of it so
that, if a flag
"show me new variables"  is set to true,  each time newvar adds a new
symbol to the varlist, it
displays for the user some message like
  now adding sqrt(x+u+3) to the varlist, which currently has u, v, x.  Is
this new variable algebraically
dependent on the varlist?  If not, click "ok".  Otherwise click "not_ok"
and Maxima will return to
the top level so you can restructure your input.

This should not be too hard.  Unfortunately it doesn't cure the issue,
which is that computing with
algebraically dependent variables without understanding the dependencies is
dangerous.


RJF



On Tue, Nov 11, 2025 at 10:21 AM Michel Talon <ta...@lp...>
wrote:

> I have run the considered program with all sort of inclusions of
> sqrtdenest , radcan, etc.  without getting the correct result. However if i
> convert all equations to floating values, as you advocate, then the program
> gets correct results.
>
> eqsAT:ev(eqsAT,numer,float); ---> yields complicated expressions such as
> (0.07179676972449123 d - 0.8667160128367755)^0.5
>
> soAT:linsolve(eqsAT, unksAT)$
>
> zeAT:subst(soAT, eqsAT);  ----> yields complicated expressions, but
>
> ratsimp(zeAT);   ---->  yields  [0, 0, 0, 0, 0]
>
> So it is quite puzzling that maxima is able to find the simplifications
> when part of the coefficients have been converted to floats, but not when
> they are left litteral. From my very modest experience with maxima, maple
> and mathematica, these programs become very awkward when radicals are
> involved, and it is the a question of luck to get at results which can be
> obtained quite easily by hand.
>
>
> 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
>