maxima-discuss — Maxima discussion list

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

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

Take a look at the examples I sent before, where that approach doesn't
work. For convenience, I'm repeating them below:

If you're working in degrees, *limit(sind(x)/x,x,0)* gives *%pi/180*; is
that what is expected, or does the user want to see *(%pi/180)°* or maybe
*1*? Note that *sin/cos/etc. *don't appear in the result.

How do you write the Taylor expansion of sind(x)? The straightforward way
gives

taylor(sind(x),x,0,3) =>
             (%pi*x)/180-(%pi^3*x^3)/34992000


Note that *sin/cos/etc. *don't appear in the result. Do you write that as
something like

(x*°*) -(x*°*)^3/6


How do you know to do that?

On Mon, Apr 27, 2026 at 6:33 PM Henry Baker <hb...@pi...> wrote:

> No, simply given an expression with "sin" or "asin", rewrite each
> occurrence with the "sind" or "asind" with the appropriate fudge factor
> (%pi/180 or 180/%pi) stuck in; ditto in reverse.  Then resimplify, of
> course.
>
>
>
>
>
> -----Original Message-----
> From: Stavros Macrakis <mac...@gm...>
> Sent: Apr 27, 2026 3:24 PM
> To: <hb...@pi...>
> Cc: <max...@li...>, Robert Dodier <
> rob...@gm...>
> Subject: Re: [Maxima-discuss] standard trig functions for degrees ?
>
>
> I'm not sure what you're proposing -- that every function that takes trig
> functions as input or output will have to be modified?
>
> On Mon, Apr 27, 2026 at 6:20 PM Henry Baker <hb...@pi...> wrote:
>
>> Well, as ugly as switches are, I suppose one could switch from primitives
>> sind/cosd/tand/asind/acosd/atand to primitives sin/cos/tan/asin/acos/atan
>> or back again with a switch.
>>
>>
>>
>> I agree that things get ugly when using degrees instead of radians, but
>> some usages of degrees are embedded so tightly into the application context
>> that it seems perverse to insist on radians.
>>
>>
>>
>> Also, if we are sufficiently knowledgeable about the number %pi/180 --
>> e.g., identities about its various powers -- some "nice" things may happen
>> that are a bit less obvious when working with radians.
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: Stavros Macrakis <mac...@gm...>
>> Sent: Apr 27, 2026 3:09 PM
>> To: Henry Baker <hb...@pi...>
>> Cc: <max...@li...>, Robert Dodier <
>> rob...@gm...>
>> Subject: Re: [Maxima-discuss] standard trig functions for degrees ?
>>
>>
>> Henry,
>>
>> I really don't know much about working in degrees. Like Ray, the last
>> time I did that was in high school.
>>
>> If you're working in degrees, how do you write, say, the Taylor expansion
>> of sind(x)? The straightforward way gives
>>
>>
>> taylor(sind(x),x,0,3) =>
>>              (%pi*x)/180-(%pi^3*x^3)/34992000
>>
>>
>> Do you write that as something like
>>
>>
>> (x*°*) -(x*°*)^3/6
>>
>> ?
>>
>> On Mon, Apr 27, 2026 at 5:15 PM Stavros Macrakis <mac...@gm...>
>> wrote:
>>
>>> I don't know what exactly Henry wants. If it's just numeric computation,
>>> that's trivial. As he says, it's < 1k of code, which he can write himself.
>>>
>>> The hard part is symbolic computation.
>>>
>>> I'd think that someone working in degrees would like to see things like:
>>>
>>>
>>> *sind(x/2),halfangles => sqrt(1-cosd(x))/sqrt(2) *(for 0<x<360)
>>>
>>>
>>> This gets messier. Yes, you can write pattern matching rules that change
>>> all instances of *cos(...)* to *cosd(...)*, etc.
>>>
>>> But what about, say, *limit(sind(x)/x,x,0)*? That gives *%pi/180*; is
>>> that what is expected, or does the user want to see *(%pi/180)°* or
>>> maybe *1*? I've never worked in degrees beyond elementary trig, so I
>>> don't know what the user expects, and whether the system (as opposed to the
>>> user) needs to keep track of degrees vs. radians.
>>>
>>> Or am I overthinking it?
>>>
>>>           -s
>>>
>>> On Mon, Apr 27, 2026 at 4:45 PM Robert Dodier <rob...@gm...>
>>> wrote:
>>>
>>>> On Mon, Apr 27, 2026 at 12:48 PM Henry Baker <hb...@pi...>
>>>> wrote:
>>>>
>>>> > A number of computer languages -- e.g., Fortran -- support trig
>>>> functions over degrees -- e.g., sind(x), cosd(x), tand(x), asind(x), etc.
>>>> >
>>>> > I know it's "trivial", but could Maxima please go ahead a define
>>>> standardly the trig functions over degrees?  We're talking about about
>>>> increasing the core system at most by perhaps 1K bytes !
>>>>
>>>> Well, maybe the code is trivial, but the increased mental burden is
>>>> not ... Instead of creating new functions, I am OK with two functions,
>>>> radians(x) to get radians from degrees and degrees(x) to get degrees
>>>> from radians. Then one can call those whenever it makes sense.
>>>>
>>>> We could make those simplifying functions. Just thinking out loud here.
>>>>
>>>> Hmm, maybe degrees(x) should represent x degrees, like radians(x)
>>>> represents x radians. radians(x) simplifies to x and degrees(x)
>>>> simplifies to x*%pi/180. E.g. sin(degrees(90)) --> sin(%pi/2), etc.
>>>>
>>>> I think I'm leaning towards degrees(x) representing x degrees. What
>>>> does anyone else think?
>>>>
>>>> Robert
>>>>
>>>>
>>>> _______________________________________________
>>>> Maxima-discuss mailing list
>>>> Max...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>>>
>>>

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

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

