Re: Some modules from Modula-2

[Mike Griebling <grieblm@trt.allied.com>]

> Mike wrote:
> >  I'll volunteer to implement the following ISO modules:
> >  
> >  	LowReal, LowLong  (already partially covered by Math, MathL)
> >  	RealStr, LongStr  
> >  	RealConv, LongConv
> >  	RealMath, LongMath (are these modules really necessary given Math(L)?)
> >  	ComplexMath, LongComplexMath
> >  
> >  I suggest that the RealMath & LongMath simply be stubs which call the
> >  appropriate Math or MathL routines.
> >  
> I'd rather have it the other way round: change the name of Math to
> RealMath and MathL to LongMath.  I prefer the M2 names because they
> use a quite orthogonal naming scheme for *Str, *Conv, *Math, and Low*.
> The module names Math/MathL can then be dropped altogether
> resp. turned into OakMath and OakMathL which would be stubs that call
> the *Math modules.

I have no objection to your naming convention.  It will be implemented so.
It will have additional functions which are not part of the ISO standard
however (sinh, cosh, tanh, inverses, and a few others).

> I don't see how you can conveniently implement the Complex modules
> without a builtin COMPLEX type.  Take for example the function 
>   PROCEDURE conj (z: COMPLEX): COMPLEX; 
> This can only be declared when COMPLEX is a pointer type, which isn't
> very nice.  And complex constants like "i = CMPLX (0.0, 1.0)" aren't
> possible at all.

What's wrong with a pointer-based implementation?  The complex "constants"
such as i can also be declared as read-only pointers and initialized
during module start-up.  The only tricky part will be that assignments
will copy the pointer and not the contents of the complex number.  It
is possible to add an Assign routine which implements the assignment
correctly.  Of course, we'll also need Add, Subtract, Multiply, Divide
functions.
 
> Some remarks on the RealConv/RealStr modules:  It is absolutely
> paramount that the conversion from real to string and vice versa is
> precise to the last bit.  This probably prevents using any floating
> point functions (+, /, exp, etc) to construct a string or calculate a
> number from a string.  To illustrate this requirement I'll give an
> example from the very early days of o2c: 
>   The first RealStr module of o2c relied on the real operators and
> various math functions to build/break down strings.  The algorithms
> where pure Oberon, and naturally they contained a number of real
> constants.  o2c was used to compile the module, and o2c used the
> module to read in the real constants in the module sources.  
>   But the real number conversion wasn't precise.  Whenever the
> compiler read a real const from RealStr, it translated it to its
> value+-something.  This v+-s value went into the module's next object
> file.  This in turn was used to build a new compiler whose conversion
> functions lost even more precision.  The new compiler converted reals
> into something like value+-(2*something) and the whole cycle started
> anew.  
>   At the end each compilation of RealStr.Mod build conversion
> functions that where a factor of 10 of the mark, and the gap was
> widening... 
>   Therefore my urge to implement RealStr/Conv with the greatest
> possible care and without the use of any real arithmetic (at least in
> the critical parts).

I would be interested in seeing the original modules you defined to
implement RealStr/Conv.  It is possible to precisely represent
REAL/LONGREAL numbers since this was also required for the Math(L)
modules.  I mapped the required bit patterns into an integer and
then interpreted these integers as REALs or LONGREALs.  Some numbers
such as 0.5, 0.25, 0.75, 1.0, etc. are exactly representable so they
shouldn't cause any conversion problems.  Of course, numbers like 0.1
are not exactly representable because they end up being numbers like
3DCCCCCD (REAL) or 3FB999999999999A (LONGREAL).  Note the rounding up
of the last hexadecimal digit since these numbers repeat the `C' or `9'
patterns forever.
 
> -- mva

Michael