Re: ideas about representing degrees as Maxima expressions

On Wed, Apr 29, 2026 at 9:19 AM Stavros Macrakis <[email protected]> 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 mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/maxima-discuss