No, simply given an expression with "sin" or "asin", rewrite each occurrence with the "sind" or "asind" with the appropriate fudge factor (%pi/180 or 180/%pi) stuck in; ditto in reverse.  Then resimplify, of course.

-----Original Message-----
From: Stavros Macrakis <mac...@gm...>
Sent: Apr 27, 2026 3:24 PM
To: <hb...@pi...>
Cc: <max...@li...>, Robert Dodier <rob...@gm...>
Subject: Re: [Maxima-discuss] standard trig functions for degrees ?

I'm not sure what you're proposing -- that every function that takes trig functions as input or output will have to be modified?


On Mon, Apr 27, 2026 at 6:20 PM Henry Baker <hb...@pi... (mailto:hb...@pi...)> wrote:
Well, as ugly as switches are, I suppose one could switch from primitives sind/cosd/tand/asind/acosd/atand to primitives sin/cos/tan/asin/acos/atan or back again with a switch.

I agree that things get ugly when using degrees instead of radians, but some usages of degrees are embedded so tightly into the application context that it seems perverse to insist on radians.

Also, if we are sufficiently knowledgeable about the number %pi/180 -- e.g., identities about its various powers -- some "nice" things may happen that are a bit less obvious when working with radians.



-----Original Message-----
From: Stavros Macrakis <mac...@gm... (mailto:mac...@gm...)>
Sent: Apr 27, 2026 3:09 PM
To: Henry Baker <hb...@pi... (mailto:hb...@pi...)>
Cc: <max...@li... (mailto:max...@li...)>, Robert Dodier <rob...@gm... (mailto:rob...@gm...)>
Subject: Re: [Maxima-discuss] standard trig functions for degrees ?

Henry,
 
I really don't know much about working in degrees. Like Ray, the last time I did that was in high school.
 
If you're working in degrees, how do you write, say, the Taylor expansion of sind(x)? The straightforward way gives
 
taylor(sind(x),x,0,3) =>
             (%pi*x)/180-(%pi^3*x^3)/34992000
 
Do you write that as something like
 
(x&deg;) -(x&deg;)^3/6
?


On Mon, Apr 27, 2026 at 5:15 PM Stavros Macrakis <mac...@gm... (mailto:mac...@gm...)> wrote:
I don't know what exactly Henry wants. If it's just numeric computation, that's trivial. As he says, it's < 1k of code, which he can write himself.
 
The hard part is symbolic computation.

I'd think that someone working in degrees would like to see things like:
 
sind(x/2),halfangles => sqrt(1-cosd(x))/sqrt(2) (for 0<x<360)
 
This gets messier. Yes, you can write pattern matching rules that change all instances of cos(...) to cosd(...), etc.
 
But what about, say, limit(sind(x)/x,x,0)? That gives %pi/180; is that what is expected, or does the user want to see (%pi/180)&deg; or maybe 1? I've never worked in degrees beyond elementary trig, so I don't know what the user expects, and whether the system (as opposed to the user) needs to keep track of degrees vs. radians.
 
Or am I overthinking it?
 
          -s


On Mon, Apr 27, 2026 at 4:45 PM Robert Dodier <rob...@gm... (mailto:rob...@gm...)> wrote:
On Mon, Apr 27, 2026 at 12:48 PM Henry Baker <hb...@pi... (mailto:hb...@pi...)> wrote:

> A number of computer languages -- e.g., Fortran -- support trig functions over degrees -- e.g., sind(x), cosd(x), tand(x), asind(x), etc.
>
> I know it's "trivial", but could Maxima please go ahead a define standardly the trig functions over degrees?  We're talking about about increasing the core system at most by perhaps 1K bytes !

Well, maybe the code is trivial, but the increased mental burden is
not ... Instead of creating new functions, I am OK with two functions,
radians(x) to get radians from degrees and degrees(x) to get degrees
from radians. Then one can call those whenever it makes sense.

We could make those simplifying functions. Just thinking out loud here.

Hmm, maybe degrees(x) should represent x degrees, like radians(x)
represents x radians. radians(x) simplifies to x and degrees(x)
simplifies to x*%pi/180. E.g. sin(degrees(90)) --> sin(%pi/2), etc.

I think I'm leaning towards degrees(x) representing x degrees. What
does anyone else think?

Robert


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

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

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

I'm not sure what you're proposing -- that every function that takes trig
functions as input or output will have to be modified?

On Mon, Apr 27, 2026 at 6:20 PM Henry Baker <hb...@pi...> wrote:

