maxima-discuss — Maxima discussion list

Re: [Maxima-discuss] [EXTERNAL] Re: 1-button calculator ~ "all elementary fns from a single operator"

[Henry B. <hb...@pi...>]

OK, I downloaded the "EML compiler" from here:

https://github.com/VA00/SymbolicRegressionPackage/tree/master

The EML compiler requires python3 & numpy (and probably other stuff that I might already have installed).

I then did a trivial script to convert from Mathematica expressions to Maxima expressions.

EML requires that log(0)=minf, so I defined mylog(x):=if (x=0) then minf else log(x), and used mylog(x) instead of log(x) in the definition of eml.

However, I now require that %e^minf = 0.

What is the magic in Maxima to make this happen?  I did "? minf", but that didn't provide any help.

-----Original Message-----
From: Henry Baker <hb...@pi...>
Sent: May 1, 2026 11:23 AM
To: Przemek Klosowski via Maxima-discuss <max...@li...>
Subject: Re: [Maxima-discuss] [EXTERNAL] Re: 1-button calculator ~ "all elementary fns from a single operator"

Obviously, Google was confused.

Q: If z = exp(x)-log(y), then x = log(z + log(y)) might look a tad better ? Is this log(z+log(y)) function universal in the same sense as eml() ?

Q: if we have a 1BC expression for f(x)=y, can we then trivially compute x=f^-1(y) ?

Q: The 1BC paper seems to want to rely on functions defined over the reals; I suspect that functions defined over the complex numbers might give additional 1BC results that might be prettier ? Perhaps the constant %pi*%i might work to force things into the complex plane ?

Q: I've always had a fondness for asinh(x), as it is bijective onto the reals, and has many of the same properties/characteristics as "gradual underflow" floating point numbers. I'm wondering if it could be part of a universal 1BC function ?

-----Original Message-----
From: Przemek Klosowski via Maxima-discuss
Sent: May 1, 2026 9:24 AM
To:
Subject: Re: [Maxima-discuss] [EXTERNAL] Re: 1-button calculator ~ "all elementary fns from a single operator"

> BTW, Google just told me that the obvious differential equation for > eml(x,y) is
>
> dy/dx = y*exp(x)

(%i1) eq:'diff(y,x)=y*exp(x);
dy x
(%o1) ── = %e y
dx
(%i2) ode2(eq,y,x);
x
%e
(%o2) y = %e %c

what am I missing?



_______________________________________________
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] Colnew Help

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

I join Example4 as treated by using my scripts.  This needed fixing a 
bug in colnew_discov.lisp. I have suppressed useless colnew output so 
one has to wait a couple of seconds (on my machine 4s. ) to see the plot 
appearing.  I would be happy if someone has an idea so that one can 
include the file colnew_help  instead of interpolating it like in p4.mac 
below. For example i have played with the following in lisp:

cat t.lisp

(eval-when (:execute) (incf z))
(format t "~a ~%" z)

then at the lisp prompt:

CL-USER> (defvar z 3)
Z
CL-USER> (load "t.lisp")
4
T
CL-USER> z
4

so when loading t.lisp it sees the global variable z and can modify it.  
Is there something similar in maxima so that loading the script 
colnew_help.mac the variables list_of_eqns, list_of_conds, etc can be 
discovered from the previous maxima statements?  I would like to have 
just to define the equations at the beginning, and then load(colnew) and 
load(colnew_help) followed by the program running automatically. Of 
course one still needs to plot the solution at the end ...

  Below the appropriate files.

Le 02/05/2026 à 11:14, Michel Talon a écrit :
> By the way i discovered that there may be several "boundary 
> conditions" at the same interior point, so that fixpoint has several 
> identical values, which is a bug. There is a trivial fix in 
> colnew_discov.lisp attached below.
>
-- 
Michel Talon

Re: [Maxima-discuss] Colnew Help

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

I agree with you, this was my intention, but i have encountered a 
problem for which i have not found the solution so far. If i write in 
the maxima session:

list_of_equations:[something];     and then

load("colnew_help.mac");

the list_of_equations appearing in  colnew_help.mac is not filled by 
what i wrote previously, so the program still asks questions. This 
defeats my intention, i have to include colnew_help.mac textually in the 
session. Is there any way to force evaluation of symbols in the loaded 
file in the context in which they are loaded? Something like perhaps 
eval-when :load in lisp?


Another point is that user intervention is  necessarily involved if one 
wants to change the number of tolerances checked by colnew or add points 
to fixpnt, for example to avoid a singularity, or perform some 
modification of ipar.. This is why there is a break in the program. By 
the way i discovered that there may be several "boundary conditions" at 
the same interior point, so that fixpoint has several identical values, 
which is a bug. There is a trivial fix in colnew_discov.lisp attached below.



