OpenEuphoria

Re: New proposal for math.e

• Posted by Juergen Luethje <j.lue at gmx.??> Aug 05, 2007
• 564 views

CChris wrote:

<snip>

> You may take a look at the corresponding routines I wrote in complex.e - you
> can find it at oedoc.free.fr/Fichiers/ESL/complex.zip . Obviously, it would
> need some rewriting if you wanted to use it, because it takes its argument
> from
> the sequence representing a complex number.

In "complex.zip" I couldn't see what range is used for the angles.

> As far as I know:
> * When counting in radians, angles go from -PI excluded to +PI included,
> counterclockwise.

This is the same as what is used in the Russian textbook by
Bronstein, Semendjajew, Musiol, Mühlig. And the same as Colin
proposed.

> The point at rectangular coordinates (1,0) defines the 0 angle.
> * When counting in degrees, the usage is to count from 0 to 360° rather, with
> the point at (0,1) defining the 0 (North) angle, counting clockwise.
> * Some schoolbooks use a mixed thing where angles start from (1,0) and go from
> 0 to 360° counterclockwise, probably to ease transition from degrees to
> radians.
> I hope they have stopped this confusing course; they were doing that some
> 30-40
> years ago. At the very least, it's a high school only thing.
> 
> So perhaps you'll wish to include a parameter in the rect_to_polar() and
> polar_to_rect()
> which says which of the two angle representations is being used, either as
> input
> or output. Or use two separate sets of functions, but this looks clumsier to
> me. Yet it's an option, and would be faster (one test less, and one passed
> parameter
> less).

I think rect_to_polar() and polar_to_rect() just should use radians.
For conversion we already have radians_to_degrees() and degrees_to_radians().
So it's not necessary to build a conversion option into every routine that
deals with angels, or to write two versions of those routines.

> In the framework of the ESL, errors were reported by the library to stderr and
> caused an abort(); that's what you'll find in the code. Here, we may return
> an invalid value for the angle, namely {}.

I also thought of that. It is rather strict, but probably the
clearest way to express "Here is not a (valid) number."

> It's the sort of non portable NIL
> we have been using from day one, and we won't have it before long, if it ever
> happens - which isn't guaranteed in any way.
> 
> CChris

Regards,
   Juergen