> Well, as ugly as switches are, I suppose one could switch from primitives
> sind/cosd/tand/asind/acosd/atand to primitives sin/cos/tan/asin/acos/atan
> or back again with a switch.
>
>
>
> I agree that things get ugly when using degrees instead of radians, but
> some usages of degrees are embedded so tightly into the application context
> that it seems perverse to insist on radians.
>
>
>
> Also, if we are sufficiently knowledgeable about the number %pi/180 --
> e.g., identities about its various powers -- some "nice" things may happen
> that are a bit less obvious when working with radians.
>
>
>
>
>
> -----Original Message-----
> From: Stavros Macrakis <mac...@gm...>
> Sent: Apr 27, 2026 3:09 PM
> To: Henry Baker <hb...@pi...>
> Cc: <max...@li...>, Robert Dodier <
> rob...@gm...>
> Subject: Re: [Maxima-discuss] standard trig functions for degrees ?
>
>
> Henry,
>
> I really don't know much about working in degrees. Like Ray, the last time
> I did that was in high school.
>
> If you're working in degrees, how do you write, say, the Taylor expansion
> of sind(x)? The straightforward way gives
>
>
> taylor(sind(x),x,0,3) =>
>              (%pi*x)/180-(%pi^3*x^3)/34992000
>
>
> Do you write that as something like
>
>
> (x*°*) -(x*°*)^3/6
>
> ?
>
> On Mon, Apr 27, 2026 at 5:15 PM Stavros Macrakis <mac...@gm...>
> wrote:
>
>> I don't know what exactly Henry wants. If it's just numeric computation,
>> that's trivial. As he says, it's < 1k of code, which he can write himself.
>>
>> The hard part is symbolic computation.
>>
>> I'd think that someone working in degrees would like to see things like:
>>
>>
>> *sind(x/2),halfangles => sqrt(1-cosd(x))/sqrt(2) *(for 0<x<360)
>>
>>
>> This gets messier. Yes, you can write pattern matching rules that change
>> all instances of *cos(...)* to *cosd(...)*, etc.
>>
>> But what about, say, *limit(sind(x)/x,x,0)*? That gives *%pi/180*; is
>> that what is expected, or does the user want to see *(%pi/180)°* or maybe
>>  *1*? I've never worked in degrees beyond elementary trig, so I don't
>> know what the user expects, and whether the system (as opposed to the user)
>> needs to keep track of degrees vs. radians.
>>
>> Or am I overthinking it?
>>
>>           -s
>>
>> On Mon, Apr 27, 2026 at 4:45 PM Robert Dodier <rob...@gm...>
>> wrote:
>>
>>> On Mon, Apr 27, 2026 at 12:48 PM Henry Baker <hb...@pi...>
>>> wrote:
>>>
>>> > A number of computer languages -- e.g., Fortran -- support trig
>>> functions over degrees -- e.g., sind(x), cosd(x), tand(x), asind(x), etc.
>>> >
>>> > I know it's "trivial", but could Maxima please go ahead a define
>>> standardly the trig functions over degrees?  We're talking about about
>>> increasing the core system at most by perhaps 1K bytes !
>>>
>>> Well, maybe the code is trivial, but the increased mental burden is
>>> not ... Instead of creating new functions, I am OK with two functions,
>>> radians(x) to get radians from degrees and degrees(x) to get degrees
>>> from radians. Then one can call those whenever it makes sense.
>>>
>>> We could make those simplifying functions. Just thinking out loud here.
>>>
>>> Hmm, maybe degrees(x) should represent x degrees, like radians(x)
>>> represents x radians. radians(x) simplifies to x and degrees(x)
>>> simplifies to x*%pi/180. E.g. sin(degrees(90)) --> sin(%pi/2), etc.
>>>
>>> I think I'm leaning towards degrees(x) representing x degrees. What
>>> does anyone else think?
>>>
>>> Robert
>>>
>>>
>>> _______________________________________________
>>> Maxima-discuss mailing list
>>> Max...@li...
>>> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>>
>>

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

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

Well, as ugly as switches are, I suppose one could switch from primitives sind/cosd/tand/asind/acosd/atand to primitives sin/cos/tan/asin/acos/atan or back again with a switch.

I agree that things get ugly when using degrees instead of radians, but some usages of degrees are embedded so tightly into the application context that it seems perverse to insist on radians.

Also, if we are sufficiently knowledgeable about the number %pi/180 -- e.g., identities about its various powers -- some "nice" things may happen that are a bit less obvious when working with radians.

-----Original Message-----
From: Stavros Macrakis <mac...@gm...>
Sent: Apr 27, 2026 3:09 PM
To: Henry Baker <hb...@pi...>
Cc: <max...@li...>, Robert Dodier <rob...@gm...>
Subject: Re: [Maxima-discuss] standard trig functions for degrees ?

Henry,
 
I really don't know much about working in degrees. Like Ray, the last time I did that was in high school.
 
If you're working in degrees, how do you write, say, the Taylor expansion of sind(x)? The straightforward way gives
 
taylor(sind(x),x,0,3) =>
             (%pi*x)/180-(%pi^3*x^3)/34992000
 
Do you write that as something like
 
(x&deg;) -(x&deg;)^3/6
?


On Mon, Apr 27, 2026 at 5:15 PM Stavros Macrakis <mac...@gm... (mailto:mac...@gm...)> wrote:
I don't know what exactly Henry wants. If it's just numeric computation, that's trivial. As he says, it's < 1k of code, which he can write himself.
 
The hard part is symbolic computation.

I'd think that someone working in degrees would like to see things like:
 
sind(x/2),halfangles => sqrt(1-cosd(x))/sqrt(2) (for 0<x<360)
 
This gets messier. Yes, you can write pattern matching rules that change all instances of cos(...) to cosd(...), etc.
 
But what about, say, limit(sind(x)/x,x,0)? That gives %pi/180; is that what is expected, or does the user want to see (%pi/180)&deg; or maybe 1? I've never worked in degrees beyond elementary trig, so I don't know what the user expects, and whether the system (as opposed to the user) needs to keep track of degrees vs. radians.
 
