🚀 go-pugleaf

In article <2426@l.cc.purdue.edu>, cik@l.cc.purdue.edu (Herman Rubin) writes:
> Portable constructs are one thing, but portable code is another.  Packing
> and unpacking floating-point numbers are portable constructs, but I know
> of no HLL which has them.

1. ANSI C.
2. Common Lisp.
3. The Ada Numerics Group have a very nice proposal for operations
   on floating point numbers (including, would you believe, math functions
   with guaranteed error bounds) which should be in Ada 9x.
4. Fortran 90.  In detail, if x = s * b**e * f, s = +1 or -1, 0 <= f < 1
	EXPONENT(x)	=> e   (exponent(0.0) .eq. 0)
	FRACTION(x)	=> f   .eq. x * b**(-EXPONENT(x))
	RADIX(x)	=> b
	SIGN(1.0, x)	=> s   (sign(1.0, 0.0) .eq. 1.0)
	DIGITS(x)	=> number of base-b digits in f
	NEAREST(x, s)	=> if s > 0, the machine number _just_ .gt. x
			   if s < 0, the machine number _just_ .lt. x
	RRSPACING(x)	=> ABS(SCALE(x,-EXPONENT(x)))* RADIX(x)**DIGITS(x)
	SPACING(x)	=> RADIX(x)**(EXPONENT(x)-DIGITS(x))
	SCALE(x, i)	=> x * RADIX(x)**i
	SETEXPONENT(x,i)=> x * RADIX(x)**(i-EXPONENT(x))

There's a proposal for a standard for the floating-point part of
programming language standards.  It was published in an issue of
SIGPlan Notices this year.  Anyone interested in this matter should
see that and send in comments.

A language standard says what the operations _look_ like.  ANSI C,
Fortran 90, and the proposal for Ada 9x, are all for languages with
static typing, so a compiler can figure out at compile time exactly
which hardware floating-point type is in use, and may generate the
appropriate instructions.  On a VAX,
	X = SETEXPONENT(X, 2)
might well be compiled into a single INSV instruction.  Why not?
Mathematically, these things _are_ functions, and they might as well
_look_ like functions.

> Why can we not have additional operator SYMBOLS added to a HLL?

In Algol 68, they _can_.  When Algol 68 needed friends, where were you?
Haskell lets you declare new (overloaded) operators.

> I have not run into anything which can not be written in a semi-portable
> manner.  But in choosing which of the extremely large number of algorithms
> I can understand, I do take into account the machine.

I think that the answer here may be to think in terms of meta-programs.
I've often run into an irritating problem.  There is some special function
I would like to compute, and I'm not enough of a numerical analyst to work
out how to do it well myself, so I look around in journals and such for an
implementation I can copy.  _Far_ too often I'm presented with something
with around a dozen coefficients which are (a) presented to fewer decimal
places than I can get in IEEE 754 arithmetic, (b) designed for single
precision arithmetic on some antique machine in the first place, and
(c) -- this is the killer -- unaccompanied by any explanation of how to
compute suitable coefficients for some other machine.  What I would really
like to see is meta-programs:  tell them something about the machine
arithmetic and they generate the appropriate table of coefficients for you.
(No, tables for a dozen different existing machines are not enough.  I've
yet to see the 80-bit numbers you get on a Mac in such tables.)

-- 
Distinguishing between a work written in Hebrew and one written in Aramaic
when we have only a Latin version made from a Greek translation is not easy.
(D.J.Harrington, discussing pseudo-Philo)