Comments on the Proposed LIA Standard

[Dan Zuras]

To :	Mark Hamilton, Chair, X3T2			Sep. 25, 1992
	Netwise, Inc.
	2477 55th St.
	Boulder, CO, 80301

Cc:	Ken Edwards
	IBM Corporation - D48/D333
	555 Bailey Ave. - POB 49023
	San Jose, CA, 95161

	Prof. W. Kahan
	Computer Science Division
	Department of Electrical Engineering
		and Computer Science
	University of California
	Berkeley, CA, 94720

	Stacy Alexander		stacyacup.hp.com
	Ed Barkmeyer		edbarkacme.nist.gov
	Carl Burch		cdbacup.hp.com
	Jeff Dawson		dawsonardvax.enet.dec.com
	Ken Edwards		EDWARDSKaSTLVM7.vnet.ibm.com
	Mark Hamilton		mahanetwise.com
	Jerry Huck		huckacup.hp.com
	Willy McAllister	mcallisterahpl.hp.com
	Murray			x3j3mfacc.bellcore.com
	Mary Payne		mpayneacrl.dec.com
	Liz Peters-Tanaka	lizacup.hp.com
	Fred Ris		risabldvma.vnet.ibm.com
	Schaffert		schaffertacrl.dec.com
	Brian Wickman		baw%seg.npl.co.ukansfnet-relay.ac.uk
	Dan Zuras		zurasacup.hp.com
				numeric-intavalidgh.com
				ncegacray.com

From:	Dan Zuras			Re: Language Independent Arithmetic
	Hewlett-Packard, 47LA
	19447 Prunridge Ave.
	Cupertino, CA, 95014


Mr. Chairman :

	   I have been asked to post my comments on the X3T2 Committee's
	Draft International Standard ISO/IEC CD 10967-1:1992 entitled
	Information Technology - Language Independent Arithmetic (LIA) -
	Part 1:  Integer and Floating-Point Arithmetic and formerly
	known as LCAS.  The version was the Second Committee Draft
	(Version 4.0) dated August 31, 1992.

	   I have divided them up into two sections.

	   The first section has my general comments and observations.

	   The second section is the detailed list of comments quoting
	chapter and verse from the LIA document.

	   I thank you in advance for your attention,


		Sincerely,




				Dan Zuras

   General comments and observations on the proposed Language Independent
