Re: 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 <[email protected]> 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 <[email protected]>
> Sent: Apr 27, 2026 3:09 PM
> To: Henry Baker <[email protected]>
> Cc: <[email protected]>, Robert Dodier <
> [email protected]>
> 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 <[email protected]>
> 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 <[email protected]>
>> wrote:
>>
>>> On Mon, Apr 27, 2026 at 12:48 PM Henry Baker <[email protected]>
>>> 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
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>>
>>

_______________________________________________
Maxima-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/maxima-discuss