NICE-ESG-Libs Digest Tue, 14 Feb 95 Volume 1 : Issue 182
Today's Topics:
Comment on NUMERIC from the net
The PELKS (including a proposal for a Board motion)
NICE Eiffel Standards Group -- Library Committee Mailing List
To post to list:
NICE-ESG-Libs@atlanta.twr.com
To send mail to the Chairman of the committee:
NICE-ESG-Libs-chair@atlanta.twr.com
Administrative matters (sign up, unsubscribe, mail problems, etc):
NICE-ESG-Libs-request@atlanta.twr.com
Date: Tue, 14 Feb 95 16:14:15 EST
From: tynor (Steve Tynor)
Subject: Comment on NUMERIC from the net
To: nice-esg-libs
Library Committee members,
The recent discussion of PELKS on comp.lang.eiffel prompted Chris
Flatters to look at the proposal. He sent me the following concerns
regarding IEEE floating-point representations and how they relate to the
kernel standard. I pass them along for the committee's review.
Steve
------- start of forwarded message (RFC 934 encapsulation) -------
|From: Chris Flatters
|To: tynor@atlanta.twr.com
|Subject: re: PELKS
|Date: Mon, 13 Feb 1995 09:37:11 -0700
> | Is there any way of getting feedback to the PELKS committee?
>
> Sure: send it a committee member (like me...) or to the chair:
> nice-esg-libs-chair@atlanta.twr.com.
I have a few concerns relating to the interfaces for REAL and DOUBLE and
their impact on support for IEEE 754 floating-point arithmetic, so here
goes...
The IEEE Standard for Binary Floating-Point Arithmetic (ANSI/IEEE
Std. 754) specifies the floating-point environment seen by the
programmer or user of a system. It provided for the implementation of
numerically sophisticated programs that are both robust and efficient.
It would be unfortunate if the PELKS were to present a obstacle to the
future development of Eiffel programming environments that allow the
programmer to exploit IEEE 754 facilities.
The basic arithmetic operations specified by IEEE 754 (addition,
subtraction, multiplication, division, square root and comparison) are
normally defined over the entire domain of IEEE floating point values.
Exceptional arithmetic operations (such as dividing zero by zero) do
not normally interrupt program execution but result in the setting of
a status flag that may be tested later. This allows a programmer to
use a fast but unsafe algorithm to perform a calculation and to check
the status flags later and to use a slower backup method if an
exception occurred. As exceptional cases are normally much rarer than
unexceptional cases, this will usually be more efficient than using
the safe algorithm in all cases. The standard also defines optional
facilities for handling floating-point exceptions as they occur (trap
handlers) but implementations of these facilities are often incomplete.
In order that program execution can continue uninterrupted after an
exception, the set of IEEE floating-point values includes signed
infinities (that mark arithmetic overflows) and two or more NaNs (that
mark indeterminate values).
As they stand in Version 7 of the PELKS, the flatshort forms of DOUBLE
and REAL are too restrictive to allow the use of facilities provided
by IEEE 754.
i) The precondition for infix "/" (from NUMERIC) is too strict since
division by zero is defined in IEEE 754. This is not a serious
problem since flatshort conformance allows preconditions to be
weakened in an implementation class (PELKS Section 2.4.1.4) but it
becomes questionable whther the predicate divisible (from NUMERIC)
is meaningful.
ii) No total ordering exists over IEEE 754 floating-point values
unless NaNs are excluded. Any comparison involving a NaN should
be false (even an equality test for two identical NaNs). This
is not a problem in Version 7 of the PELKS since COMPARABLE only
requires a partial ordering although its description claims
total ordering.
iii) The class invariants inherited from NUMERIC are not true for all
IEEE floating-point values: neutral_addition, self_subtraction,
neutral_multiplication, self_division and sign_times_abs are
false if Current is a NaN; Self_subtraction and possibly
self_division (depending on the implementation of divisible) are
also false if Current is an infinity.
iv) Some feature postconditions are also not true for all IEEE
floating-point values: both postconditions of abs are false
if Current is a NaN; commutative from infix "+" is false if
either Current or other is a NaN.
Rather than requiring programmers to disable postcondition and class
invariant checking for REAL and DOUBLE to gain access to the full IEEE
754 floating-point behaviour or requiring implementors to add less
restrictive ancestors of REAL and DOUBLE to the class hierarchy to
provide access to this behaviour (particularly awkward since the
ancestors would have to be higher than NUMERIC --- and possibly
COMPARABLE --- in the inheritance hierarchy), I would recommend that
the class invariants and postconditions from NUMERIC be moved to
INTEGER and that validity-checks for floating-point operations be left
to the underlying hardware and operating system environment.
Implementors are, of course, free to add stronger assertions where
appropriate (PELKS Section 2.4.1.5). The cost of weakening the
postconditions and invariants in NUMERIC would be that fewer problems
that might occur when porting to machines with more restrictive
floating-point models would be caught while developing programs on
machines with less-restrictive floating-point models.
------- end -------
Date: Wed, 15 Feb 95 00:07:10 +0100
From: bertrand@eiffel.fr (Bertrand Meyer @ SOL)
Subject: The PELKS (including a proposal for a Board motion)
To: NICE-Board@atlanta.twr.com
Dear colleagues:
In response to Simon Parker let me explain why it is
essential - I mean more than essential: almost a
matter of life and death - to approve the PELKS and publish it
now.
1. The PELKS as approved carries a notion of vintage.
What we have should be considered as the 1995 vintage.
If anything needs to be changed there is room for adjustment
in the subsequent vintages.
2. To satisfy users, we need a common base. Commonality is
more important than perfection - especially since the PELKS
is actually quite good. With an approved PELKS vendors can
provide standard-conforming implementations. (As an aside
the idea to publish the PELKS now and adopt it as vintage
1995 initially came from a major industrial user, in a recent
conversation.)
3. The crucial point: let's not lose the momentum. In the
object-oriented world, and in the software world in general,
hype wins over substance most of the time. Many of the fashionable
products and efforts are 90% PR and 10% reality. In the Eiffel
world, we have been good at substance and bad at PR. PLEASE,
let us have a little PR just for once. Let's have 90% good
substance (the current PELKS) and 90% good PR.
A recent editorial in Computer World (consecutive to a letter
I wrote to the editor) went something like this:
Everyone tells me Eiffel is excellent.
C++ is terrible.
Smalltalk is not as good as Eiffel.
Yet Eiffel has no standard.
So I cannot recommend Eiffel.
I recommend C++ or Smalltalk.
True, C++ has no standard either.
True, Smalltalk has no standard either.
But someone is working on it.
So you should go for C++ or Smalltalk.
This is the way the people who are supposed to guide our
industry (in this case Charles Babcock, editor-in-chief or
something like that for ComputerWorld) reason! All sizzle,
no steak. All appearance, no substance.
To convince that kind of idiots, whom the industry considers
geniuses, we need to work on the appearance too. In the Eiffel
world, we agree on 90% of everything in the language and
Kernel Library areas. Why use the other 10% as an excuse
to look WORSE than people who disagree on 50% of their stuff
(or 70% in the case of Smalltalk) while still succeeding
in convincing the public that they are OPEN and STANDARD?
Please, let us not be suicidal. Let us use our strengths.
Let us emphasize our agreements, not our disagreements.
This is a crucial time for Eiffel. We need all the PR
we can get. The PELKS, vintage 95, is the ideal opportunity.
No one will be interested in a perfect standard 5 years
from now. Everyone will love a good standard in 1995.
I hereby submit the following motion and request Simon
(or is it Christine? Does the chairman or the secretary
take care of pushing motions?) to put it to a vote.
Resolved:
1. That NICE adopts the PELKS version 6 as the vintage
1995 kernel library standard.
2. That NICE officially requests all vendors of
Eiffel compilers to bring up their implementations, within the
next 9 months, to a state of full conformance with the vintage
1995 kernel library standard, and clearly document, in reports
made available to their customers as well as to the NICE
board, any deviations from the standard.
3. That the library committee appoint one or more persons,
preferably from among its members, to contact a major publisher
to publish the PELKS with a view to: (3.1) make it as widely available
as possible; (3.2) bring the proceeds of the sales to NICE.
4. That NICE shall advertize the adoption of a Kernel Library Standard
as a way to promote Eiffel as an open, standardized, interoperable
solution.
5. That the NICE library committee shall establish a timetable
for the preparation of the vintage 1996 Kernel Library Standard,
and shall diligently handle proposals meant for that vintage.
This is not the time to engage in minute debates on low-level
details. This is the time to publicize our agreements and draw
the benefits of our extensive work.
Please move ahead quickly with this proposal.
Thanks and best regards,
-- Bertrand Meyer
|