Arithmetic Standard (LIA) formerly known as LCAS.  The version was the
Second Committee Draft (Version 4.0) dated August 31, 1992.


   <>	I think the most important observation I can make is to
	note that LIA chooses to define the word "portability"
	differently than most people.  Thus, they take directions to
	achieve it that most people would regard as contra-indicated.

	Portability as most define it is the ability to take a
	program that works on one vendor's compiler/OS/hardware/etc.
	and compile, link, & run it successfully in another vendor's
	environment with little or no changes to the source.

	Portability as LIA defines it appears to be something like :
	if each vendor I wish to port my program to documents their
	arithmetic and language bindings in a reasonably standard way,
	I can write a program FOR THAT VENDOR that will do the job I
	have in mind.

	Under LIA, the more usual definition of portability means that
	a programmer may only use those features that are required to
	be identical from vendor to vendor.

   <>	Language bindings are suggested but not required.  Thus, an
	implementation may comply by providing a subroutine addF(x,y)
	which returns the LIA defined sum of two numbers while the
	expression x+y performs the vendor's add operation.  A vendor
	might be motivated to do something like this if their native
	operations differed from the LIA in some way.

	(Since I wrote up these comments I have been told that the
	issue of language bindings is beyond the scope of X3T2.  I
	leave these and other comments in because I believe it is an
	area where a real contribution can be made.  Recent work by
	the Fortran-90 & NCEG groups show some promise for Fortran & C.
	It would be useful for X3T2 to make some contribution beyond
	mere repetition of their work.  It is important not to be in
	conflict.)

   <>	While LIA states that "A method shall be provided ..." to
	obtain various parameters that partially describe a vendor's
	floating-point, the method is left up to the vendor.  Thus,
	while it may be possible to obtain those parameters, each
	vendor is free to choose their own method of providing them.

   <>	It is the stated purpose of LIA that almost all existing
	floating-points should comply (the most major exception being
	Cray's).  Yet, I read LIA as containing clauses that exclude
	IEEE-754, IEEE-854, DEC floating-point, & IBM floating-point
	(both the 360-style hex format and the RS-6000).  Further, it
	is possible to define INTEGERS in such a way as to make them
	comply as a normalized FLOATING-POINT data type under LIA.

   <>	LIA is incorrect in stating that systems that meet their
	standard have a relative error less than 1 ULP (rnd_error<=1).
	It is an intrinsic property of systems without denormalized
	numbers that rnd_error >= r^p - 1.

   <>   The LIA wishes to distance themselves from the Brown model for
	some reason.  But the model they present is much more like Brown
	in its character than it is like IEEE-754.  This would not be bad
	in and of itself if the model used were both applicable to real
	systems and permitted non-trivial inferences to be derived.

   Detailed comments and questions on the proposed Language Independent
Arithmetic Standard (LIA) formerly known as LCAS.  The version was the
Second Committee Draft (Version 4.0) dated August 31, 1992.


	Section 3.2, page 4 :  The definition of denormalized is
		incorrect.  What is really defined here is unnormalized.

	Section 4.1, page 6 :  "A method shall be provided ..."  to
		obtain various parameters.  This is not stringent enough
		for portability.

	Section 4.2, page 9 :  If you set r = 2^N, p = 1, emin = emax =
		1, then Fn = { 0, +/- i | 1 <= i <= 2^N - 1 }, a subset
		of the integers, qualifies as a floating-point type!
		(with denorm = false or with Fd = {} and denorm = true)

	Section 4.2.1, page 10 :  The operation absF is deleted but used
		elsewhere.

	Section 4.2.3, pages 11-12 :  The derived constant rnd_error is
		not restricted to be <= 1.  For any floating-point
		system that does not have denormalized numbers, it can
		be shown that rnd_err >= r^p - 1.

		Proof :
			rnd_error is the smallest element of F such that

			|x-rndF(x)| <= rnd_error*r^(eF(rndF(x))-p)

			for all x in R.  Choose x = fmin - eps where

			0.5*r^(emin-p) < eps <= r^(emin-p)

			On floating-point systems that don't have
			denormalized numbers and flush to zero on
			underflow, values <= x will flush to zero.
			Therefore,

			|(fmin-eps)-rndF(fmin-eps)| <=
					rnd_error*r^(eF(rndF(fmin-eps))-p)

			|(fmin-eps)-0| <= rnd_error*r^(ef(0)-p)

			|r^emin-eps| <= rnd_error*r^(emin-p)

			|r^emin-r^(emin-p)| <= rnd_error*r^(emin-p)

			(r^p-1)*r(emin-p) <= rnd_error*r^(emin-p)

			r^p-1 <= rnd_error

		This is not a problem with the definition of rnd_error.
		It is an intrinsic property of flush to zero in
		floating-point systems without denormalized numbers.

	Section 4.2.4, page 13 :  No system without denormalized numbers
		can choose rnd(x) for x<fminN-.5*ULP without incurring a
		denormalization error (as defined on page 11).  Therefore,
		all such systems must return underflow to comply.
		Therefore, all systems that return zero don't comply.
		Therefore, DEC & IBM (the 360 hex format) don't comply.

		(I realize that both DEC and IBM can trap on underflow.
		Therefore, the best I can say is that they don't comply
		with their default settings.  Since this is the setting
		that the bulk of the existing portable software has been
		written for, it is an important case.)

	Section 4.2.5, page 13 :  The rather contrived function add*F
		appears to be there to allow machines without a guard
		digit in their add to comply.

	Section 4.2.6, page 14 :  Both 754 & 854 return infinity for
		1.0/0.0.  Therefore, both don't comply.  In general,
		these arithmetics create values outside those permitted
		by LIA (NaNs and infinities) even for operations on
		values permitted by LIA (0.0/0.0 and 1.0/0.0).  Given
		that this is the case, I don't see how 754 & 854 can
		ever comply.

		(The continuation values on page 18 might be a way out
		of this problem.  It might be possible to set the IEEE
		traps for overflow, underflow & divide-by-zero and write
		trap handlers that return values that conform to LIA.
		Therefore, the best I can say is that they don't conform
		in their default settings.  But, just as in the case for
		DEC & IBM, this eliminates the case for which the bulk
		of portable code has been written.)

		Why doesn't exponentF(x) return emin when x=0?

		In 754, succ(x) = nextafter(x,+inf) and pred(x) =
		nextafter(x,-inf).  Therefore, succ(-0) = +0 and
		pred(+0) = -0.  Not really a violation but it means
		that succ & pred are a little tricky around zero.

		The function rnF(x,n) rounds up on even.  Rather like a
		generalization of the Pascal definition of Round(x) to
		be Floor(x+0.5).  Not really a violation with IEEE since
		it is a new operation but, if implemented in hardware,
		would require yet another method of rounding in already
		complex circuitry.

	Section 4.3, page 16 : I don't understand the purpose for the
		last paragraph.

	All of section 5 :  One of the most interesting methods of
		notification of exception that I have ever seen was an
		implementation of IEEE-754 in Forth.  Since Forth is a
		language with no notion of either global variables or
		implied order of execution, it was not possible to use
		global flags and traps.  Therefore, the implementors
		decided to append 10 bits (5 flags & 5 traps) to each
		floating-point number.  After an operation, I believe
		the resulting traps were the inclusive or of the
		operands' traps and the resulting flags were the
		inclusive or of the operands' flags together with any
		exception that happened on this operation.  The final
		result was a method of notification in which the trap &
		flag state associated with a given value was just that
		state that was involved in the creation of that value
		and no other.

		This very clean method of notification seems to be
		outside those considered by LIA.  It would be a shame
		if functional languages such as Forth, Lisp & APL were
		denied this method because of LIA.

	Section 6, page 19 :  "This standard does not define the syntax
		of arithmetic expressions."  Therefore, a compliant
		function (such as addF) need not be bound to the obvious
		language syntax (such as +).

	Section A.1.2, page 24 :  If Kulish-Miranker arithmetic is
		specifically excluded from LIA then so is the arithmetic
		on the RS-6000.

		The text does not specifically state why K-M is excluded
		so I will speculate.

		It is possible that LIA does not wish to deal with the
		notion of super-accumulators.

		I think it more likely that something like the following
		is true.  Consider the expression

			R <-- A*B + C*D

		LIA must define this as

			R <-- resultF(resultF(A*B,rndF)+resultF(C*D,rndF),rndF)

		K-M would define this as (to use LIA's notation)

			R <-- resultF(A*B+C*D,rndF)

		and the RS-6000 would define this as either

			R <-- resultF(A*B+resultF(C*D+0,rndF),rndF)

		or

			R <-- resultF(resultF(A*B+0,rndF)+C*D,rndF)

		according to how the compiler evaluates the expression.

		I can see no definition of the pseudo-functions resultF
		and rndF that would permit these arithmetics to comply.

	Section A.1.3, page 25 :  String<->floating-point conversions
		are outside the scope of LIA.  This is an important
		aspect to the portability of any program.

	Section A.2.3, page 26 :  "The LIA-1 does not define any process
		for validating conformity."  Can anyone claim compliance?

	Section A.4, page 28 :  "Each arithmetic type is a subset of the
		real numbers characterized by a small number of
		parameters."  a la Brown.

	Section A.4.1.0.2, pages 29-30 :  "...  100 decimal digit
		integers ..."  qualifies as unbound integers.  This is
		hardly unbound.  So long as the integer data type is
		bound by some arbitrary limit not associated with runtime
		or architectural resources, I would say it is bound.

	Section A.4.1.1, page 30 :  Since the C integer multiply is
		usually modulo the word size, it does not conform to
		LIA.

	Section A.4.2, page 31 :  Five parameters (radix, precision,
		emin, emax, denorm) a la Brown.

	Section A.4.2.0.1, page 32 :  While it is true that addition and
		subtraction that results in denormalized numbers is
		always exact in IEEE-754 & IEEE-854, it is not true in
		an LIA floating-point that includes denormalized
		numbers.  The add*F function permits a loss of accuracy
		due to the lack of a guard digit.

	Section A.4.2.0.2, page 33 :  The statement that r^(p-1) >= 10^6
		assures at least 7 decimal digits of precision is false.

		(Counter example :  r=2, p=21, 2^20>=10^6 but the
		resulting floating-point type has only a little better
		than 6 decimal digits of precision.)

		The correct statement should be r^p >= 10^7.

	Section A.4.2.0.3, page 34 :  Eliminating two's-complement
		floating-point eliminates the HP 1000 & 3000 floating-
		point systems.  Even though I work for HP, this doesn't
		bother me a great deal.  But it does seem to be a
		restriction without much gain.

	Section A.4.2.0.4, page 35 :  Since infinities and NaNs can be
		generated from ordinary operands (1.0/0.0, 0.0/0.0),
		IEEE-754 & 854 cannot comply in these cases.

	Section A.4.2.2, page 36 :  <Paragraph (c)> Is this just silly
		wording or are they trying to include a case that eludes
		me?  It can't be for systems with just one zero since
		they have been eliminated.

	Section A.4.2.2, page 37 :  <Paragraph (n)> Not true for 754 &
		854.  The boolean operation x<y, for example, may trap.

	Section A.4.2.5, page 39 :  Here is the explanation of that
		rather contrived function add*F.  It is here to allow
		IBM to comply.

	Section A.4.2.8, page 41 :  The hierarchy presented is meant to
		show that LIA is closer to 754 than Brown in its level
		of predictability.  But the very form of LIA is
		Brown-like.  So long as the model is useful, I don't
		understand why they appear to be distancing themselves
		from Brown.  Is the LIA model useful?  That is, does it
		apply to real systems and can one make reasonable
		inferences from it?  I see no evidence that this is so.

	Section A.4.2.9, page 43 :  Statement (VI) is only interesting
		for multiply and divide.  It is seldom true for add and
		subtract.

	All of Annex B :  LIA "suggests" but does not "require" language
		bindings.  Thus, a vendor may conform by merely
		documenting the their implementation of LIA functions
		whether they are bound to the language objects or not.

		(Since I wrote up these comments I have been told that
		the issue of language bindings is beyond the scope of
		X3T2.  I leave these and other comments in because I
		believe it is an area where a real contribution can be
		made.  Recent work by the Fortran-90 & NCEG groups show
		some promise for Fortran & C.  It would be useful for
		X3T2 to make some contribution beyond mere repetition of
		their work.  It is important not to be in conflict.)