Le 30/04/2026 à 16:45, Raymond Toy a écrit :
> setup_colnew([list-of-eqns],[vars], otherstuff)

-- 
Michel Talon

Re: [Maxima-discuss] ideas about representing degrees as Maxima expressions

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

On 5/2/26 06:29, Robert Dodier wrote:
> On Fri, May 1, 2026 at 3:54 PM Stavros Macrakis <mac...@gm...> wrote:
>
>> On Thu, Apr 30, 2026 at 12:43 AM Robert Dodier <rob...@gm...> wrote:
>>> modulo 360. This last bit produces degrees(-10) --> degrees(350).
>> Really? Why are you doing modular arithmetic on degrees?
> I guess that doesn't really make much sense. I will cut out that bit
> and try it again.
>
>
Good. I prefer the current behavior: conjugate(exp(%i)) --> exp(-%i), 
rather than conjugate(exp(%i)) --> exp((2*%pi-1)*%i)

Jaime

Re: [Maxima-discuss] ideas about representing degrees as Maxima expressions

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

On Fri, May 1, 2026 at 3:54 PM Stavros Macrakis <mac...@gm...> wrote:

> On Thu, Apr 30, 2026 at 12:43 AM Robert Dodier <rob...@gm...> wrote:

>> modulo 360. This last bit produces degrees(-10) --> degrees(350).

> Really? Why are you doing modular arithmetic on degrees?

I guess that doesn't really make much sense. I will cut out that bit
and try it again.

> I'd think you want a global option for how to present them: fractional degrees or degrees/minutes/seconds.

Well, so far I am assuming that the user inputs stuff the way they
want to see it, either as degrees only or degrees with minutes or
minutes and seconds. For purely numerical values, a canonical
representation as just one number is workable, but when variables are
allowed, as I think they must be, then I don't see a way to make that
work.

E.g. suppose a user writes degrees(x, y, z) so the canonical
representation could be either x + y/60 + z/3600 (degrees) or x*3600 +
y*60 + z (seconds). That seems to make a mess when you try to extract
bits for display; Maxima doesn't recover x from floor((x + 60*y +
3600*z)/3600), even after assuming that y and z are >= 0 and < 60.
Maybe I'm overlooking something obvious.

> How do you handle the inverse functions? i.e. how do you get asin(1/2) => 30° ? Is that degrees(asin(1/2))?

Almost. It has to be degrees(from_radians(asin(1/2))) since asin(1/2)
is just a number, so degrees(asin(1/2)) is valid and it represents
%pi/6 degrees.

best

Robert

Re: [Maxima-discuss] 1-button calculator ~ "all elementary fns from a single operator"

[Brent M. <mee...@gm...>]

I  think he deliberately chose a provocative title.  In the paper he's 
clear that he's composing all the functions on a typical handheld 
calculator.  He refers to a two-button calculator.  He's just using 
"elementary" an "on a calculator sense", not the elementary functions 
defined by Liouville.

I don't think it would be practical to implement functions in a 
calculator using eml.  The idea seems like a curiosity of no great 
import to me.

Brent

On 4/30/2026 6:04 PM, Henry Baker wrote:
> Andrzej Odrzywołek<and...@uj...> 's paper "All elementary functions from a single operator" has been making the rounds:
>
> https://arxiv.org/pdf/2603.21852
>
> In his paper, Odrzywołek concludes that the binary function eml(x,y)=exp(x)-ln(y), together with the constant 1 (one), is universal for "elementary" functions (using the complex domain).
>
> Here is a discussion of what is an "elementary" function:
>
> https://en.wikipedia.org/wiki/Elementary_function
>
> ---
> I noticed that Odrzywołek did NOT talk about derivatives or differential equations, yet isn't the notion of "elementary" tied rather tightly to 'elementary' differential equations (for a suitable definition of 'elementary' differential equation).
>
> Thus, does Odrzywołek's "eml(x,y}" function have a suitable differential equation definition ?
>
>
>
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss

Re: [Maxima-discuss] ideas about representing degrees as Maxima expressions

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

On Thu, Apr 30, 2026 at 12:43 AM Robert Dodier <rob...@gm...>
wrote:

> On Wed, Apr 29, 2026 at 9:19 AM Stavros Macrakis <mac...@gm...>
> wrote:
> ...
> > 2*degrees(10) => degrees(20) <<< OK
> > (-1)*degrees(10) => -degrees(10)  <<< why not degrees(-10)?
>
> Well, this is the subtle part. degrees(d, m, s) simplifies by carrying
> minutes from s into m, carrying degrees from m into d, and taking d
> modulo 360. This last bit produces degrees(-10) --> degrees(350).
>

Really? Why are you doing modular arithmetic on degrees? We don't do it for
radians. After all, two full turns are 4*%pi = 720 degrees -- nothing
strange about that.