Or am I overthinking it?
 
          -s


On Mon, Apr 27, 2026 at 4:45 PM Robert Dodier <rob...@gm... (mailto:rob...@gm...)> wrote:
On Mon, Apr 27, 2026 at 12:48 PM Henry Baker <hb...@pi... (mailto:hb...@pi...)> wrote:

> A number of computer languages -- e.g., Fortran -- support trig functions over degrees -- e.g., sind(x), cosd(x), tand(x), asind(x), etc.
>
> I know it's "trivial", but could Maxima please go ahead a define standardly the trig functions over degrees?  We're talking about about increasing the core system at most by perhaps 1K bytes !

Well, maybe the code is trivial, but the increased mental burden is
not ... Instead of creating new functions, I am OK with two functions,
radians(x) to get radians from degrees and degrees(x) to get degrees
from radians. Then one can call those whenever it makes sense.

We could make those simplifying functions. Just thinking out loud here.

Hmm, maybe degrees(x) should represent x degrees, like radians(x)
represents x radians. radians(x) simplifies to x and degrees(x)
simplifies to x*%pi/180. E.g. sin(degrees(90)) --> sin(%pi/2), etc.

I think I'm leaning towards degrees(x) representing x degrees. What
does anyone else think?

Robert


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

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

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

Henry,

I really don't know much about working in degrees. Like Ray, the last time
I did that was in high school.

If you're working in degrees, how do you write, say, the Taylor expansion
of sind(x)? The straightforward way gives

taylor(sind(x),x,0,3) =>
             (%pi*x)/180-(%pi^3*x^3)/34992000


Do you write that as something like

(x*°*) -(x*°*)^3/6

?

On Mon, Apr 27, 2026 at 5:15 PM Stavros Macrakis <mac...@gm...> wrote:

> I don't know what exactly Henry wants. If it's just numeric computation,
> that's trivial. As he says, it's < 1k of code, which he can write himself.
>
> The hard part is symbolic computation.
>
> I'd think that someone working in degrees would like to see things like:
>
> *sind(x/2),halfangles => sqrt(1-cosd(x))/sqrt(2) *(for 0<x<360)
>
>
> This gets messier. Yes, you can write pattern matching rules that change
> all instances of *cos(...)* to *cosd(...)*, etc.
>
> But what about, say, *limit(sind(x)/x,x,0)*? That gives *%pi/180*; is
> that what is expected, or does the user want to see *(%pi/180)°* or maybe
> *1*? I've never worked in degrees beyond elementary trig, so I don't know
> what the user expects, and whether the system (as opposed to the user)
> needs to keep track of degrees vs. radians.
>
> Or am I overthinking it?
>
>           -s
>
> On Mon, Apr 27, 2026 at 4:45 PM Robert Dodier <rob...@gm...>
> wrote:
>
>> On Mon, Apr 27, 2026 at 12:48 PM Henry Baker <hb...@pi...>
>> wrote:
>>
>> > A number of computer languages -- e.g., Fortran -- support trig
>> functions over degrees -- e.g., sind(x), cosd(x), tand(x), asind(x), etc.
>> >
>> > I know it's "trivial", but could Maxima please go ahead a define
>> standardly the trig functions over degrees?  We're talking about about
>> increasing the core system at most by perhaps 1K bytes !
>>
>> Well, maybe the code is trivial, but the increased mental burden is
>> not ... Instead of creating new functions, I am OK with two functions,
>> radians(x) to get radians from degrees and degrees(x) to get degrees
>> from radians. Then one can call those whenever it makes sense.
>>
>> We could make those simplifying functions. Just thinking out loud here.
>>
>> Hmm, maybe degrees(x) should represent x degrees, like radians(x)
>> represents x radians. radians(x) simplifies to x and degrees(x)
>> simplifies to x*%pi/180. E.g. sin(degrees(90)) --> sin(%pi/2), etc.
>>
>> I think I'm leaning towards degrees(x) representing x degrees. What
>> does anyone else think?
>>
>> Robert
>>
>>
>> _______________________________________________
>> Maxima-discuss mailing list
>> Max...@li...
>> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>>
>

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

[ehm <eri...@gm...>]

On Mon, 2026-04-27 at 13:44 -0700, Robert Dodier wrote:
> 
> Well, maybe the code is trivial, but the increased mental burden is
> not ... Instead of creating new functions, I am OK with two
> functions,
> radians(x) to get radians from degrees and degrees(x) to get degrees
> from radians. Then one can call those whenever it makes sense.
> 
> We could make those simplifying functions. Just thinking out loud
> here.
> 
> 

I'm not necessarily in favor of adding new trivial functions, but if
you do, I would suggest names that are completely unambiguous and
symmetric, like rad2deg() and deg2rad(). It would make them easier to
remember.

-Eric

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

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

On 4/27/26 2:15 PM, Stavros Macrakis wrote:

> I don't know what exactly Henry wants. If it's just numeric 
> computation, that's trivial. As he says, it's < 1k of code, which he 
> can write himself.
>
> The hard part is symbolic computation.
>
> I'd think that someone working in degrees would like to see things like:
>
>     *sind(x/2),halfangles => sqrt(1-cosd(x))/sqrt(2) *(for 0<x<360)
>
>
> This gets messier. Yes, you can write pattern matching rules that 
> change all instances of *cos(...)* to *cosd(...)*, etc.
>
> But what about, say, *limit(sind(x)/x,x,0)*? That gives *%pi/180*; is 
> that what is expected, or does the user want to see *(%pi/180)°***or 
> maybe*1*? I've never worked in degrees beyond elementary trig, so I 
> don't know what the user expects, and whether the system (as opposed 
> to the user) needs to keep track of degrees vs. radians.
>
> Or am I overthinking it?

