newRPL - build 1255 released! [updated to 1299]

[3298]

Going on a tangent again...

(04-28-2019 08:30 AM)Gilles Wrote:  If I'm not mistaken, RPL has no specific object for 'angle'.

It has. The stock firmware uses the regular units system for them, which also gives you angle conversion for free. (100_grad 1_arcmin CONVERT -> 5400_arcmin) Even plain numbers are accepted for conversions, CONVERT treats them as having the unit of the current angle mode just like the trig commands do!
The only thing missing is a way to output in DMS. Input is possible by adding numbers with \^o, arcmin, arcs units together; slightly unwieldy, but it works.
Fortunately, DMS output could be retrofitted like this:

Code:

\<<
  DUP 1._\^o CONVERT IP
  OVER 1._arcmin CONVERT IP OVER 1._arcmin CONVERT -
  ROT 1._arcs CONVERT PICK3 PICK3 + 1._arcs CONVERT -
\>>

... That little program splits any angle into the three DMS components. (Lots of CONVERT here, but a simple variant down-converting through \^o, arcmin, arcs and splitting via DUP IP SWAP FP tends to introduce rounding errors when it receives a value that is in arcmin or arcs already.) Maybe this is not settable as a mode, but you can stick the program into a custom menu or a key definition so it's available on demand...
Even better, with library 256 you can have it construct a symbolic object containing the unevaluated sum, which would only occupy a single stack level instead of three. (Inspired by what complex numbers look like when flag -27 is set.)

Code:

\<<
  DUP 1._\^o CONVERT IP
  OVER 1._arcmin CONVERT IP OVER 1._arcmin CONVERT -
  ROT 1._arcs CONVERT PICK3 PICK3 + 1._arcs CONVERT -
  { + } OBJ\-> DROP DUP UNROT 5. \->ALG
\>>

Unlike complex numbers this needs an EVAL to be accepted for conversion. Other calculations get appended without being carried out; all of this happens because it's no longer a unit object but an algebraic instead.

Claudio, what will happen to existing programs using unit objects for angles - will they work in newRPL at some point?