> Yeah, as it stands, the degrees simplifier doesn't extract minutes and
> seconds from fractions. I was thinking that if someone writes
> degrees(122.832933), it probably wouldn't help to simplify that to
> degrees(122, 49, 58.5588).
>

I'd think you want a global option for how to present them: fractional
degrees or degrees/minutes/seconds.

How do you handle the inverse functions? i.e. how do you get asin(1/2) => 30°
? Is that degrees(asin(1/2))?

            -s

Re: [Maxima-discuss] [EXTERNAL] Re: 1-button calculator ~ "all elementary fns from a single operator"

[Leo B. <Leo...@um...>]

On Fri, May 01 2026, Henry Baker <hb...@pi...> wrote:

> Obviously, Google was confused.

No, it was not. The OP just needed to do some re-arranging.

(%i3) eq : 'diff(y,x) = y*exp(x);

(%o3) 'diff(y,x,1) = %e^x*y
(%i4) ode2(eq,y,x);

(%o4) y = %e^%e^x*%c
(%i5) map(log,%);

(%o5) log(y) = log(%e^%e^x*%c)
(%i6) %,logexpand=all;

(%o6) log(y) = log(%c)+%e^x
(%i7) subst(first(rhs(%))=eml(y,x),%-exp(x));

(%o7) log(y)-%e^x = eml(y,x)

Leo

Re: [Maxima-discuss] [EXTERNAL] Re: 1-button calculator ~ "all elementary fns from a single operator"

[Henry B. <hb...@pi...>]

Obviously, Google was confused.

Q: If z = exp(x)-log(y), then  x = log(z + log(y)) might look a tad better ?  Is this log(z+log(y)) function universal in the same sense as eml() ?

Q: if we have a 1BC expression for f(x)=y, can we then trivially compute x=f^-1(y) ?

Q: The 1BC paper seems to want to rely on functions defined over the reals; I suspect that functions defined over the complex numbers might give additional 1BC results that might be prettier ?  Perhaps the constant %pi*%i might work to force things into the complex plane ?

Q: I've always had a fondness for asinh(x), as it is bijective onto the reals, and has many of the same properties/characteristics as "gradual underflow" floating point numbers.  I'm wondering if it could be part of a universal 1BC function ?

-----Original Message-----
From: Przemek Klosowski via Maxima-discuss <max...@li...>
Sent: May 1, 2026 9:24 AM
To: <max...@li...>
Subject: Re: [Maxima-discuss] [EXTERNAL] Re: 1-button calculator ~ "all elementary fns from a single operator"

> BTW, Google just told me that the obvious differential equation for > eml(x,y) is
>
> dy/dx = y*exp(x)

(%i1) eq:'diff(y,x)=y*exp(x);
                                  dy     x
(%o1)                             ── = %e  y
                                  dx
(%i2) ode2(eq,y,x);
                                         x
                                       %e
(%o2)                            y = %e    %c

what am I missing?



_______________________________________________
Maxima-discuss mailing list
Max...@li...
https://lists.sourceforge.net/lists/listinfo/maxima-discuss

Re: [Maxima-discuss] [EXTERNAL] Re: 1-button calculator ~ "all elementary fns from a single operator"

[Przemek K. <prz...@ni...>]

> BTW, Google just told me that the obvious differential equation for 
> eml(x,y) is
>
> dy/dx = y*exp(x)

(%i1) eq:'diff(y,x)=y*exp(x);
                                   dy     x
(%o1)                             ── = %e  y
                                   dx
(%i2) ode2(eq,y,x);
                                          x
                                        %e
(%o2)                            y = %e    %c

what am I missing?

Re: [Maxima-discuss] Some more questions about defsystem modules

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

On Wed, Apr 29, 2026 at 9:45 AM Raymond Toy <toy...@gm...> wrote:

>
>
>
> There may have been a increase in testsuite time from 82 sec to 90, but
> not clear;  Other things may be been running at the time and we know the
> times do vary a bit between runs.
>
> Overall, I think this is a good  change.  (Oh, I left the optimize thing
> in.  Something for another day.)
>

Ok.  I removed the gcl proclaim stuff, and disabled the gcl optimize.lisp
file.  I ran the testsuite without and without these changes.  Time
original is 106.5 sec and 107.5 sec with the changes.  Average of 3 runs.
The difference is not statistically significant.

I think I'll remove the proclaim stuff but leave the optimize line in, but
disabled, pending any info from Camm.  If we don't here from him in a
while, I'll remove that too.


>
>> FWIW
>>
>> Robert
>>
>
>
> --
> Ray
>


-- 
Ray

Re: [Maxima-discuss] 1-button calculator ~ "all elementary fns from a single operator"

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

That DE is simpler than I would have expected!