I think this is the main problem. I have no interest in making the 
degree functions support all the symbolic manipulations that we have.

Like you, I only used degrees for trig computations as done in a high 
school trig class. Anything more means working in radians.

So if that’s what desired, that’s fine with me. Maybe someone will write 
a simple package to compute the trig functions (and inverses) using 
degrees. That could fit in the share or contrib directories. Or on 
someone’s git repo somewhere.

&#8203;

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

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

I don't know what exactly Henry wants. If it's just numeric computation,
that's trivial. As he says, it's < 1k of code, which he can write himself.

The hard part is symbolic computation.

I'd think that someone working in degrees would like to see things like:

*sind(x/2),halfangles => sqrt(1-cosd(x))/sqrt(2) *(for 0<x<360)


This gets messier. Yes, you can write pattern matching rules that change
all instances of *cos(...)* to *cosd(...)*, etc.

But what about, say, *limit(sind(x)/x,x,0)*? That gives *%pi/180*; is that
what is expected, or does the user want to see *(%pi/180)°* or maybe *1*?
I've never worked in degrees beyond elementary trig, so I don't know what
the user expects, and whether the system (as opposed to the user) needs to
keep track of degrees vs. radians.

Or am I overthinking it?

          -s

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

> On Mon, Apr 27, 2026 at 12:48 PM Henry Baker <hb...@pi...> wrote:
>
> > A number of computer languages -- e.g., Fortran -- support trig
> functions over degrees -- e.g., sind(x), cosd(x), tand(x), asind(x), etc.
> >
> > I know it's "trivial", but could Maxima please go ahead a define
> standardly the trig functions over degrees?  We're talking about about
> increasing the core system at most by perhaps 1K bytes !
>
> Well, maybe the code is trivial, but the increased mental burden is
> not ... Instead of creating new functions, I am OK with two functions,
> radians(x) to get radians from degrees and degrees(x) to get degrees
> from radians. Then one can call those whenever it makes sense.
>
> We could make those simplifying functions. Just thinking out loud here.
>
> Hmm, maybe degrees(x) should represent x degrees, like radians(x)
> represents x radians. radians(x) simplifies to x and degrees(x)
> simplifies to x*%pi/180. E.g. sin(degrees(90)) --> sin(%pi/2), etc.
>
> I think I'm leaning towards degrees(x) representing x degrees. What
> does anyone else think?
>
> 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 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.
> I am inclined to remove optimize.lisp. Inlining makes it harder or
> impossible to trace functions, which I believe outweighs the speed
> gain.
Hopefully, Camm can provide some insight on this.
> 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.

I’ll try to look up some history on this soon. I don’t build or test 
with gcl very often.

&#8203;

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

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

On Mon, Apr 27, 2026 at 12:48 PM Henry Baker <hb...@pi...> wrote:

> A number of computer languages -- e.g., Fortran -- support trig functions over degrees -- e.g., sind(x), cosd(x), tand(x), asind(x), etc.
>
> I know it's "trivial", but could Maxima please go ahead a define standardly the trig functions over degrees?  We're talking about about increasing the core system at most by perhaps 1K bytes !

Well, maybe the code is trivial, but the increased mental burden is
not ... Instead of creating new functions, I am OK with two functions,
radians(x) to get radians from degrees and degrees(x) to get degrees
from radians. Then one can call those whenever it makes sense.

We could make those simplifying functions. Just thinking out loud here.

Hmm, maybe degrees(x) should represent x degrees, like radians(x)
represents x radians. radians(x) simplifies to x and degrees(x)
simplifies to x*%pi/180. E.g. sin(degrees(90)) --> sin(%pi/2), etc.

I think I'm leaning towards degrees(x) representing x degrees. What
does anyone else think?

Robert

[Maxima-discuss] standard trig functions for degrees ?

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

A number of computer languages -- e.g., Fortran -- support trig functions over degrees -- e.g., sind(x), cosd(x), tand(x), asind(x), etc.

I know it's "trivial", but could Maxima please go ahead a define standardly the trig functions over degrees?  We're talking about about increasing the core system at most by perhaps 1K bytes !

I don't mind the names sind, cosd, tand, but wouldn't it be more intuitive to have the inverse functions named dasin, dacos, datan, etc. ?

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

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

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.

I am inclined to remove optimize.lisp. Inlining makes it harder or
impossible to trace functions, which I believe outweighs the speed
gain.

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.

FWIW

Robert

[Maxima-discuss] Some more questions about defsystem modules

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

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.

I also haven’t tried to compile maxima with these things removed. Maybe 
that would explain why they’re important.

​

Re: [Maxima-discuss] *large-positive-number* defined twice

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

Commit [6dac3c]<https://sourceforge.net/p/maxima/code/ci/6dac3c3e0ff74f340b072872f906f57b02a6e272/>  master

--Barton
________________________________
From: Raymond Toy <toy...@gm...>
Sent: Sunday, April 26, 2026 9:32 AM
To: Barton Willis <wi...@un...>; <max...@li...> <max...@li...>
Subject: Re: [Maxima-discuss] *large-positive-number* defined twice

