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