Since f(x)=x+1 can be defined by a composition of 19 instances of EML,
maybe Maxima can find a DE definition for f using it? :-)

... one reason I still strongly doubt that EML has any practical or
theoretical interest.




On Thu, Apr 30, 2026, 21:29 Henry Baker <hb...@pi...> wrote:

> BTW, Google just told me that the obvious differential equation for
> eml(x,y) is
>
> dy/dx = y*exp(x)
>
> I was hoping for something even simpler -- anyone ?, anyone ?
>
> -----Original Message-----
> From: Henry Baker <hb...@pi...>
> Sent: Apr 30, 2026 6:05 PM
> To: Barton Willis via Maxima-discuss <max...@li...
> >
> Subject: [Maxima-discuss] 1-button calculator ~ "all elementary fns from a
> single operator"
>
> Andrzej Odrzywołek 's paper "All elementary functions from a single
> operator" has been making the rounds:
>
> https://arxiv.org/pdf/2603.21852
>
> In his paper, Odrzywołek concludes that the binary function
> eml(x,y)=exp(x)-ln(y), together with the constant 1 (one), is universal for
> "elementary" functions (using the complex domain).
>
> Here is a discussion of what is an "elementary" function:
>
> https://en.wikipedia.org/wiki/Elementary_function
>
> ---
> I noticed that Odrzywołek did NOT talk about derivatives or differential
> equations, yet isn't the notion of "elementary" tied rather tightly to
> 'elementary' differential equations (for a suitable definition of
> 'elementary' differential equation).
>
> Thus, does Odrzywołek's "eml(x,y}" function have a suitable differential
> equation definition ?
>
>
>
> _______________________________________________
> 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] 1-button calculator ~ "all elementary fns from a single operator"

[Henry B. <hb...@pi...>]

BTW, Google just told me that the obvious differential equation for eml(x,y) is

dy/dx = y*exp(x)

I was hoping for something even simpler -- anyone ?, anyone ?

-----Original Message-----
From: Henry Baker <hb...@pi...>
Sent: Apr 30, 2026 6:05 PM
To: Barton Willis via Maxima-discuss <max...@li...>
Subject: [Maxima-discuss] 1-button calculator ~ "all elementary fns from a single operator"

Andrzej Odrzywołek 's paper "All elementary functions from a single operator" has been making the rounds:

https://arxiv.org/pdf/2603.21852

In his paper, Odrzywołek concludes that the binary function eml(x,y)=exp(x)-ln(y), together with the constant 1 (one), is universal for "elementary" functions (using the complex domain).

Here is a discussion of what is an "elementary" function:

https://en.wikipedia.org/wiki/Elementary_function

---
I noticed that Odrzywołek did NOT talk about derivatives or differential equations, yet isn't the notion of "elementary" tied rather tightly to 'elementary' differential equations (for a suitable definition of 'elementary' differential equation).

Thus, does Odrzywołek's "eml(x,y}" function have a suitable differential equation definition ?



_______________________________________________
Maxima-discuss mailing list
Max...@li...
https://lists.sourceforge.net/lists/listinfo/maxima-discuss

[Maxima-discuss] 1-button calculator ~ "all elementary fns from a single operator"

[Henry B. <hb...@pi...>]

Andrzej Odrzywołek <and...@uj...> 's paper "All elementary functions from a single operator" has been making the rounds:

https://arxiv.org/pdf/2603.21852

In his paper, Odrzywołek concludes that the binary function eml(x,y)=exp(x)-ln(y), together with the constant 1 (one), is universal for "elementary" functions (using the complex domain).

Here is a discussion of what is an "elementary" function:

https://en.wikipedia.org/wiki/Elementary_function

---
I noticed that Odrzywołek did NOT talk about derivatives or differential equations, yet isn't the notion of "elementary" tied rather tightly to 'elementary' differential equations (for a suitable definition of 'elementary' differential equation).

Thus, does Odrzywołek's "eml(x,y}" function have a suitable differential equation definition ?

Re: [Maxima-discuss] Colnew Help

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

Sorry for the delay!

I haven’t looked at your files in detail, but I think it’s really 
beneficial to have tools like this. I doubt I could write some code that 
could use colnew to produce a useful answer without having to read and 
understand all the examples and the code. It is quite dense.

One thing I did notice is that you read a list of equations. Good for 
interactive use, but I think there should also be a more programmatic 
way to do this so that the list of equations was a parameter.

So something like |setup_colnew([list-of-eqns],[vars], otherstuff)|.

On 4/25/26 2:35 PM, Michel Talon wrote:

> Hello,
>
> i have taken some time to write a program to help writing the 
> appropriate incantations to invoke colnew. It is not always obvious, 
> in particular the number of evaluations necessary so that fsub, dfsub, 
> gsub and dgsub only contain the z-variables and numerical data. The 
> smallest error or incoherence between colnew variables, etc. produce 
> very hard to debug lisp errors, hence the utility of  a more automatic 
> program. I have tested this stuff on Example 3 of the colnew 
> documentation, which already reveals problems - notably dfsub has a 
> tendency to contain L and s variables due to insufficient evaluation. 
> I have tried to be quite general,Sorry but it may be that more 
> complicated problems reveal other similar glitches that could be 
> solved similarly. Anyways, i join here 3 files, one is a lisp file 
> containing stuff to analyze the equations and compute necessary colnew 
> variables,  the other a maxima file which loads it and colnew and 
> links the appropriate steps, finally a text file describing a maxima 
> session with this program. One can see it runs very automatically.  If 
> someone finds this interesting i would be happy to see them included 
> in the colnew folder... The maxima file has some quite complex 
> invocations, like define(funmake (gsub, cons(i,var_list)), 
> buildq([gval:apply (g, var_list)], gval[i]))$ which took me some time 
> to discover, and may be of interest for other computations...(note in 
> this case apply(g,var_list)[i] quoted or not does not work, the := 
> operator accepts the subscript [i] but doesn't allow to have a 
> constructed list of arguments, buildq allows to both evaluate gval and 
> not evaluate the subscript).
>
>
> -- 
> Michel Talon
>
>
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
​

Re: [Maxima-discuss] Colnew Help

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

I think i have understood and fixed the evaluation problem (which 
probably is not dealt with correctly in the examples appearing in 
colnew) and have simplified a little bit the use of colnew_help. The 
corresponding files colnew_help.mac, colnew_discov.lisp and 
p3_session.txt (application to example3) are attached below.

I hope that this could reduce to very little work the use of colnew for 
people wanting to  solve boundary value problems.


Le 25/04/2026 à 23:35, Michel Talon a écrit :
> notably dfsub has a tendency to contain L and s variables due to 
> insufficient evaluation

-- 
Michel Talon

Re: [Maxima-discuss] ideas about representing degrees as Maxima expressions

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

On Wed, Apr 29, 2026 at 9:19 AM Stavros Macrakis <mac...@gm...> wrote:

> I understand that this is version 0 and that you or anyone else can improve and extend it, so please don't interpret what follows as criticism of what you've already done, but ideas for future development.

Oh, understood, no problem, thanks for looking at it.

> I was thinking it would be nice to define syntax for °, ′, ″,

Yeah, that would be great, if only so one could copy and paste output
as input. The easy part, I think, is defining °, ′, ″ as postfix
operators, then stand-alone expressions foo″ etc are understood by the
parser. The part I don't yet know is how to make it so that one can
put these items adjacent to each other, and only those, and in a
specific order. As you pointed out, this problem is already solved by
the "do" parser, so we could look at that to get some inspiration.

> 2*degrees(10) => degrees(20) <<< OK
> (-1)*degrees(10) => -degrees(10)  <<< why not degrees(-10)?

Well, this is the subtle part. degrees(d, m, s) simplifies by carrying
minutes from s into m, carrying degrees from m into d, and taking d
modulo 360. This last bit produces degrees(-10) --> degrees(350).

So far, so good. However, the simplification of sin applies a
heuristic for reflection: if ?great(-x, x), then sin(x) --> -sin(-x).
Since ?great(350, -10), sin(degrees(-10)) --> -sin(degrees(350)). I
decided I didn't like that. I suppose there are ways around it, but I
haven't tried anything yet.

> degrees(5/2) == degrees(5)/2 => degrees(5/2) <<< shouldn't this be degrees(2,30)? (maybe under control of a switch)
> Similarly for degrees(2.5)  => degrees(2,30.0)

Yeah, as it stands, the degrees simplifier doesn't extract minutes and
seconds from fractions. I was thinking that if someone writes
degrees(122.832933), it probably wouldn't help to simplify that to
degrees(122, 49, 58.5588).

But yeah, some easy way to get that could be nice. I see that at
present one can say canonical_degrees([0, 0, 3600*122.832933]) to get
122.0° 49.0′ 58.55879999999888″. That's only a little clumsy, but it
could be improved.

> Is there any reason the user needs to write degrees(from_radians(...)) rather than degrees_from_radians(...)?

Well, writing degrees(from_radians(...)) means that the operator is
degrees, which means it can be recognized by a simplification rule.
degrees_from_radians(...) might return a result (a degrees(...)
expression) but the degrees_from_radians(...) itself isn't
recognizable, short of cluttering the rules with additional stuff just
for that.

The degrees/radians conversion is a little clumsy. I'll think about
how to make it less so.