Caution: Non-NU Email


On 4/25/26 6:49 PM, Barton Willis wrote:

Thanks for catching my flub.  It seems that the definition in tlimit should be changed to

;; For limits toward `inf`, assume that the limit variable exceeds `*large-positive-number*`
(defmvar *large-positive-number*  (expt 10 8))

And in a couple of places in limit.lisp, we should change 100000000 to
`*large-positive-number*`.


I can make these changes early next week, or if you want to get it done sooner, that's great too.

I’m not in any hurry. This was noted by Claude when I asked it to look for circular dependencies between the tlimit and limit. They are pretty tightly coupled with mutual calls between the two which are hard to separate.

Thanks.

--Barton


________________________________
From: Raymond Toy <toy...@gm...><mailto:toy...@gm...>
Sent: Saturday, April 25, 2026 6:56 PM
To: <max...@li...><mailto:max...@li...> <max...@li...><mailto:max...@li...>
Subject: [Maxima-discuss] *large-positive-number* defined twice


Caution: Non-NU Email


The specvar *large-positive-number* is defined twice. Once in tlimit.lisp and the second in limit.lisp. Only those two files use it. Since tlimit.lisp is compiled first, the actual value is from tlimit.lisp. Since the comment in tlimit says the choice of [2^{42}]  was arbitrary, maybe remove the definition from tlimit.

Well, that’s not quite right since tlimit is compiled first. So use the value from limit.lisp and remove the definition from tlimit?

&#8203;
&#8203;

Re: [Maxima-discuss] integrate bug

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

Coffee inspired idea:  There is no Maxima-level interface to this, but with one line of Common Lisp, we can do this:

