newRPL: [UPDATED April 27-2017] Firmware for testing available for download

[Claudio L.]

(10-25-2015 10:46 PM)matthiaspaul Wrote:  Your ANGUNIT would address the problem as well, but is still quite long to type.
I was hoping we could find something shorter, ideally as short as choosing ∠, [->]∠, [<-]∠ in the Units.Angle soft menu or typing a "special" unit like _∠ .

That shouldn't be a problem: →∠ is available instead of ANGUNIT. Remember, longer to type won't be that much of a problem with the new Autocomplete function.

(10-25-2015 10:46 PM)matthiaspaul Wrote:  There's one more potential problem, but it applies to ANGUNIT as well as my idea to replace the _∠ by the actual unit on the first attempt to interpret this as a unit:

If the angular mode is changed after the ASIN, but before the invocation of ANGUNIT or the evalulation of _∠, it would reflect the new angular mode, not the one active while ASIN was executed.

I don't see this as a big deal. If you want to attach units you'd use ASIN →∠ immediately, this is not a multitasking environment where the flags could change in the background.

(10-25-2015 10:46 PM)matthiaspaul Wrote:  Alternatively, seeking for a simple solution, if the behaviour of functions like ASIN would be changed to attach the angular unit by default (perhaps depending on a flag), what were the effects on existing RPL programs only expecting such functions to return unit-less numbers?

I work mainly in radians, and angles, while treated as a physical magnitude for unit purposes, it's actually a non-dimensional quantity by definition (arc_length/radius), so even when I'm working with units, my angles are always unit-less.
Angular velocity is 1/s (or r/s if you use angular units), and multiplied by a distance is supposed to be m/s, not m*r/s.
So I'm not a fan of adding units by default, as angles work best when unit-less in my opinion.