> sin(degrees(x+45))
> trig_with_degrees(%) => sin((%pi*(x+45))/180)
> trigexpand(expand(%)) => sin((%pi*x)/180)/sqrt(2)+cos((%pi*x)/180)/sqrt(2)
>
> Very nice. How do I put this back in degree form?

Great question, I haven't figured that out yet. I guess the obvious
thing is a rule to replace every foo(...) with
foo(degrees(from_radians(...))) for foo in [sin, cos, tan, csc, sec,
cot].

> radians(from_degrees(degrees(10)^2)) << doesn't change
> radians(from_degrees(degrees(10))^2) << doesn't change
> radians(from_degrees(degrees(10)))^2
>     => %pi^2/324 (steradians)
>
> Why do the first three not work, and how do I convert to square degrees?

Well, the obvious explanation about the first two is that the rules
are only for radians(from_degrees(degrees(...))), and the presence of
"^" means the operators don't match. The bigger question is, to me,
should it work? Or maybe, how should it work? Is it OK to mix radians
and steradians? I wouldn't think so, but I haven't thought much about
it.

best,

Robert

[Maxima-discuss] Yamwi release 2026-04-29

[Leo B. <Leo...@um...>]

Release 2026-04-29

The Yamwi development team is pleased to announced a new release (v. 2026-04-29).

