03-31-2016, 06:13 PM

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.

So here's another proposal: Make angles first-class citizens, with its own object type, and its own syntax.

With this system, an angle is basically a "tagged" real number, with the tag indicating: first that it's an angle, and second, which angle system it's using. The syntax could be:

∡90 (in the current system angle mode)

∡90° (in degrees)

∡90.1030d (in DMS notation)

∡1.57r (in radians)

∡200g (in grads)

Operations involving angles and "normal" numbers will disregard the unit (except for DMS notation, which needs to be converted first to degrees).

Operations between angles and between angles and numbers will keep the tag of the first argument (consistent with the behavior used for binary integers).

∡90° 1 + --> ∡91°

1 ∡90° + --> 91

∡90.3000d 1.5 + --> ∡92.0000d

1.5 ∡90.3000d + --> 92

These angle quantities can be freely used as numbers inside other objects, for example:

(1 , ∡90°) becomes a complex expressed in polar notation.

[1 ∡90°] same thing for 2D vectors

[1 ∡45° ∡90°] Spherical polar vector

[1 ∡90° 1] Cylindrical polar vector

[∡90° ∡45° ∡90°] Spherical polar vector with magnitude 90 (first angle will be interpreted as just a number)

EDIT: Forgot to mention, you can mix and match different angle units in a spherical vector.

Functions like SIN would recognize the angle in arguments properly.

Commands like ASIN will always return angle objects in the current angle system. Since these objects also behave like numbers, this wouldn't break compatibility with old code.

A command to convert between angle types would have to be provided, although adding 0 would be just as effective:

∡0° ∡90.3000d + --> ∡90.5°

Or even better, commands to force an angle into a particular mode:

→∡r would take any number and tag it as an angle in radians. Also convert to radians if the argument is already an angle.

→∡d same for DMS.

→∡°

→∡g

-1 ASIN would return ∡-90° if the current mode is DEG.

-1 ASIN →∡r would guarantee a result in radians regardless of current mode.

→∡d SIN would force SIN to interpret its input as DMS, regardless of the current flags. If the user gives a number, the given number will be "tagged" as an angle in DMS.

For a CAS system, SIN should be forced into radians regardless of system flags, so instead of asking the user "switch to radians mode?", perhaps SIN should ALWAYS interpret numbers as radians, and the user needs to use the proper →∡° command if the input is not in radians. This would break compatibility with old code using degrees, but would make SIN consistent with the CAS behavior.

Unit objects would also have angle units, I gues they would have to coexist (??)

Any thoughts?

Using units of angle wasn't practical because angles are in reality unitless, and adding units makes them inconsistent with a simple numeric input.

So here's another proposal: Make angles first-class citizens, with its own object type, and its own syntax.

With this system, an angle is basically a "tagged" real number, with the tag indicating: first that it's an angle, and second, which angle system it's using. The syntax could be:

∡90 (in the current system angle mode)

∡90° (in degrees)

∡90.1030d (in DMS notation)

∡1.57r (in radians)

∡200g (in grads)

Operations involving angles and "normal" numbers will disregard the unit (except for DMS notation, which needs to be converted first to degrees).

Operations between angles and between angles and numbers will keep the tag of the first argument (consistent with the behavior used for binary integers).

∡90° 1 + --> ∡91°

1 ∡90° + --> 91

∡90.3000d 1.5 + --> ∡92.0000d

1.5 ∡90.3000d + --> 92

These angle quantities can be freely used as numbers inside other objects, for example:

(1 , ∡90°) becomes a complex expressed in polar notation.

[1 ∡90°] same thing for 2D vectors

[1 ∡45° ∡90°] Spherical polar vector

[1 ∡90° 1] Cylindrical polar vector

[∡90° ∡45° ∡90°] Spherical polar vector with magnitude 90 (first angle will be interpreted as just a number)

EDIT: Forgot to mention, you can mix and match different angle units in a spherical vector.

Functions like SIN would recognize the angle in arguments properly.

Commands like ASIN will always return angle objects in the current angle system. Since these objects also behave like numbers, this wouldn't break compatibility with old code.

A command to convert between angle types would have to be provided, although adding 0 would be just as effective:

∡0° ∡90.3000d + --> ∡90.5°

Or even better, commands to force an angle into a particular mode:

→∡r would take any number and tag it as an angle in radians. Also convert to radians if the argument is already an angle.

→∡d same for DMS.

→∡°

→∡g

-1 ASIN would return ∡-90° if the current mode is DEG.

-1 ASIN →∡r would guarantee a result in radians regardless of current mode.

→∡d SIN would force SIN to interpret its input as DMS, regardless of the current flags. If the user gives a number, the given number will be "tagged" as an angle in DMS.

For a CAS system, SIN should be forced into radians regardless of system flags, so instead of asking the user "switch to radians mode?", perhaps SIN should ALWAYS interpret numbers as radians, and the user needs to use the proper →∡° command if the input is not in radians. This would break compatibility with old code using degrees, but would make SIN consistent with the CAS behavior.

Unit objects would also have angle units, I gues they would have to coexist (??)

Any thoughts?