newRPL: Angles revisited

[Nigel (UK)]

(04-01-2016 11:15 PM)Claudio L. Wrote:  This could be a problem. For example an expression:
'ASIN(A)*ASIN(A)/ASIN(A)'. The user has the settings in DEG, and thinks ASIN will return DEG, so you would expect the result to be let's say 45 or ∡45°.
If the operator associates the right side first:
ASIN(A)*(ASIN(A)/ASIN(A)) = ASIN(A)*1 = ∡45°

but if it associates from the left:
(ASIN(A)*ASIN(A))/ASIN(A) = (pi/4)^2/∡45° = pi/4 (correct, but in radians!)

With the "angle is a number" approach:
ASIN(A)*(ASIN(A)/ASIN(A)) = ASIN(A)*1 = ∡45°
(ASIN(A)*ASIN(A))/ASIN(A) = 45^2 / ∡45° = 45 (not an angle, but at least the same number as expected)

On the other hand, the "angle is a number" can also give bad results in expressions with mixed systems:

'∡50g*2/∡90°'
If associated from the left:
(∡50g*2)/∡90° = ∡100g/∡90° = 1
versus:
∡50g*(2/∡90°)= ∡50g*(1/45)= ∡1.11111111111111g

This can seriously drive a user crazy. What could be a solution for this?

Suppose we allow powers - positive and negative - of these angle tags. Then:
45D * 45D / 45D is 45D whichever way we associate, and
50G * 2 / 90D is always going to be 1.

A rule saying that when adding an angle to a number, the number has an implicit tag corresponding to the current angular mode but that there are no implicit tags for multiplication or division would make me happy, but I expect that you would prefer the tag for addition to come from the first argument.

There should be a function that at any point removes a tag, including its powers, leaving a number that depends on the current angular mode. This function will be called if an operation is performed that makes no sense for angles.

Does this work? If so, does it introduce new problems that I haven't yet considered?

Nigel (UK)

[SlideRule]

(03-31-2016 06:13 PM)Claudio L. Wrote:  A few months back there was a discussion on how to treat angular values in trig functions.
Using units of angle wasn't practical because angles are in reality unitless, and adding units makes them inconsistent with a simple numeric input.
Any thoughts?