Yamwi (Yet Another Maxima Web Interface<https://github.com/leo-butler/yamwi/>) is a web interface to the computer algebra system Maxima<https://maxima.sourceforge.io/>. It is based on based on Linux+Apache+Php. Originally developed by Mario Rodríguez Riotorto and hosted on Sourceforge, the project is being continued by a new team of developers on Github.

Important Note

This release contains a critical security fix. Site administrators are advised to update to this release immediately.

Security
New prohibited words

  *   eval_lisp_string: this function allows execution of arbitrary code (see Issue 19<https://github.com/leo-butler/yamwi/issues/19>).

Formerly prohibited words

  *   kill is no longer a prohibited word. The functionality of kill has been restricted, so kill(all) and kill(allbut(...)) elicit warnings. Killing variables that hold important state information for Yamwi is also prohibited (see Issue 16<https://github.com/leo-butler/yamwi/issues/16> and Commit daf5d7b40f<https://github.com/leo-butler/yamwi/commit/daf5d7b40f3a62af03b62dd171bb5a4c3e4a57f9>).
  *   demo is no longer a prohibited word. It is now a synomym for batch, since Yamwi does not allow for line-by-line interaction (see Issue 15<https://github.com/leo-butler/yamwi/issues/15>).
  *   load(drawdf); works as intended; load is no longer a prohibited word (see Issue 1<https://github.com/leo-butler/yamwi/issues/1>).
  *   concat, sconcat and printf are no longer prohibited (see Issue 18<https://github.com/leo-butler/yamwi/issues/18>).
  *   translate and compile are no longer prohibited.
  *   entermatrix no longer prohibited (see items 6 and 8 in the next section).

Changes to the User-Interface

  1.  Input and output may now be displayed as Lisp S-expressions (Sexps). Users who are curious about how Maxima represents mathematical objects can use these display options.
  2.  Improve the handling of verbatim input (see Issue 5<https://github.com/leo-butler/yamwi/issues/5>).
  3.  Improve the handling of error messages from Maxima and Gnuplot (SBCL, ECL; not GCL or CLISP).
  4.  Correct the TeX code for matrices and diff (see Issue 6<https://github.com/leo-butler/yamwi/issues/6> and Issue 11<https://github.com/leo-butler/yamwi/issues/6>).
  5.  Print the Maxima banner as a header for the output, similar to other front-ends.
  6.  Maxima's trace command now works, subject to a patch to Maxima (see Issue 17<https://github.com/leo-butler/yamwi/issues/17>).
  7.  Commands like integrate(x^n,x);, which require an answer to the question Is n equal to -1?, can now have the answer embedded in the input (see Issue 12<https://github.com/leo-butler/yamwi/issues/12>).
  8.  Commands line read("input a number:"); now have their prompt (input a number) echoed correctly. The answer can be placed on the next input line and it is read correctly (see Issue 13<https://github.com/leo-butler/yamwi/issues/13>).
  9.  More commands are now available to the user (see the list in Formerly prohibited words.
  10. Print to PDF has been improved. Figures should no longer be cut across pages.
  11. MathML output has been improved (requires updates to Maxima).
  12. Yamwi should generate fully compliant HTML that validates with the W3C validator. If you find a page that does not validate, please report a bug<https://github.com/leo-butler/yamwi/issues> and be sure to include a link to non-validating page.

Lisps supported

Maxima runs on a variety of Common Lisp implementations. As of this release, using a Debian 13 server installed on a virtual machine, the following implementations are supported:

SBCL, ECL
fully supported.
GCL
partially supported, not recommended. There are multiple issues that hobble the use of GCL on a server:

  1.  [X] Runs with Yamwi served on localhost.
  2.  [X] Recent versions of Maxima cannot be built with GCL. They must be build with GCL27.
  3.  [ ] The Debian GCL-based Maxima package has majour problems compiling and loading the draw package.
  4.  [ ] GCL does not correctly re-bind the *error-output* stream. This limits error reporting compared to SBCL and ECL and necessitates a customized run-program (built on si:run-process).

Clisp
unsupported. There are a few issues to be overcome.

  1.  [X] Runs with Yamwi served on localhost.
  2.  [ ] There are filesystem-access issues when run as part of Apache. Patches are invited.
  3.  [ ] Clisp's implementation of run-program is broken (neither *standard-output* nor *error-output* can be correctly let bound in order to redirect these output streams). No good work-arounds are known to us.

Download

Download the tar.gz release file from the project webpage: https://github.com/leo-butler/yamwi/releases/.

Reference implementation

A pair of live Yamwi servers are maintained by the project:

  1.  https://net124.reltub.ca/yamwi/ serves the latest release of Yamwi.
  2.  https://net124.reltub.ca/yamwi-dev/ serves the latest version of Yamwi from the master branch of the Github repository (it may take up to 24 hours to synchronize with HEAD).

Re: [Maxima-discuss] standard trig functions for degrees ?

[Andrey G. G. <A.G...@in...>]

I am very much against sind and similar functions.

Entities must not be multiplied beyond necessity
(c) Occam

Andrey

Re: [Maxima-discuss] silly q about sloop

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

On 4/29/26 11:23 AM, James Cloos wrote:

> having read the git log on the brach about moving sloop,
> in my master checkout sloop.lisp reads:
>
> (in-package :cl-sloop)
> (defmacro sloop (&rest body)
>    (warn (intl:gettext "Using deprecated macro 'sloop'. Use 'loop' instead."))
>    `(loop ,@body))
>
> is deleting not better than moving?

Probably, but I didn’t want to break anyone’s use of sloop so it’s still 
in share/utils. I won’t object if someone really wants to remove it 
completely.

​

[Maxima-discuss] silly q about sloop

[James C. <cl...@jh...>]

having read the git log on the brach about moving sloop,
in my master checkout sloop.lisp reads:

(in-package :cl-sloop)
(defmacro sloop (&rest body)
  (warn (intl:gettext "Using deprecated macro 'sloop'. Use 'loop' instead."))
  `(loop ,@body))

is deleting not better than moving?

(yes, i got curious as to what sloop was....)

-JimC
-- 
James Cloos <cl...@jh...>
            OpenPGP: https://jhcloos.com/0x997A9F17ED7DAEA6.asc

Re: [Maxima-discuss] odd result with complex / numerical v:(-1)^(%i*%pi)^(-1)

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

Could you be more explicit? I will guess that you would like
*realpart(ev(v,number,float))
*to return a float?

But as far as Maxima is concerned, *%e^(.3*%pi)* is a perfectly fine
simplified expression.

One possibly and reasonable change to the simplifier would simplify
expressions of the form *<float>*<const> *to *<float>*float(<const>)*, by
float contagion.

Is that desirable? It sounds good to me, but we've seen that some users
write *0.5*%pi *for *%pi/2*, much as we try to discourage it, and would not
want that to become *1.57*.

                -s

On Wed, Apr 29, 2026 at 11:53 AM Raymond Toy <toy...@gm...> wrote:

> On 4/28/26 12:28 PM, Richard Fateman wrote:
>
> v:(-1)^(%i*%pi)^(-1);
>
> realpart(v);
> v,numer,float;
> realpart(%);
> %,numer;
>
> I think this is just one of the long list of quirks in how numer and float
> are treated. I remember discussions about this on the list, probably from
> Stavros and others. I don’t think we ever came to a conclusion on how this
> is supposed to work.
> &#8203;
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>

Re: [Maxima-discuss] Some more questions about defsystem modules

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

On Mon, Apr 27, 2026 at 12:42 PM Robert Dodier <rob...@gm...>
wrote:

>
> About the module "proclaim", dunno what's up with that. Maybe stuff
> got moved into that in order to quiet some warnings or something like
> that? Maybe try to do without "proclaim" and remove the #-gcl
> conditionals for those items elsewhere in maxima.system. On the whole
> I think reducing implementation dependent stuff is a good idea.
>

Agreed. I just commented out that part of defsystem.  Had to make a few
other minor tweaks, but maxima still builds with gcl.  I don't see anything
bad happening and the testsuite still passes (gcl Version_2_7_2pre15).

There may have been a increase in testsuite time from 82 sec to 90, but not
clear;  Other things may be been running at the time and we know the times
do vary a bit between runs.

Overall, I think this is a good  change.  (Oh, I left the optimize thing
in.  Something for another day.)


> FWIW
>
> Robert
>


-- 
Ray

Re: [Maxima-discuss] ideas about representing degrees as Maxima expressions

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

Very nice!

I understand that this is version 0 and that you or anyone else can improve
and extend it, so please don't interpret what follows as criticism of what
you've already done, but ideas for future development.

In playing with it quickly, here are some things I noticed.

I was thinking it would be nice to define syntax for °, ′, ″, but then I
realized that very few users will want to go to the trouble of inputting
those characters. Still, could be nice to have output in that form and then
input it back. If we can do it for the various clauses of *do*, it would
seem that we can do it for these operators, as long as we require °, e.g., 0
°30′, not simply 30′.

2*degrees(10) => degrees(20) <<< OK
(-1)*degrees(10) => -degrees(10)  <<< why not degrees(-10)?

degrees(5/2) == degrees(5)/2 => degrees(5/2) <<< shouldn't this be
degrees(2,30)? (maybe under control of a switch)
Similarly for degrees(2.5)  => degrees(2,30.0)

My guess is that some users will want to work in decimal degrees and others
will want to see degrees/minutes/seconds, at least as the final form.

Is there any reason the user needs to write degrees(from_radians(...))
rather than degrees_from_radians(...)?

sin(degrees(x+45))
trig_with_degrees(%) => sin((%pi*(x+45))/180)
trigexpand(expand(%)) => sin((%pi*x)/180)/sqrt(2)+cos((%pi*x)/180)/sqrt(2)

Very nice. How do I put this back in degree form?

radians(from_degrees(degrees(10)^2)) << doesn't change
radians(from_degrees(degrees(10))^2) << doesn't change
radians(from_degrees(degrees(10)))^2
    => %pi^2/324 (steradians)

Why do the first three not work, and how do I convert to square degrees?

           -s


On Wed, Apr 29, 2026 at 1:57 AM Robert Dodier <rob...@gm...>
wrote:

> Inspired by recent discussions, I put together a proof of concept of a
> representation of degrees as Maxima expressions. You can see the
> result here:
>
>
> https://github.com/maxima-project-on-github/maxima-packages/tree/master/robert-dodier/degrees
>
> I chose to represent degrees apart from trig functions, so trig
> functions are unchanged. If you want sin of x degrees, you write
> sin(degrees(x)).
>
> Trig functions of degrees by default don't simplify; I think that's
> preferable since otherwise you get a mess with factors of %pi/180
> floating around. Degrees are changed into radians by calling a
> function, trig_with_degrees, which changes all the degrees in an
> expression into radians, and therefore enables further simplifications
> of the trig functions.
>
> Degrees can have optional minutes and seconds, e.g. degrees(45),
> degrees(45, 30), degrees(45, 30, 22).
>
> Degrees are displayed by the pretty printer with postfix Unicode
> operators, e.g. 134° 56′ 12″ for degrees(134, 56, 12).
>
> Arithmetic is allowed on degrees, although I haven't worked out how to
> handle subtraction; it turns out that's a bit subtle. I'll think about
> it some more.
>
> The output from degrees.demo is shown in the README for that package.
>
> For the record,
> https://github.com/maxima-project-on-github/maxima-packages is a
> package-parking place that I started a few years ago, in hope of
> promoting something like the package ecosystems for other systems such
> as R and Python.
>
> All in good fun,
>
> Robert
>
>
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>

Re: [Maxima-discuss] Some more questions about defsystem modules

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

On 4/27/26 2:06 PM, Raymond Toy wrote:

> On 4/27/26 12:42 PM, Robert Dodier wrote:
>
>> On Mon, Apr 27, 2026 at 10:30 AM Raymond Toy<toy...@gm...> wrote:
>>> According to maxima.system, we still compile and load sloop.lisp. But I think the last use of sloop was removed many, many years ago? Can we remove that from the defsystem?
>>>
>>> Likewise, gcl includes optimize.lisp. Do we still need this? I guess it’s telling gcl to optimize (inline) some simple operations. I’m not familiar with this. Maybe leave it?
>>>
>>> At the very beginning we have a gcl module named proclaim that just loads (no compiling) a bunch of files. Not sure why this needs to be done. Couldn’t find any notes on this, but I didn’t look very hard.
>> Assuming that SLOOP was successfully expunged (some years ago), I
>> think it's OK to remove sloop.lisp. I suppose there might possibly be
>> some user code somewhere which uses SLOOP. If so we will hear about
>> it. I am inclined to say that any code still using SLOOP is the
>> author's responsibility at this point.
> My thinking right now was to remove it from defsystem and move 
> sloop.lisp to share or something so that some it’s still available in 
> case anyone wants it.

Done. sloop is now in share/utils.

&#8203;