%i1) :lisp(putprop '$f '((x) (($ff) x)) 'integral);

((X) (($FF) X))

Now we can do:

(%i1)  integrate(f(y(x))*diff(y(x),x),x);
(%o1)                              ff(y(x))


Maybe somebody would like to build a Maxima function that allows a user to declare the antiderivative of a function.

--Barton
________________________________
From: Barton Willis via Maxima-discuss <max...@li...>
Sent: Monday, April 27, 2026 4:59 AM
To: Aleksas Domarkas <ale...@gm...>; <max...@li...> <max...@li...>
Subject: Re: [Maxima-discuss] integrate bug

Caution: Non-NU Email



This isn't an answer to your question, but the user documentation for integrate states:

" integrate does not respect implicit dependencies established by the depends<https://urldefense.com/v3/__https://maxima.sourceforge.io/docs/manual/maxima_singlepage.html*depends__;Iw!!PvXuogZ4sRB2p-tU!CLY3z-JfJBA0okYLkEptJxh6X75cKWTLE4FUu3W-beCDzoZ2YBuigIy71MxOPVNeysWpER47Q7GRnDC34dIk0Q5Vn6wvM20Prg$> function."

One way to avoid the outativity is to make the dependence explicit:

(%i4)  integrate(f(y(x))*diff(y(x),x),x);
(%o4) integrate(f(y(x))*('diff(y(x),x,1)),x)

Notice that integrate can handle

(%i11)       integrate(cos(y(x))*diff(y(x),x),x);
(%o11)      sin(y(x))

But Maxima doesn't have a feature that allows a user to declare that F is an antiderivative of f. Maybe somebody would like to work on that.

--Barton




________________________________
From: Aleksas Domarkas <ale...@gm...>
Sent: Monday, April 27, 2026 1:35 AM
To: <max...@li...> <max...@li...>
Subject: [Maxima-discuss] integrate bug

Caution: Non-NU Email

 --> depends(y,x);
(%o1) [y(x)]
 --> integrate(f(y)*diff(y,x),x);
(%o39) f(y)*integrate('diff(y,x),x)
 --> constantp(f(y));
(%o2) false
Why integrate is outative for not constant ?

Aleksas

Re: [Maxima-discuss] integrate bug

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

This isn't an answer to your question, but the user documentation for integrate states:

" integrate does not respect implicit dependencies established by the depends<https://maxima.sourceforge.io/docs/manual/maxima_singlepage.html#depends> function."

One way to avoid the outativity is to make the dependence explicit:

(%i4)  integrate(f(y(x))*diff(y(x),x),x);
(%o4) integrate(f(y(x))*('diff(y(x),x,1)),x)

Notice that integrate can handle

(%i11)       integrate(cos(y(x))*diff(y(x),x),x);
(%o11)      sin(y(x))

But Maxima doesn't have a feature that allows a user to declare that F is an antiderivative of f. Maybe somebody would like to work on that.

--Barton




________________________________
From: Aleksas Domarkas <ale...@gm...>
Sent: Monday, April 27, 2026 1:35 AM
To: <max...@li...> <max...@li...>
Subject: [Maxima-discuss] integrate bug

Caution: Non-NU Email

 --> depends(y,x);
(%o1) [y(x)]
 --> integrate(f(y)*diff(y,x),x);
(%o39) f(y)*integrate('diff(y,x),x)
 --> constantp(f(y));
(%o2) false
Why integrate is outative for not constant ?

Aleksas

[Maxima-discuss] integrate bug

[Aleksas D. <ale...@gm...>]

 --> depends(y,x);
(%o1) [y(x)]
 --> integrate(f(y)*diff(y,x),x);
(%o39) f(y)*integrate('diff(y,x),x)
 --> constantp(f(y));
(%o2) false
Why integrate is outative for not constant ?

Aleksas

Re: [Maxima-discuss] def-simplifier for variable arity functions?

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

On 4/26/26 10:54 AM, Stavros Macrakis wrote:

>
>
> There are other nary operators which /should/ be simplifying, namely 
> *and/or*. Again, my code for that is almost done.
>
> According to its comments, *def-simplifier *(in *defmfun-check.lisp*) 
> explicitly does not address the nary case: "the args for the 
> simplifier only supports a fixed set of required arguments". It would 
> be nice to fix that.

I confess on not looking at the comments. I’ll look into it, but it 
would really be helpful if I had a simplifier (without using 
def-simplifier) to look at.

Based on the this thread, it looks like we’re mostly looking for things 
with |&rest| args. So not a simplifier with a finite number of args of 
which some or all are optional.

​

Re: [Maxima-discuss] def-simplifier for variable arity functions?

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

No, I was only contemplating changing

(defun simp-set (a yy z)
  (declare (ignore yy))
  ....


     to use the new def-simplifier macro.  That would, I think, change a set object from (($set simp) ...) to ((%set simp) ....).  It makes the code more uniform, but it makes no difference to the user, right?

--Barton
________________________________
From: Stavros Macrakis <mac...@gm...>
Sent: Sunday, April 26, 2026 12:54 PM
To: Barton Willis <wi...@un...>
Cc: Raymond Toy <toy...@gm...>; max...@li... <max...@li...>
Subject: Re: [Maxima-discuss] def-simplifier for variable arity functions?

Caution: Non-NU Email

I assume that by "convert sets to be noun/verb compliant", you mean to make intersection, union, etc. into simplifying functions? That sounds very valuable! As I suggested in my previous email, I already have some (not quite ready for prime time) code for simplifying, e.g., union(a,a) => a, etc.

It looks like set itself is already a simplifying function:

   simp:false$ set(a,b,a) => set(a,b,a)

There are other nary operators which should be simplifying, namely and/or. Again, my code for that is almost done.

According to its comments, def-simplifier (in defmfun-check.lisp) explicitly does not address the nary case: "the args for the simplifier only supports a fixed set of required arguments". It would be nice to fix that.



On Sun, Apr 26, 2026 at 11:12 AM Barton Willis via Maxima-discuss <max...@li...<mailto:max...@li...>> wrote:
Simplify a set—I was wondering what would happen if we converted sets to be noun/verb compliant. The easiest way to achieve that would be to use def-simplifier.

The only other example of a non-fixed arity function is the humble list, but unlike sets, lists do not have a simplifier.
________________________________
From: Raymond Toy <toy...@gm...<mailto:toy...@gm...>>
Sent: Sunday, April 26, 2026 9:29 AM
To: max...@li...<mailto:max...@li...> <max...@li...<mailto:max...@li...>>
Subject: Re: [Maxima-discuss] def-simplifier for variable arity functions?

Caution: Non-NU Email


On 4/25/26 4:57 PM, Barton Willis via Maxima-discuss wrote:

Does def-simplifier handle variable arity functions?
Do you have an example?




_______________________________________________
Maxima-discuss mailing list
Max...@li...<mailto:Max...@li...>
https://lists.sourceforge.net/lists/listinfo/maxima-discuss<https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/maxima-discuss__;!!PvXuogZ4sRB2p-tU!D2u-7mnlfbSfPuxgCitIo-zzLSOrUw1dDjHpkEASH0fO_bNDf03W1TMS9M6VeCjwgpPn2wo2AyF1qnF_6F4$>


&#8203;
_______________________________________________
Maxima-discuss mailing list
Max...@li...<mailto:Max...@li...>
https://lists.sourceforge.net/lists/listinfo/maxima-discuss<https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/maxima-discuss__;!!PvXuogZ4sRB2p-tU!EAGnlEDaGouRc-Td0Dmto0KX0UgmTC7KB5zCMOCJ8YbVicBD2zqKq7pEOB1z2nE9DJwGVfsCBtJl4is$>

Re: [Maxima-discuss] def-simplifier for variable arity functions?

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

I assume that by "convert sets to be noun/verb compliant", you mean to
make *intersection,
union, *etc. into simplifying functions? That sounds very valuable! As I
suggested in my previous email, I already have some (not quite ready for
prime time) code for simplifying, e.g., *union(a,a) => a*, etc.

It looks like *set* itself is already a simplifying function:

   simp:false$ set(a,b,a) => set(a,b,a)

There are other nary operators which *should* be simplifying, namely
*and/or*. Again, my code for that is almost done.

According to its comments, *def-simplifier *(in *defmfun-check.lisp*)
explicitly does not address the nary case: "the args for the simplifier
only supports a fixed set of required arguments". It would be nice to fix
that.



On Sun, Apr 26, 2026 at 11:12 AM Barton Willis via Maxima-discuss <
max...@li...> wrote:

> Simplify a set—I was wondering what would happen if we converted sets to
> be noun/verb compliant. The easiest way to achieve that would be to use
> def-simplifier.
>
> The only other example of a non-fixed arity function is the humble list,
> but unlike sets, lists do not have a simplifier.
> ------------------------------
> *From:* Raymond Toy <toy...@gm...>
> *Sent:* Sunday, April 26, 2026 9:29 AM
> *To:* max...@li... <
> max...@li...>
> *Subject:* Re: [Maxima-discuss] def-simplifier for variable arity
> functions?
>
> Caution: Non-NU Email
>
> On 4/25/26 4:57 PM, Barton Willis via Maxima-discuss wrote:
>
> Does def-simplifier handle variable arity functions?
>
> Do you have an example?
>
>
>
> _______________________________________________
> Maxima-discuss mailing lis...@li...://lists.sourceforge.net/lists/listinfo/maxima-discuss <https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/maxima-discuss__;!!PvXuogZ4sRB2p-tU!D2u-7mnlfbSfPuxgCitIo-zzLSOrUw1dDjHpkEASH0fO_bNDf03W1TMS9M6VeCjwgpPn2wo2AyF1qnF_6F4$>
>
> &#8203;
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>

Re: [Maxima-discuss] integrate in pdiff

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

I don't have an answer to your question, and I can't even do this using antidiff, gradef, and the like:

(%i1) display2d : false$

(%i2) gradef(f(x,y), fx(x,y), fy(x,y))$

(%i3) depends(y,x)$

(%i4) rrr : diff(f(x,y),x);

(%o4) fy(x,y)*'diff(y,x,1)+fx(x,y)
(%i5) integrate(rrr,x);

(%o5) 'integrate(fy(x,y)*'diff(y,x,1)+fx(x,y),x)

(%i6) load(antid)

(no success)

Let us know what you discover.

--Barton
________________________________
From: Aleksas Domarkas <ale...@gm...>
Sent: Sunday, April 26, 2026 10:17 AM
To: <max...@li...> <Max...@li...>
Subject: [Maxima-discuss] integrate in pdiff

Caution: Non-NU Email

load(pdiff);
r:diff(f(x,y(x)),x);

How integrate(r,x)  ?

I wont get  f(x,y(x))

I solve ode from Kamke 6.55
'diff(y,x,2)+('diff(y,x)^2+1)*(f(x,y)*'diff(y,x)+g(x,y))=0;

Aleksas

[Maxima-discuss] integrate in pdiff

[Aleksas D. <ale...@gm...>]

load(pdiff);
r:diff(f(x,y(x)),x);

How integrate(r,x)  ?

I wont get  f(x,y(x))

I solve ode from Kamke 6.55
'diff(y,x,2)+('diff(y,x)^2+1)*(f(x,y)*'diff(y,x)+g(x,y))=0;

Aleksas

Re: [Maxima-discuss] def-simplifier for variable arity functions?

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

Simplify a set—I was wondering what would happen if we converted sets to be noun/verb compliant. The easiest way to achieve that would be to use def-simplifier.

The only other example of a non-fixed arity function is the humble list, but unlike sets, lists do not have a simplifier.
________________________________
From: Raymond Toy <toy...@gm...>
Sent: Sunday, April 26, 2026 9:29 AM
To: max...@li... <max...@li...>
Subject: Re: [Maxima-discuss] def-simplifier for variable arity functions?

Caution: Non-NU Email


On 4/25/26 4:57 PM, Barton Willis via Maxima-discuss wrote:

Does def-simplifier handle variable arity functions?
Do you have an example?




_______________________________________________
Maxima-discuss mailing list
Max...@li...<mailto:Max...@li...>
https://lists.sourceforge.net/lists/listinfo/maxima-discuss<https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/maxima-discuss__;!!PvXuogZ4sRB2p-tU!D2u-7mnlfbSfPuxgCitIo-zzLSOrUw1dDjHpkEASH0fO_bNDf03W1TMS9M6VeCjwgpPn2wo2AyF1qnF_6F4$>


&#8203;

Re: [Maxima-discuss] *large-positive-number* defined twice

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

On 4/25/26 6:49 PM, Barton Willis wrote:

> Thanks for catching my flub.  It seems that the definition in tlimit 
> should be changed to
>
> ;; For limits toward `inf`, assume that the limit variable exceeds 
> `*large-positive-number*`
> (defmvar *large-positive-number*  (expt 10 8))
>
> And in a couple of places in limit.lisp, we should change 100000000 to
> `*large-positive-number*`.
>
>
> I can make these changes early next week, or if you want to get it 
> done sooner, that's great too.

I’m not in any hurry. This was noted by Claude when I asked it to look 
for circular dependencies between the tlimit and limit. They are pretty 
tightly coupled with mutual calls between the two which are hard to 
separate.

>
> Thanks.
>
> --Barton
>
>
> ------------------------------------------------------------------------
> *From:* Raymond Toy <toy...@gm...>
> *Sent:* Saturday, April 25, 2026 6:56 PM
> *To:* <max...@li...> 
> <max...@li...>
> *Subject:* [Maxima-discuss] *large-positive-number* defined twice
>
> 	
> Caution: Non-NU Email
>
>
> The specvar |*large-positive-number*| is defined twice. Once in 
> tlimit.lisp and the second in limit.lisp. Only those two files use it. 
> Since tlimit.lisp is compiled first, the actual value is from 
> tlimit.lisp. Since the comment in tlimit says the choice of 2^{42} was 
> arbitrary, maybe remove the definition from tlimit.
>
> Well, that’s not quite right since tlimit is compiled first. So use 
> the value from limit.lisp and remove the definition from tlimit?
>
> &#8203;
&#8203;

Re: [Maxima-discuss] def-simplifier for variable arity functions?

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

On 4/25/26 4:57 PM, Barton Willis via Maxima-discuss wrote:

> Does def-simplifier handle variable arity functions?
Do you have an example?
>
>
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
​