Sorry to enter this thread a little late, but...
I START with this conceptual notion; angle is the measure of rotation. I think of rotation as ill-defined fundamental unit (#8 of 7), such as temperature, time, etc. related to but separate from length. Thoughts?

SlideRule

[Vtile]

(04-03-2016 04:27 PM)SlideRule Wrote:  

(03-31-2016 06:13 PM)Claudio L. Wrote:  A few months back there was a discussion on how to treat angular values in trig functions.
Using units of angle wasn't practical because angles are in reality unitless, and adding units makes them inconsistent with a simple numeric input.
Any thoughts?

Sorry to enter this thread a little late, but...
I START with this conceptual notion; angle is the measure of rotation. I think of rotation as ill-defined fundamental unit (#8 of 7), such as temperature, time, etc. related to but separate from length. Thoughts?

SlideRule

It is also measure of time ie. in EE with phasors (f=constant) if we get philosophical P=U*I*Cos(Phi), as it is there for the difference of the phase of the I and U in timedomain. Now when phasors are mentioned, will there be traditional non-tagged method of using angles, by just using bare numbers. I think these two methods can't be separated in discussion they must work together and I go as far as saying that tagging should be more like an option to those who are jumping between O/(decided slicing method).

Ie. If I'm creating impedance (or any Dance) from capacitor 1/(j*2*Pi*f) etc. edit(.. and adding it ..) to existing impedance in polar representation in degrees I wouldn't want it to be some symbolic mess because of the 2*Pi which is radian representation of on full O.

Interesting subject, I like to read these on MoHPC. Would be nice to know what angle is in an eyes of mathematician percentage, direction, factor, way of divide Italian food ??

[Claudio L.]

(04-03-2016 08:12 PM)Vtile Wrote:  Interesting subject, I like to read these on MoHPC. Would be nice to know what angle is in an eyes of mathematician percentage, direction, factor, way of divide Italian food ??

I'm no mathematician, but I learnt long time ago than angles in radians are the ratio of the arc length to the radius (works on a pizza if you like italian food...). Based on that definition it's a non-dimensional unit (m/m).
That's why is doesn't play well with a unit system. It's a unit in its own right, but yet it's non-dimensional, so it has to be consistent with raw numbers.
The current unit system in the 50g or newRPL doesn't achieve this property. 1_r + 1 gives you inconsistent unit error, while in reality the operation should proceed.
Angular velocity in r/s times the radius in m should give you linear velocity in m/s, not in m*r/s.
So angles are always a pain to handle properly. Then we add several ways to measure angles (deg, grad), and throw in there different ways to represent the same measurement (decimal degrees, vs dms), and you have a perfect storm.

Really hard to handle correctly, I thought I had a good idea when I started this thread, now I'm not convinced.

[Claudio L.]

(04-03-2016 11:05 AM)Nigel (UK) Wrote:  Suppose we allow powers - positive and negative - of these angle tags.

OK, but that's what the unit system does. It takes space, and a lot of extra overhead to operate because it's not a number, it's a number raised to a power. And after you allow powers, you end up having to handle fractional powers too, and then... you have a full blown unit system, same as using 1_r really, except we have to somehow "guess" when is a good time to drop the unit and convert to a number, and when that unit is needed.

[Claudio L.]

Since I can't find a way to make things work correctly, I think we should drop the part that doesn't work and simplify:

* Tagged angles could be used for user entry.
* Tagged angles could be used for return values of trig functions.
* Any operation (I mean any) done on a tagged angle will convert it to the current angle system and remove the tag prior to doing the operation itself.
* Commands will exist to convert between all tag formats, and to explicitly tag a number.

I know it will eliminate many of the useful features (like directly adding/subtracting angles in DMS), but at least won't introduce any weirdness.

[Claudio L.]

(04-04-2016 11:52 AM)Claudio L. Wrote:  Since I can't find a way to make things work correctly, I think we should drop the part that doesn't work and simplify:

* Tagged angles could be used for user entry.
* Tagged angles could be used for return values of trig functions.
* Any operation (I mean any) done on a tagged angle will convert it to the current angle system and remove the tag prior to doing the operation itself.
* Commands will exist to convert between all tag formats, and to explicitly tag a number.

I know it will eliminate many of the useful features (like directly adding/subtracting angles in DMS), but at least won't introduce any weirdness.

I guess there's no harm in adding this:
* Addition/subtraction between 2 tagged angles returns a tagged angle with the same system as the left argument.
All other operations, or if angles get mixed with numbers, will convert to current angle system units and remove the tag, then operate.

[Helix]

So, if I understand correctly:
If the current angle mode is DEG, then '∡1r * 2' = 114.59 ?

[Claudio L.]

(04-07-2016 01:04 PM)Helix Wrote:  So, if I understand correctly:
If the current angle mode is DEG, then '∡1r * 2' = 114.59 ?

Yes.

[Nigel (UK)]

(04-06-2016 01:58 PM)Claudio L. Wrote:  

(04-04-2016 11:52 AM)Claudio L. Wrote:  Since I can't find a way to make things work correctly, I think we should drop the part that doesn't work and simplify:

* Tagged angles could be used for user entry.
* Tagged angles could be used for return values of trig functions.
* Any operation (I mean any) done on a tagged angle will convert it to the current angle system and remove the tag prior to doing the operation itself.
* Commands will exist to convert between all tag formats, and to explicitly tag a number.

I know it will eliminate many of the useful features (like directly adding/subtracting angles in DMS), but at least won't introduce any weirdness.

I guess there's no harm in adding this:
* Addition/subtraction between 2 tagged angles returns a tagged angle with the same system as the left argument.
All other operations, or if angles get mixed with numbers, will convert to current angle system units and remove the tag, then operate.

I think this approach should be useful without adding too much complexity either to the code or to what the user has to learn.

This discussion made me go back and look at the code for my RPN calculator for Casio machines. There is one feature which I had forgotten: a complex number carries an angle tag (radian or degrees) which specifies the angle display mode when polar display is chosen. So a complex number can be entered as polar, displayed as rectangular, and later displayed as polar still keeping the angle tag that the polar angle was entered with. Is this idea at all useful, or is it making things too complicated - especially as newRPL has to support 3D vectors?

Nigel (UK)

[Claudio L.]

(04-07-2016 01:55 PM)Nigel (UK) Wrote:  This discussion made me go back and look at the code for my RPN calculator for Casio machines. There is one feature which I had forgotten: a complex number carries an angle tag (radian or degrees) which specifies the angle display mode when polar display is chosen. So a complex number can be entered as polar, displayed as rectangular, and later displayed as polar still keeping the angle tag that the polar angle was entered with. Is this idea at all useful, or is it making things too complicated - especially as newRPL has to support 3D vectors?

Nigel (UK)

I intend to eliminate the "polar" mode altogether. Complex numbers and vectors can be created in polar mode by simply including angles in their definition. Once polar, it's always polar, unless a command is used to convert it to cartesian. Operations will detect this and proceed accordingly (again, keeping the format of the "left" argument to decide the format of the result).
Basically you compute with vectors, and you convert to polar the results you want to see in polar form. Or, you operate with everything in polar form and get results directly in polar form.

This starts getting weird when you add a vector as a matrix row. In such case polar vectors will have to be converted to cartesian before inserting in a matrix.
Also product of matrix*vector will have to convert to cartesian.

[Francois Lanciault]

Sorry if this has been explained before but now that angles have been implemented in the current (and previous) firmware version, how can I enter the "angle" prefix symbol or de postfix "degree" symbol on the calculator in order to create a tagged angle value ?

Thank you.

[Claudio L.]

(05-10-2016 04:48 AM)Francois Lanciault Wrote:  Sorry if this has been explained before but now that angles have been implemented in the current (and previous) firmware version, how can I enter the "angle" prefix symbol or de postfix "degree" symbol on the calculator in order to create a tagged angle value ?

Thank you.

No need to be sorry, this has never been asked before and is not documented anywhere.
The keyboard is mapped as follows:
In Alpha mode (L or C):
Right-Shift + 6 = Angle symbol (not right-shift-hold, that does superscript numbers on all numbers)
Left-Shift + 6 (or left-shift-hold+6) = Degree symbol
Left-Shift + 9 (or left-shift-hold+9) = Delta symbol for the new temperatures, so it's close to the degree for quick typing.