The disturbing myth of Eiffel portability

The disturbing myth of Eiffel portability

[The Rt Rev'd Colin James III, KOTM 1/96]

It is common knowledge that the same ANSI C source code when compiled by
different ANSI C compilers produces executables which when run yield
different, inconsistent floating point results.  

This is due to the fact that the runtime floating point packages of ANSI C
compilers vary as to word size and are not required to conform to strict
standards, other than weasel words, as are Ada compilers.

Eiffel emits ANSI C code.

Therefore Eiffel is in fact not truly portable and can in fact yield
different numerical results according to platform.

That begs the following question:  how can the largest Eiffel project of
over 700,000 lines of code (the CALfp bank's derivatives' program) expect
to be taken seriously if the source code when compiled on different
platforms could produce inconsistent and erroneous results.  

In other words, the reason that banks generally have learned to avoid C due
to floating point problems is not solved at all but rather propagated and
worsened by the questionable strategic decision to adopt Eiffel.  That fact
may of course explain why no other famous banks with both US _and_ European
computer operations have jumped on the Eiffel bandwagon and predictably
would not, such as the perfect example of CitiCorp which had the first GE
bank computers about 1962.

Don Knuth tried to get around the floating point problem in the 1960's by
suggesting in Volumes 1 and 2 of his opus to use scaled integers.  It's too
bad that the immature project weenies choose not to read that classic
anymore these days and thus don't know the meaning of integer math.

~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Re-usable, patented financial software for business and banks 
Colin James III, Principal Scientist     www.cec-services.com
CEC Services, LLC, 1613 Morning Dr, Loveland, CO   80538-4410
Telephone lines:  Voice 970.622.0466; Facsimile: 970.622.0177
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~

Re: The disturbing myth of Eiffel portability

[Eoin Woods]

In article <3294e64b.74799475@news2.ibm.net>
           cjames3@ibm.net "The Rt Rev'd Colin James III, KOTM 1/96" writes:

> In other words, the reason that banks generally have learned to avoid C due
> to floating point problems is not solved at all but rather propagated and
> worsened by the questionable strategic decision to adopt Eiffel.
This is abolute rubbish!  (As usual from CJIII).  I work (as a consultant) at
banks a LOT - they ALL use C as a mainstream development language (whether
or not they *should* is a different question!)

Eoin.
-- 
Eoin Woods, Watford, Hertfordshire, WD1 1PD, UK
Email:      Eoin@copse.demon.co.uk

Re: The disturbing myth of Eiffel portability

[Lawrence Kirby]

In article <3294e64b.74799475@news2.ibm.net>
           cjames3@ibm.net "The Rt Rev'd Colin James III, KOTM 1/96" writes:

>It is common knowledge that the same ANSI C source code when compiled by
>different ANSI C compilers produces executables which when run yield
>different, inconsistent floating point results.  

They should not be inconsistent for correctly written code. What can differ
is the accuracy of the results. That results aren't exact in general is a
fact of life with floating point.

>This is due to the fact that the runtime floating point packages of ANSI C
>compilers vary as to word size and are not required to conform to strict
>standards, other than weasel words, as are Ada compilers.

ANSI C does define minimum precision and other requirement for floating
point types. The only question is whether they are adequate for your needs.
ANSI C compilers on many platforms conform to the relevant IEEE floating
point formats so if this is a big issue for you simply specify that your
code is only certified for, say, an ANSI + IEEE 754 compliant platform.

>Eiffel emits ANSI C code.
>
>Therefore Eiffel is in fact not truly portable and can in fact yield
>different numerical results according to platform.

It depends what the actual specs for floating point in Eiffel are. If they
are stricter than those in ANSI C then not all implementations of Eiffel
may be compliant with its specs. You don't certify code for such
platforms.

>That begs the following question:  how can the largest Eiffel project of
>over 700,000 lines of code (the CALfp bank's derivatives' program) expect
>to be taken seriously if the source code when compiled on different
>platforms could produce inconsistent and erroneous results.  

You have yet to establish that it does.

>In other words, the reason that banks generally have learned to avoid C due
>to floating point problems is not solved at all but rather propagated and
>worsened by the questionable strategic decision to adopt Eiffel.  That fact
>may of course explain why no other famous banks with both US _and_ European
>computer operations have jumped on the Eiffel bandwagon and predictably
>would not, such as the perfect example of CitiCorp which had the first GE
>bank computers about 1962.

Can you think of a platform that a bank is likely to adopt these days
for hosting Eiffel that doesn't support suitable floating point formats?

>Don Knuth tried to get around the floating point problem in the 1960's by
>suggesting in Volumes 1 and 2 of his opus to use scaled integers.  It's too
>bad that the immature project weenies choose not to read that classic
>anymore these days and thus don't know the meaning of integer math.

5-10 years ago I might have agreed with you. However IEEE formats have
been generally adopted and do guarantee exact results for calculations
on integers that can be represented exactly.

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

Re: The disturbing myth of Eiffel portability

[The Rt Rev'd Colin James III, KOTM 1/96]

Eoin Woods is deluded in the article quoted below.  

Almost all banks still do most of their processing in COBOL.

All new development in US banks with European branches is in C++ back end
and many front ends (none in Eiffel that I know of).  This is partly due to
C with its silly pointers not scaling well and mostly due to floating point
problems at run time in C.

Case in point:  one of the 10-largest US banks with European branches just
killed a 5 year old derivatives project in C, fired everyone involved, and
wrote off $25 MM.  (Case in point: that's yet another example of C hackers,
such as Eoin, banging on Un*x boxes.)  The same vice-president at that bank
also told me that they are not interested at all in CALfp's "laughable"
Rainbow derivative's project in Eiffel "because it's still in C" and "those
bozos in France still haven't learned about C yet".

While none of the banks above are The Nancy Bank of Watford, Hertfordshire,
UK, please tell the readers here, Eoin [sic], did you "consult" there too?

----------------

From: Eoin@copse.demon.co.uk (Eoin Woods)
Newsgroups:
comp.lang.eiffel,comp.lang.ada,comp.lang.c,comp.lang.c++,comp.lang.object
Subject: Re: The disturbing myth of Eiffel portability
Date: Sun, 17 Nov 96 16:42:18 GMT
Organization: At Home
Lines: 15
Message-ID: <848248938snz@copse.demon.co.uk>
References: <3294e64b.74799475@news2.ibm.net>
Reply-To: Eoin@copse.demon.co.uk
X-Mail2News-User: Eoin@copse.demon.co.uk
X-Mail2News-Path: copse.demon.co.uk
X-Newsreader: Demon Internet Simple News v1.29
Xref: news.fortnet.org comp.lang.eiffel:303 comp.lang.ada:1172
comp.lang.c:4668 comp.lang.c++:5720

In article <3294e64b.74799475@news2.ibm.net>
           cjames3@ibm.net "The Rt Rev'd Colin James III, KOTM 1/96" writes:

> In other words, the reason that banks generally have learned to avoid C
due
> to floating point problems is not solved at all but rather propagated and
> worsened by the questionable strategic decision to adopt Eiffel.
This is abolute rubbish!  (As usual from CJIII).  I work (as a consultant)
at
banks a LOT - they ALL use C as a mainstream development language (whether
or not they *should* is a different question!)

Eoin.
-- 
Eoin Woods, Watford, Hertfordshire, WD1 1PD, UK
Email:      Eoin@copse.demon.co.uk


~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Re-usable, patented financial software for business and banks 
Colin James III, Principal Scientist     www.cec-services.com
CEC Services, LLC, 1613 Morning Dr, Loveland, CO   80538-4410
Telephone lines:  Voice 970.622.0466; Facsimile: 970.622.0177
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~

Re: The disturbing myth of Eiffel portability

[Stephen J Bevan]

In article <3294e64b.74799475@news2.ibm.net> cjames3@ibm.net (The Rt Rev'd Colin James III, KOTM 1/96) writes:
   ... Eiffel emits ANSI C code. ...

Eiffel is a language and as such doesn't emit anything.
Some Eiffel implementations emit ANSI C, some don't.

Re: The disturbing myth of Eiffel portability

[James Youngman]

In article <32b09c4c.252526073@news2.ibm.net>, cjames3@ibm.net says...

>All new development in US banks with European branches is in C++ back end
>and many front ends (none in Eiffel that I know of).  This is partly due to
>C with its silly pointers not scaling well and mostly due to floating point
>problems at run time in C.

The runtime behaviour of C++ has just the same pros and cons as that of C.

Is that your hat you are talking out of?  Funny place to wear it...

-- 
James Youngman       VG Gas Analysis Systems |The trouble with the rat-race 
 Before sending advertising material, read   |is, even if you win, you're 
http://www.law.cornell.edu/uscode/47/227.html|still a rat.

Re: The disturbing myth of Eiffel portability

[Kaz Kylheku]

In article <3294e64b.74799475@news2.ibm.net>,
The Rt Rev'd Colin James III, KOTM 1/96 <cjames3@ibm.net> wrote:
>It is common knowledge that the same ANSI C source code when compiled by
>different ANSI C compilers produces executables which when run yield
>different, inconsistent floating point results.  
>
>This is due to the fact that the runtime floating point packages of ANSI C
>compilers vary as to word size and are not required to conform to strict

Runtime packages? Most floating point code these days translates to floating
point machine language. The industry is converging on using the standard
IEEE floating point formats.

>standards, other than weasel words, as are Ada compilers.
>
>Eiffel emits ANSI C code.
>
>Therefore Eiffel is in fact not truly portable and can in fact yield
>different numerical results according to platform.

Any computer scientist worth his salt knows that floating point numbers are
only approximations of real quantities. Well written numerical analysis code
takes this into consideration, and can be made portable. 

You cannot expect bit for bit equality from portable floating point code, but
you can write the program in such a way that it will produce well-behaved
approximations, and so that it will produce better and better approximations on
more and more capable numerical processors.   The fact is that forcing each
implementation of a language to do floating point math precisely the same way
is completey impractical, because it would impose a *huge* performance hit
which is often not acceptable in number crunching.

>That begs the following question:  how can the largest Eiffel project of
>over 700,000 lines of code (the CALfp bank's derivatives' program) expect
>to be taken seriously if the source code when compiled on different
>platforms could produce inconsistent and erroneous results.  

What fool would use floating point numbers for a banking system in the first
place? Floating point numbers are not well suited for representing currency,
except if their extra mantissa bits allow you to use them as ``large
integers''. 

>In other words, the reason that banks generally have learned to avoid C due
>to floating point problems is not solved at all but rather propagated and
>worsened by the questionable strategic decision to adopt Eiffel.  That fact
>may of course explain why no other famous banks with both US _and_ European
>computer operations have jumped on the Eiffel bandwagon and predictably
>would not, such as the perfect example of CitiCorp which had the first GE
>bank computers about 1962.
>
>Don Knuth tried to get around the floating point problem in the 1960's by
>suggesting in Volumes 1 and 2 of his opus to use scaled integers.  It's too
>bad that the immature project weenies choose not to read that classic
>anymore these days and thus don't know the meaning of integer math.

So what is your real beef? That floating point code is not portable bit for bit
or that it is inappropriately used by ``immature project weenies''?

Re: The disturbing myth of Eiffel portability

[Robert Dewar]

Kaz says

"Any computer scientist worth his salt knows that floating point numbers are
only approximations of real quantities. Well written numerical analysis code
takes this into consideration, and can be made portable.

You cannot expect bit for bit equality from portable floating point code, but
you can write the program in such a way that it will produce well-behaved
approximations, and so that it will produce better and better approximations on
more and more capable numerical processors.   The fact is that forcing each
implementation of a language to do floating point math precisely the same way
is completey impractical, because it would impose a *huge* performance hit
which is often not acceptable in number crunching."


Many computer scientists have this view of floating-point, but at least in
the IEEE world, this is an incorrect view. IEEE arithmetic is NOT an
approximation of real arithmetic, but rather an EXACT implementation of
a very well defined arithmetic, whose axioms are well understood. 

The idea that it is wrong to test for exact equality is quite incorrect,
there are many algorithms where it is perfectly legitimate to test for
exact equality if you know you are dealing with IEEE arithmetic.

This *huge* performance hit occurs on fewer and fewer machines, nearly all
machines now support IEEE arithmetic, and the decision to require this
semantis in Java represents a final nail in the coffin for weird (and often
badly designed) non-IEEE arithmetic systems. 

Re: The disturbing myth of Eiffel portability

[Jeff Miller]

The Rt Rev'd Colin James III, KOTM 1/96 wrote:
> 
> Eoin Woods is deluded in the article quoted below.
> 
> Almost all banks still do most of their processing in COBOL.
> 
> All new development in US banks with European branches is in C++ back end
> and many front ends (none in Eiffel that I know of).  This is partly due to
> C with its silly pointers not scaling well and mostly due to floating point
> problems at run time in C.

Could you elaborate on the way pointers in C restrict scalability?

Re: The disturbing myth of Eiffel portability

[Larry Kilgallen]

In article <dewar.848444338@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> This *huge* performance hit occurs on fewer and fewer machines, nearly all
> machines now support IEEE arithmetic, and the decision to require this
> semantis in Java represents a final nail in the coffin for weird (and often
> badly designed) non-IEEE arithmetic systems. 

To be fair, many of the machines whose native floating point arithmetic
is non-IEEE were designed before the IEEE standard.  Manufacturers also
owe some continuity to their existing customers.

Larry Kilgallen

Re: The disturbing myth of Eiffel portability

[Piercarlo Grandi]

>>> "jmiller" == Jeff Miller <jmiller@probe.net> writes:

jmiller> The Rt Rev'd Colin James III, KOTM 1/96 wrote:

cjames3> Eoin Woods is deluded in the article quoted below.

Ah well, perhaps you should phrase this in a less personal way :-).

cjames3> Almost all banks still do most of their processing in COBOL.

Well, indeed, if one is considering back-office processing; but their
front-office applications are nowadays indeed mostly done, in the more
progressive banks, in:

cjames3> All new development in US banks with European branches is in
cjames3> C++ back end and many front ends

In many cases these front-ends are C++ based too...

cjames3> (none in Eiffel that I know of).  This is partly due to C with
cjames3> its silly pointers not scaling well and mostly due to floating
cjames3> point problems at run time in C.

I don't think that the definite advantage that C++ has as to the ability
to define ``intelligent'' pointers is much relevant to why banks use C++
instead of C for front-office developments, so I would not consider it
even a partial cause ("partly due");

IMNHO the major cause is perhaps the fashionability of C++.

As to technical reasons I can agree that perhaps the strongest ("mostly
due") one is indeed the ease and efficiency of adding a multiple
precision numeric type to C++, which obviates the variable precision
properties of floating point arithmetic in C.

jmiller> Could you elaborate on the way pointers in C restrict
jmiller> scalability?

Well, there is not much need to: there is an ample literature (just use
some WWW index to search for either "intelligent pointer" or "pointer
swizzling" for many references to the two concepts) on the possibility
to define ``intelligent'' pointer datatypes in C++, in a way that is
impossible in C, and then uasing those to implement the ability to do
pointer ``swizzling'' and other techniques (mostly inspired by
Smalltalk-80's LOOM and other similar technologies in Lisp Machines)
that allow a program to manipulate a set of objects potentially much
larger than that which can be contained in the address space visible to
a program (depending on how large the latter is).

Re: The disturbing myth of Eiffel portability

[Piercarlo Grandi]

>>> "JYoungman" == James Youngman <JYoungman@vggas.com> writes:

JYoungman> In article <32b09c4c.252526073@news2.ibm.net>,
JYoungman> cjames3@ibm.net says...

cjames> All new development in US banks with European branches is in C++
cjames> back end and many front ends (none in Eiffel that I know of).

This does not mean that there are _no_ banks using Eiffel...

cjames> This is partly due to C with its silly pointers not scaling well
cjames> and mostly due to floating point problems at run time in C.

JYoungman> The runtime behaviour of C++ has just the same pros and cons
JYoungman> as that of C.

Those that have some idea of what C++ is about know better. It is very
easy to define a new data type, say 'Currency', in C++, and implement
precise arithmetic for it which is efficient at runtime, and which does
not suffer from the variable precision of the builting 'float' type.

In C one has the relatively unpleasant choice of either using the
builtin floating point datatype, whose variable precision is not
acceptable when dealing with (potentially large) sums of money (at least
without expending considerable analytical effort in range analysis), or
using a non encapsulated datatype and a library of external, non
inlined, functions.

This is both less convenient and (usually) less efficient than in C++;
for while C++ has inline functions, neither C nor ANSI C have them, and
using macros is not quite the same thing.

Indeed one of the _major_ design goals of C++, according to its authors,
is to allow the programmer to define new datatypes that can be used
almost as (e.g. wrt performance and syntax) a builtin one; this is
indeed possible thanks to the ability to overload operators and
functions and to suggest that the compiler inline them, and thanks to
the abiluty to encapsulate the representation of those user defined
datatypes (including ``intelligent'' pointers, as described above).

In this respect Eiffel is rather less attractive; user defined Eiffel
datatypes are not quite on a par with builtin ones either as to syntax
(which IMNHO is not important) or as to performance (which matters for
very fine granularity datatypes).

  It is rather significant IMNHO that Eiffel 3 has now expanded
  datatypes, which however small a detail, allows for _considerable_
  improvements in performance, in particular asd to garbage collection.

JYoungman> Is that your hat you are talking out of?  Funny place to wear
JYoungman> it...

Please keep such innuendo to yourself. Even if 'cjames3' occasionally
forgets it himself, this is in theory a technical, if informal,
newsgroup.

Re: The disturbing myth of Eiffel portability

[Matt Kennel]

Robert Dewar (dewar@merv.cs.nyu.edu) wrote:
: The idea that it is wrong to test for exact equality is quite incorrect,
: there are many algorithms where it is perfectly legitimate to test for
: exact equality if you know you are dealing with IEEE arithmetic.

: This *huge* performance hit occurs on fewer and fewer machines, nearly all
: machines now support IEEE arithmetic, and the decision to require this
: semantis in Java represents a final nail in the coffin for weird (and often
: badly designed) non-IEEE arithmetic systems. 

I think requiring "IEEE arithmetic" is acceptable if this means
"arithmetic on a well-defined finite subset of rationals" in a particular
bit representation. 

On the other hand, I think it is too strenuous and ill-advised for a language
to insist upon 100% full exact IEEE exception handling, as this
is far less often compatible with high performance and portability. 

--
Matthew B. Kennel/mbk@caffeine.engr.utk.edu/I do not speak for ORNL, DOE or UT
Oak Ridge National Laboratory/University of Tennessee, Knoxville, TN USA/ 

Re: The disturbing myth of Eiffel portability

[James Mansion]

Kaz Kylheku wrote:
 
> What fool would use floating point numbers for a banking system in the first
> place? Floating point numbers are not well suited for representing currency,
> except if their extra mantissa bits allow you to use them as ``large
> integers''.

Hmm, what fool would make a statement like this without any
understanding of
derivatives trading? ;-)

Seriously, it makes sense to do the risk side of derivatives with
doubles.
You don't need that last little bit of accuracy when running the
valuation
models (which are themselves approximations) and you do need them to go
fast.

The settlements side is a thornier issue and you may need to use large
integers,
though its not entirely clear cut given the sizes of the principal
values
concerned.  It *is* the case that you have to read the letter of the
rounding
rules in use very carefully, to see where and how the rounding takes
place and
to how many decimal places.  Bear in mind that while you can't represent
all
fractions, you *can* represent integers exactly within quite a wide
range of
values, so you can potentially scale actual values so that the
appropriate
accuracy is there.

James

Re: The disturbing myth of Eiffel portability

[Kaz Kylheku]

In article <3292D290.51F7@wgold.demon.co.uk>,
James Mansion  <james@wgold.demon.co.uk> wrote:
>Kaz Kylheku wrote:
> 
>> What fool would use floating point numbers for a banking system in the first
>> place? Floating point numbers are not well suited for representing currency,
>> except if their extra mantissa bits allow you to use them as ``large
>> integers''.
>
>Hmm, what fool would make a statement like this without any
>understanding of
>derivatives trading? ;-)

Yes, I took a risk there. The only derivatives I know are in the domain
of elementary calculus, and few are interested in trading those! :)

Re: The disturbing myth of Eiffel portability

[Keith Thompson]

In <dewar.848444338@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> Kaz says
> 
> > Any computer scientist worth his salt knows that floating point
> > numbers are only approximations of real quantities. Well written
> > numerical analysis code takes this into consideration, and can be
> > made portable.
[...]
> Many computer scientists have this view of floating-point, but at least in
> the IEEE world, this is an incorrect view. IEEE arithmetic is NOT an
> approximation of real arithmetic, but rather an EXACT implementation of
> a very well defined arithmetic, whose axioms are well understood. 

True, but that well defined arithmetic was designed to be an approximation
of real arithmetic.

> The idea that it is wrong to test for exact equality is quite incorrect,
> there are many algorithms where it is perfectly legitimate to test for
> exact equality if you know you are dealing with IEEE arithmetic.

Agreed.  It's important to remember, though, that the behavior of IEEE
arithmetic can change depending on the current rounding mode, and the
programmer may or may not have direct control over that.  However, I
don't think that affects any cases where it makes sense to test for
exact equality.

I believe the Ada specification of floating-point behavior is loose enough
that an implementation can conform to it with any IEEE rounding mode.

> This *huge* performance hit occurs on fewer and fewer machines, nearly all
> machines now support IEEE arithmetic, and the decision to require this
> semantis in Java represents a final nail in the coffin for weird (and often
> badly designed) non-IEEE arithmetic systems. 

Any bets on whether Ada 200Y mandates (or at least strongly encourages)
IEEE arithmetic?

-- 
Keith Thompson (The_Other_Keith) kst@thomsoft.com <*>
TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2706
FIJAGDWOL

Re: The disturbing myth of Eiffel portability

[Paul Johnson]

In article <vwj20dodc99.fsf@osfb.aber.ac.uk>, pcg@aber.ac.uk says...

>Indeed one of the _major_ design goals of C++, according to its authors,
>is to allow the programmer to define new datatypes [...]
>
>In this respect Eiffel is rather less attractive; user defined Eiffel
>datatypes are not quite on a par with builtin ones either as to syntax
>(which IMNHO is not important) or as to performance (which matters for
>very fine granularity datatypes).

Syntax first: I think you will find that the built-in Eiffel data types
are on a par with the user-defined ones: unlike C++ things like integer
and array are defined as classes.

Efficiency: see the thread about benchmarks.  Where exactly do you think
that user defined data types lose performance?

>  It is rather significant IMNHO that Eiffel 3 has now expanded
>  datatypes, which however small a detail, allows for _considerable_
>  improvements in performance, in particular asd to garbage collection.

More importantly, it has allowed the builtin data types to become part of
the class hierarchy.

Paul.

-- 
Paul Johnson            | GEC-Marconi Ltd is not responsible for my opinions. |
+44 1245 242244         +-----------+-----------------------------------------+
Work: <paul.johnson@gecm.com>       | You are lost in a twisty maze of little
Home: <Paul@treetop.demon.co.uk>    | standards, all different.

Re: The disturbing myth of Eiffel portability

[Robert Dewar]

Keith said

"Agreed.  It's important to remember, though, that the behavior of IEEE
arithmetic can change depending on the current rounding mode, and the
programmer may or may not have direct control over that.  However, I
don't think that affects any cases where it makes sense to test for
exact equality."


No, that's wrong. the IEEE 754 and 854 standards (that is what we are
referring to when we informally talk of IEEE arithmetic), require that
a programmer not only have control over the rounding mode, but that this
control must be *dynamic*, i.e. that a given section of code must be
able to be executed with different rounding modes.

Any so called IEEE arithmetic implementation that does not meet this
requirement is non-standard.

In practice, everyone operates in round-to-nearest all the time, I have
never encountered an IEEE compliant or even semi-compliant system in which
this was not the default.

One thing to remember about the IEEE standard is that it is NOT a hardware
standard. Generally any implementation of the standard involves a
combination of software and hardware.

When chip manufacturers say they provide IEEE arithmetic, they do NOT
mean that any language operating on that chip is automatically IEEE
standard conforming, instead they mean that their base arithmetic more
or less matches the IEEE model (sometimes less than more, recently
there have been some disturbing departures from the IEEE model, e.g.
the failure to provide denormals on the MIPS R10000).

Ada 95 as defined out of the box is nowhere near IEEE compliant. For
example it lacks handling of infinities and NaN's. But it is indeed
the case that Ada 95 has been designed to be compatible with the
standard, in the sense that it is quite possible to provide an IEEE
compliant implementation without violating Ada 95 semantics (which
were carefully designed to make sure that was the case).

I did a draft of a proposed IEEE binding for Ada 95 some time ago, and
one of my students, Sam Figueroa, has been following up on this and
refining the draft, as well as investigating some fundamental issues
revolving around floating-point semantics in languages like Ada. However,
there has been insufficient interest for this work to be finished so far

Re: The disturbing myth of Eiffel portability

[Kaz Kylheku]

In article <570j6p$nlq$1@news-s01.ny.us.ibm.net>,
Francois Labreque  <flabreq@ibm.net> wrote:

>Anyway, I agree with you that unless you deal with the infinitely small 
>or infinitely large, gone are the days where you had to substract two 
>floats and see if the difference was less than some predefined "tiny" 
>value rather than testing them for equality.

That is nonsense. 

Re: The disturbing myth of Eiffel portability

[Robert Dewar]

Larry said

"To be fair, many of the machines whose native floating point arithmetic
is non-IEEE were designed before the IEEE standard.  Manufacturers also
owe some continuity to their existing customers."

Well the IEEE standard is nearly 20 years old now, so there are very few
such machines left, and they become of decreasing interest. The only
really notable exception is the Japanese super computers, which made the
horrible error of copying junk IBM hex floating-point.

Re: The disturbing myth of Eiffel portability

[Francois Labreque]

dewar@merv.cs.nyu.edu (Robert Dewar) wrote:
>This *huge* performance hit occurs on fewer and fewer machines, nearly all
>machines now support IEEE arithmetic, and the decision to require this
>semantis in Java represents a final nail in the coffin for weird (and often
>badly designed) non-IEEE arithmetic systems. 
>

I think the original discussion involved "Large US Banks having European 
branches" i.e. The-One-Bank-Where-CJ3-Worked-Therefore-All-Of-Them, and I 
really don't think that we'll see Java-enabled bank machines or terminals 
really soon.  Most of the banks still use COBOL on their mainframes and 
are too busy making their code and databases survive the year 2000 to 
think about Java.

Anyway, I agree with you that unless you deal with the infinitely small 
or infinitely large, gone are the days where you had to substract two 
floats and see if the difference was less than some predefined "tiny" 
value rather than testing them for equality.


-- 
Francois Labreque | "The surest sign of the existence of extraterrestrial
flabreq@ibm.net   |  intelligence is that they never bothered to come and
flab@ca.ibm.com   |  visit us" - Calvin
I may work for them, but i'm not paid enough to speak for them!

Re: The disturbing myth of Eiffel portability

[Robert Dewar]

Larry said

"Well the VAX is that age ("nearly 20"), the Alpha supports both VAX
and IEEE formats.  Certainly System/390 is that age, if you allow for
the fact that it includes System/360 capabilities.  I know nothing
about System/360 floating point, but I know MVS has a strong tradition
of supporting the installed base.  Perhaps someone from OC Systems can
comment on support of IEEE by IBM."

OK, but here are only two examples, which kind of proves my point. Of these,
no one would choose a System/390 for high end floating-point work (or
let's say, no one interested in optimal price performance), and the Alpha
is an IEEE machine (yes, it supports the old inferior Vax formats for
consistency, but I would still regard it as an IEEE machine).

So, only 2 examples (actually there are others, notably the Unisys, and
the 1750-A, but still non-IEEE machines are a nearly extinct breed, and
I suspect that Java will be another significant nail in the coffin!

Re: The disturbing myth of Eiffel portability

[Larry Kilgallen]

In article <dewar.848592914@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> Larry said
> 
> "To be fair, many of the machines whose native floating point arithmetic
> is non-IEEE were designed before the IEEE standard.  Manufacturers also
> owe some continuity to their existing customers."
> 
> Well the IEEE standard is nearly 20 years old now, so there are very few
> such machines left, and they become of decreasing interest. The only
> really notable exception is the Japanese super computers, which made the
> horrible error of copying junk IBM hex floating-point.

Well the VAX is that age ("nearly 20"), the Alpha supports both VAX
and IEEE formats.  Certainly System/390 is that age, if you allow for
the fact that it includes System/360 capabilities.  I know nothing
about System/360 floating point, but I know MVS has a strong tradition
of supporting the installed base.  Perhaps someone from OC Systems can
comment on support of IEEE by IBM.

Larry Kilgallen

Re: The disturbing myth of Eiffel portability

[Norman H. Cohen]

Keith Thompson wrote:

> Any bets on whether Ada 200Y mandates (or at least strongly encourages)
> IEEE arithmetic?

Ada 95 already explicitly acknowledges the IEEE standard (referring to
it as IEC 559:1989 rather than IEEE 754, since Ada 95 is itself an
ISO/IEC standard).  The attribute S'Signed_Zeros is defined in A.5.3(13)
in terms of the floating-point standard.  A.10.9(35) gives
implementation permission for floating-point Put and Get to have some
textual representation of NaNs and infinities.  In the Numerics Annex,
G.1.1(56,57) gives advice in implementing complex arithmetic in a manner
that will produce the expected results in "systems that, in the future,
support an Ada binding to IEC559:1989".

Of course the intent here is to allow rather than require support of
IEEE arithmetic.  I think implementors can be counted on to provide
IEEE-based floating-point types (at the very least, types whose behavior
is consistent with SOME specified IEEE mode) on those targets with
IEEE-compliant hardware.

Perhaps a complete binding to the full floating-point standard (with
control over rounding modes and NaN signaling modes) will be adopted as
a secondary standard, implementable either directly in hardware or by
software emulation, depending on the target.  This need not await Ada
200Y (a project that so far exists only in the imaginations of some
participants in this newsgroup).

> FIJAGDWOL

I don't follow.  Could you please elaborate?

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: The disturbing myth of Eiffel portability

[Ken Garlington]

Larry Kilgallen wrote:
> 
> In article <dewar.848444338@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> 
> > This *huge* performance hit occurs on fewer and fewer machines, nearly all
> > machines now support IEEE arithmetic, and the decision to require this
> > semantis in Java represents a final nail in the coffin for weird (and often
> > badly designed) non-IEEE arithmetic systems.
> 
> To be fair, many of the machines whose native floating point arithmetic
> is non-IEEE were designed before the IEEE standard.  Manufacturers also
> owe some continuity to their existing customers.

And, also to be fair, many of us computer scientists who got the "equality bad"
speech in numerical methods courses were _using_ machines that were designed
before the IEEE standard. :)

> 
> Larry Kilgallen

-- 
LMTAS - "Our Brand Means Quality"
For more info, see http://www.lmtas.com or http://www.lmco.com

Re: The disturbing myth of Eiffel portability

[Robert Dewar]

Matt says

"On the other hand, I think it is too strenuous and ill-advised for a language
to insist upon 100% full exact IEEE exception handling, as this
is far less often compatible with high performance and portability.
"

I think Matt may be confused here. neither 754 nor 854 require support
for floating-point exceptions. They require only the support of infinity
and Nan semantics (read the standard, this is a common misconception!)_

Re: The disturbing myth of Eiffel portability

[Lawrence Kirby]

In article <E17FM8.9Gs@thomsoft.com> kst@thomsoft.com "Keith Thompson" writes:

>In <dewar.848444338@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
>> Kaz says
>> 
>> > Any computer scientist worth his salt knows that floating point
>> > numbers are only approximations of real quantities. Well written
>> > numerical analysis code takes this into consideration, and can be
>> > made portable.
>[...]
>> Many computer scientists have this view of floating-point, but at least in
>> the IEEE world, this is an incorrect view. IEEE arithmetic is NOT an
>> approximation of real arithmetic, but rather an EXACT implementation of
>> a very well defined arithmetic, whose axioms are well understood. 
>
>True, but that well defined arithmetic was designed to be an approximation
>of real arithmetic.

I observe that there are a lot of 32 bit integer + IEEE floating point
platforms out there so what is the best way to implement financial
calculations (being the topic of this thread) on such platforms? 

If you represent quantities as integral values that can be represented
exactly by IEEE then you have something has a larger guaranteed range of
values than a 32 bit integer (e.g. what long often in on C implementations)
and results are exact so long as they too are representable. Division can
be dealt with without too much difficulty. Many CPUs now can process
floating point operations (especially mutiplication) faster than they can
process integer operations.

Financial calculations within (fairly generous) limits can use IEEE
floating point and be *proven* correct barring bugs in the implementation.
But bugs can affect integer calculations as well. All this depends on the
type of operation being performed. Adding up the value of a portfolio has
different issues compared to calculating loan repayments/compound interest.
The former can be trivially done using IEEE floating point. The latter is
an imprecise quantity unless you specify extra rules. Floating point is
probably as good as any format in dealing with it and better than most. No
format can represent general irrational quantities precisely.

>> The idea that it is wrong to test for exact equality is quite incorrect,
>> there are many algorithms where it is perfectly legitimate to test for
>> exact equality if you know you are dealing with IEEE arithmetic.
>
>Agreed.  It's important to remember, though, that the behavior of IEEE
>arithmetic can change depending on the current rounding mode, and the
>programmer may or may not have direct control over that.  However, I
>don't think that affects any cases where it makes sense to test for
>exact equality.

However in situations where all results are exact and within the
precision of the format. So for a useful class of problems rounding
method makes no difference.

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

Re: The disturbing myth of Eiffel portability

[Robert Dewar]

Francois agrees with me:

"Anyway, I agree with you that unless you deal with the infinitely small
or infinitely large, gone are the days where you had to substract two
floats and see if the difference was less than some predefined "tiny"
value rather than testing them for equality."


BUT, I said nothing of the kind. I said that comparing two float's
for equality was a sensible operation in the sense that it has well
defined semantics.

But whether you use exact equality operations, or some more complex
criterion, including for example "subtracting two floats and see if
the difference was less than some predefined 'tiny' value", is an
issue of algorithmic requirements.

Suppose we are doing an iteration with a converging result. How do we
detect convergence? It depends on the situation.

Let's give two examples:

1. Computing square roots using Newton-Raphson iteration with round to
   zero arithmetic. In this case, you get absolute convergence in IEEE
   arithmetic, so an exact test for equality is fine.

2. Integrating a function using Simpson's rule with finer and finer
   element size, e.g. halving the element each time. Here you jolly
   well will NOT get absolute convergence, since after a while the
   rounding errors will dominate the fundamental inaccuracy of the
   approximation method. Catching the right point (i.e. figuring
   out what the right tiny value is) is not easy. I well remember that
   the business shool at U of Chicago used to give out this assignment
   as the second assignment in the beginning Fortran course, and it
   ate up HUGE amounts of computer time, because students missed the
   convergence point, and once you have missed it, you are in an
   infinite loop.

The required analysis is delicate. For example, in the above, I happen
to know (or at least I am pretty sure I remember), that the analysis
for case one is correct for chop semantics, but I simply don't know if
it is right for round semantics (you have to worry about the possibility
of oscillating between two adjacent machine numbers for example).

Sometimes you do the (abs (a-b) < tiny) as a substitute for proper
analysis, and that's not terrible ... but may be unnecessarily
ineffcient.

My point was simply that it is wrong to tell students (or to think!) that
exact comparison of floating-point values is always wrong. Consequently
it is indeed fine in some cases to do such comparisons. But it is wildly
wrong to think that such comparisons are always appropriate.

For example

    if (1.0 / 10.0) = 0.1 then

has somewhat tricky semantics. One reading of IEEE 754 requires the value
of the non-machine number literal 0.1 to be done in the currrent rounding
mode. Since this is dynamic, this would imply a truly horrible execution
model, one which is barely realistic. If instead, as is typical in almost
all implementations of all languages, the 0.1 is evaluated at compile
time using round-to-nearest, then the behavior of this test *may*
depend on the current rounding mode (I say may because without more
work than I care to put in, I do not know if 10.0 has a differnt
representation in chop and round semantics, but if 10.0 is a wrong
choice, there are others :-)

P.S. I know that in Ada the above is universal real --just change the
1.0 to a variable with valeu 1.0 if you are nitpicking at that level :-)

P.P.S My proposed binding to the IEEE model for Ada dealt with the vexing
issue of literals by saying that using a normal numeric literal required
round-to-nearest semantics at compile time, and that the special intrinsic
function:

   +"1.0"

yielded a literal value that was evaluatd according to the current rounding
mode.

Re: The disturbing myth of Eiffel portability

[Joachim Durchholz]

fred@genesis.demon.co.uk wrote 24.11.96:

> Financial calculations within (fairly generous) limits can use IEEE
> floating point and be *proven* correct barring bugs in the implementation.
> But bugs can affect integer calculations as well.

However, integer bugs are less likely. After all, IEEE format is much more  
complicated (at least in comparison to two's-complement integer). For IEEE  
format, there is room for interpretation (really there isn't, but some  
implementors behave as if there were).
E.g. the infamous Pentium bug was in the FPU, not in the ALU. Of course  
this is jumping to conclusions from a statistically insignificant  
sample...

> No
> format can represent general irrational quantities precisely.

There is one - storing formulae instead of quantities :)

Actually this is feasible - Mathematica and Co. do exactly this. This  
allows them to compute as many digits as required on the fly, without loss  
of precision from intermediate results.
(Of course there is still a round-off error, but it is always on the last  
printed digits.)

Anybody on his way implementing a FORMULA class for unlimited-precision  
math?

Regards,
-Joachim

--
Looking for a new job. Resume available on request. WWW version of resume
available under http://www.franken.de/users/herold/jhd/resume/index.html

Re: The disturbing myth of Eiffel portability

[Robert Dewar]

Ken Garlington said

"And, also to be fair, many of us computer scientists who got the "equality bad"
speech in numerical methods courses were _using_ machines that were designed
before the IEEE standard. :)"

Sure, but it was still bad advice. It is true that it is harder to prove
theorems about machines with junk floating-point, but that does not make
it impossible. For example Newton_Raphson iterates to precise equality
on most floating-point models.

Re: The disturbing myth of Eiffel portability

[Van Snyder]

In article <dewar.848592914@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:

|> Well the IEEE standard is nearly 20 years old now, so there are very few
|> such machines left, and they become of decreasing interest. The only
|> really notable exception is the Japanese super computers, which made the
|> horrible error of copying junk IBM hex floating-point.

There's an interesting story behind that.

When IBM was designing the 360, they hired Welwel Kahan as a consultant on
floating point arithmetic.  His recommendation was that the worst possible
thing they could do would be to use HEX radix floating point.  So they went
and did it anyway.

BTW, there is another notable exception.

Alphas can sort-of emulate VAX floating point, which isn't IEEE.  But when
they do, they convert VAX FP formats to IEEE, do the arithmetic, then convert
them back.  In the process, they lose one bit.  So it's the worst of both
worlds.

-- 
What fraction of Americans believe   |  Van Snyder
Wrestling is real and NASA is fake?  |  vsnyder@math.jpl.nasa.gov

Re: The disturbing myth of Eiffel portability

[Lawrence Kirby]

In article <6LW663dk3RB@herold.franken.de>
           jhd@herold.franken.de "Joachim Durchholz" writes:

>fred@genesis.demon.co.uk wrote 24.11.96:
>
>> Financial calculations within (fairly generous) limits can use IEEE
>> floating point and be *proven* correct barring bugs in the implementation.
>> But bugs can affect integer calculations as well.
>
>However, integer bugs are less likely. After all, IEEE format is much more  
>complicated (at least in comparison to two's-complement integer). For IEEE  
>format, there is room for interpretation (really there isn't, but some  
>implementors behave as if there were).
>E.g. the infamous Pentium bug was in the FPU, not in the ALU. Of course  
>this is jumping to conclusions from a statistically insignificant  
>sample...

Doesn't the Pentium use the FPU for integer division?

>> No
>> format can represent general irrational quantities precisely.
>
>There is one - storing formulae instead of quantities :)
>
>Actually this is feasible - Mathematica and Co. do exactly this. This  
>allows them to compute as many digits as required on the fly, without loss  
>of precision from intermediate results.
>(Of course there is still a round-off error, but it is always on the last  
>printed digits.)

So Mathematica still have to evaluate the formulae at some point when you
need a value and the issue of how you round is still there.

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

Re: The disturbing myth of Eiffel portability

[Piercarlo Grandi]

>>> "paul.johnson" == Paul Johnson <paul.johnson@gecm.com> writes:

paul.johnson> In article <vwj20dodc99.fsf@osfb.aber.ac.uk>,
paul.johnson> pcg@aber.ac.uk says...

pcg> [ ... ] In this respect Eiffel is rather less attractive; user
pcg> defined Eiffel datatypes are not quite on a par with builtin ones
pcg> either as to syntax (which IMNHO is not important) or as to
pcg> performance (which matters for very fine granularity datatypes).

paul.johnson> Syntax first: I think you will find that the built-in
paul.johnson> Eiffel data types are on a par with the user-defined ones:
paul.johnson> unlike C++ things like integer and array are defined as
paul.johnson> classes.

Well, only in Eiffel 3, which is a rather different language from Eiffel
(despite backwards similarity); and even in Eiffel 3, they are a bit
more special than user defined types.

  BTW, it's clear that different people mean different things with
  ``Eiffel''; the various versions of the language are rather
  different. The same applies to ``Ada'', ``C'', ``FORTRAN'' and also to
  ``C++'', where one never really knows _which_ version of the language
  is being discussed, for while for example for Ada and C and FORTRAN
  there is a customary indication of version (Ada 83 and Ada 95, C and
  ANSI C, FORTRAN 66, FORTRAN 77, ...) I have very rarely seen any usage
  of the C++ 1.0, C++ 2.x, C++ 3.x or C++ draft ISO @ [date] labels. In
  part this is because C++ implementations often implement bits from
  several versions...

What has most impressed me in the changes between Eiffel and Eiffel 3 is
the obvious change of many important design decisions, and the giving of
much greater importance to aspects that have always ben central to the
design of C++ (there are many examples: from 'expanded' to 'bit N').

If Eiffel had been designed from the start as a more C/C++ like
language, the ugliness of certain aspects of Eiffel 3 could have been
avoided...

paul.Johnson> Efficiency: see the thread about benchmarks.  Where
paul.johnson> exactly do you think that user defined data types lose
paul.johnson> performance?

Memory management, for like in SIMULA, they ``must'' be heap allocated,
and accessed indirectly via pointers/references (and without something
like the 'WITH' construct of Pascal or block prefixing as in SIMULA).

In Eiffel 3 they _need not_ be heap allocated; but then there are other
aspects that more or less mandate the existence of a system builder,
which is indeed duly provided (certain overheads can only be avoided if
a program-wide optimization is done), but which causes its own
difficulties (convenience more than performance).

pcg> It is rather significant IMNHO that Eiffel 3 has now expanded
pcg> datatypes, which however small a detail, allows for _considerable_
pcg> improvements in performance, in particular asd to garbage
pcg> collection.

paul.johnson> More importantly, it has allowed the builtin data types to
paul.johnson> become part of the class hierarchy.

Well, this is elegant indeed (except for abominations like 'NONE', which
was justly criticized in the discussion of Eiffel in OOSC); but I think
that the problem with having all non-primitive values accessed by
reference and in the heap was a far bigger problem as to the
practicality of using Eiffel than the inability to have basic types part
of the class hierarchy.

Re: The disturbing myth of Eiffel portability

[Don Harrison]

Piercarlo Grandi writes:

:Well, only in Eiffel 3, which is a rather different language from Eiffel
:(despite backwards similarity); and even in Eiffel 3, they are a bit
:more special than user defined types.
:
:  BTW, it's clear that different people mean different things with
:  ``Eiffel''; the various versions of the language are rather
:  different. The same applies to ``Ada'', ``C'', ``FORTRAN'' and also to
:  ``C++'', where one never really knows _which_ version of the language
:  is being discussed, for while for example for Ada and C and FORTRAN
:  there is a customary indication of version (Ada 83 and Ada 95, C and
:  ANSI C, FORTRAN 66, FORTRAN 77, ...) I have very rarely seen any usage
:  of the C++ 1.0, C++ 2.x, C++ 3.x or C++ draft ISO @ [date] labels. In
:  part this is because C++ implementations often implement bits from
:  several versions...

I think you'll find that when people refer to languages without stating which 
version, they are typically referring to the current incarnation. They will
typically only mention a specific version if distinguishing between them
(usually to update their knowledge). In the case of "Eiffel", they usually mean
Eiffel 3. If they mean OOSC Eiffel, they are graciously informed that some
things have changed since then. :)


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: The disturbing myth of Eiffel portability

[Piercarlo Grandi]

>>> "donh" == Don Harrison <donh@syd.csa.com.au> writes:

donh> I think you'll find that when people refer to languages without
donh> stating which version, they are typically referring to the current
donh> incarnation.

The incarnation of the language or that of the language's name? For it
is often the case that the same name is used to label rather different
languages, not more or less minor revisions of the same language.

The obvious example is ``Algol'', where ALGOL 60 and ALGOL 68 are rather
different. But the difficulty exists even when the current language is a
a greatly expanded superset of the previous language, but the name has
not been changed. Both cases are somewhat common, and the Eiffel-Eiffel
3 distinction is one of many example.

Therefore the assumption above involves considerable difficulties.

When one says ``C++'', which version of C++ is implied? The one with or
without namespaces? The one with or without exception handling? And when
one says ``Smalltalk''? And which version of ``FORTRAN'' is current? And
nnwhen someone writes ``Ada is an OO language'', one should understand
that phrase wrt Ada [83] or Ada 95? What about Pascal? Pascal (either
1st or 2nd edition), or ISO Pascal? And the differences between C and
ANSI C, and the (unnamed) C-like subset of ``C++''?

For Eiffel at least the situation is clear; there are three languages,
Eiffel (which was never called Eiffel 1 AFAIK, even if occasionally the
name is used, even by myself), Eiffel 2 and Eiffel 3.

Eiffel and Eiffel 2 are fairly similar, so not much is lost by using the
same name for both; but Eiffel 3 is so different from Eiffel (being a
greatly "expanded" :-) superset, and the things in the superset being so
dramatically different in philosophy) that I think using the name of the
latter to indicate the former is a bit of a strain (similarly for
Sather, for which the version number is even more essential, as it has
been for quite a while a research language, and has undergone even more
frequent evolution).

Consider as an analogy the label ``Modula'': yes, Modula, Modula 2 and
Modula 3 are somewhat similar languages, but Modula 3 is rather
different from the other two (which are not compatible either way); what
should one understand when one writes ``Modula''? The current
``version''? Which one?

donh> They will typically only mention a specific version if
donh> distinguishing between them (usually to update their
donh> knowledge).

But Eiffel has got no version number -- Eiffel 2 and Eiffel 3 have got
it. You may have not noticed that in my article I was careful to Use
Eiffel where I meant Eiffel, and Eiffel 3 where I meant Eiffel 3, as
evident in the contrast in two consecutive paragraphs:

  piercarl> In this respect Eiffel is rather less attractive; user
  piercarl> defined Eiffel datatypes are not quite on a par with builtin
  piercarl> ones either as to syntax (which IMNHO is not important) or
  piercarl> as to performance (which matters for very fine granularity
  piercarl> datatypes).

  piercarl>   It is rather significant IMNHO that Eiffel 3 has now
  piercarl>   expanded datatypes, which however small a detail, allows
  piercarl>   for _considerable_ improvements in performance, in
  piercarl>   particular asd to garbage collection.

donh> In the case of "Eiffel", they usually mean Eiffel 3.

This may well be the case, but it creates confusion...

donh> If they mean OOSC Eiffel,

But there is no such thing as OOSC Eiffel: what is described in OOSC is
the language called "Eiffel", period, with no qualifiers whatsoever
(also, there are now _two_ ``OOSC Eiffels'': I haven't yet seen the
second edition of OOSC, but I imagine it will no longer be using Eiffel
but Eiffel 3 for examples).

  I personally regard the title of Betrand Meyer's book "Eiffel the
  language" as a bit of a misrepresentation: for the vast changes
  between Eiffel and Eiffel 3 reflect some negative experience with
  Eiffel (and Eiffel 2), and blurring the distinction between Eiffel 3
  and Eiffel seems a way to sweep such past problems under the carpet,
  as if there were a continuity that is not quite there. There are vast
  differences between the various ``C++''s too, and I cringe when people
  speak of ``C++'' as if it were one and not at least four successive
  rather different languages, but none imply regrets such as those
  evident in the evolution from Eiffel to Eiffel 3.

I personally try to use typographical conventions to indicate use of the
specific vs. the generic term; for example Eiffel denotes the language
called "Eiffel", and ``Eiffel'' means any of the languages called
"Eiffel", "Eiffel 2", "Eiffel 3".

I am especially keen on using such a convention when discussing
``Smalltalk'', in part because there are so many different and often
incompatible languages whose name includes the word "Smalltalk", and
also because there is _no_ language called "Smalltalk" (while there is
one called "Eiffel"), as the original ``Smalltalk''s were all, wisely,
tagged with names of the form "Smalltalk-<year>".

donh> they are graciously informed that some things have changed since
donh> then. :)

Perhaps a better assumption would be to use the language's own full name
(ALGOL 60 instead of Algol), or use some typographical convention to
indicate ``fuzzy'' names, or simply to assume that the version, if
missing is the one, if any, for which the phrase in which it appears
makes sense; for exmaple something like "C++ does not have multiple
inheritance" should be taken to refer to "C++ 1.0".

Re: The disturbing myth of Eiffel portability

[Piercarlo Grandi]

>>> "donh" == Don Harrison <donh@syd.csa.com.au> writes:

donh> I think you'll find that when people refer to languages without
donh> stating which version, they are typically referring to the current
donh> incarnation.

The incarnation of the language or that of the language's name? For it
is often the case that the same name is used to label rather different
languages, not more or less minor revisions of the same language.

The obvious example is ``Algol'', where ALGOL 60 and ALGOL 68 are rather
different. But the difficulty exists even when the current language is a
a greatly expanded superset of the previous language, but the name has
not been changed. Both cases are somewhat common, and the Eiffel-Eiffel
3 distinction is one of many example.

Therefore the assumption above involves considerable difficulties.

When one says ``C++'', which version of C++ is implied? The one with or
without namespaces? The one with or without exception handling? And when
one says ``Smalltalk''? And which version of ``FORTRAN'' is current? And
nnwhen someone writes ``Ada is an OO language'', one should understand
that phrase wrt Ada [83] or Ada 95? What about Pascal? Pascal (either
1st or 2nd edition), or ISO Pascal? Is ``C++'' the current ``C'', as it
incldues the latter as a subset?

For Eiffel at least the situation is clear; there are three languages,
Eiffel (which was never called Eiffel 1 AFAIK, even if occasionally the
name is used, even by myself), Eiffel 2 and Eiffel 3.

Eiffel and Eiffel 2 are fairly similar, so not much is lost by using the
same name for both; but Eiffel 3 is so different from Eiffel (being a
greatly "expanded" :-) superset, and the things in the superset being so
dramatically different in philosophy) that I think using the name of the
latter to indicate the former is a bit of a strain (similarly for
Sather, for which the version number is even more essential, as it has
been for quite a while a research language, and has undergone even more
frequent evolution).

Consider as an analogy the label ``Modula'': yes, Modula, Modula 2 and
Modula 3 are somewhat similar languages, but Modula 3 is rather
different from the other two (which are not compatible either way); what
should one understand when one writes ``Modula''? The current
``version''? Which one?

donh> They will typically only mention a specific version if
donh> distinguishing between them (usually to update their
donh> knowledge).

But Eiffel has got no version number -- Eiffel 2 and Eiffel 3 have got
it. You may have not noticed that in my article I was careful to Use
Eiffel where I meant Eiffel, and Eiffel 3 where I meant Eiffel 3, as
evident in the contrast in two consecutive paragraphs:

  piercarl> In this respect Eiffel is rather less attractive; user
  piercarl> defined Eiffel datatypes are not quite on a par with builtin
  piercarl> ones either as to syntax (which IMNHO is not important) or
  piercarl> as to performance (which matters for very fine granularity
  piercarl> datatypes).

  piercarl>   It is rather significant IMNHO that Eiffel 3 has now
  piercarl>   expanded datatypes, which however small a detail, allows
  piercarl>   for _considerable_ improvements in performance, in
  piercarl>   particular asd to garbage collection.

donh> In the case of "Eiffel", they usually mean Eiffel 3.

This may well be the case, but it creates confusion...

donh> If they mean OOSC Eiffel,

But there is no such thing as OOSC Eiffel: what is described in OOSC is
the language called "Eiffel", period, with no qualifiers whatsoever
(also, there are now _two_ ``OOSC Eiffels'': I haven't yet seen the
second edition of OOSC, but I imagine it will no longer be using Eiffel
but Eiffel 3 for examples).

  I personally regard the title of Betrand Meyer's book "Eiffel the
  language" as a bit of a misrepresentation: for the vast changes
  between Eiffel and Eiffel 3 reflect some negative experience with
  Eiffel (and Eiffel 2), and blurring the distinction between Eiffel 3
  and Eiffel seems a way to sweep such past problems under the carpet,
  as if there were a continuity that is not quite there. There are vast
  differences between the various ``C++''s too, and I cringe when people
  speak of ``C++'' as if it were one and not at least four successive
  rather different languages, but none imply regrets such as those
  evident in the evolution from Eiffel to Eiffel 3.

I personally try to use typographical conventions to indicate use of the
specific vs. the generic term; for example Eiffel denotes the language
called "Eiffel", and ``Eiffel'' means any of the languages called
"Eiffel", "Eiffel 2", "Eiffel 3".

I am especially keen on using such a convention when discussing
``Smalltalk'', in part because there are so many different and often
incompatible languages whose name includes the word "Smalltalk", and
also because there is _no_ language called "Smalltalk" (while there is
one called "Eiffel"), as the original ``Smalltalk''s were all, wisely,
tagged with names of the form "Smalltalk-<year>".

donh> they are graciously informed that some things have changed since
donh> then. :)

Perhaps a better assumption would be to use the language's own full name
(ALGOL 60 instead of Algol), or use some typographical convention to
indicate ``fuzzy'' names, or simply to assume that the version, if
missing is the one, if any, for which the phrase in which it appears
makes sense; for exmaple something like "C++ does not have multiple
inheritance" should be taken to refer to "C++ 1.0".

Re: The disturbing myth of Eiffel portability

[Don Harrison]

Piercarlo Grandi writes:

:>>> "donh" == Don Harrison <donh@syd.csa.com.au> writes:
:
:donh> I think you'll find that when people refer to languages without
:donh> stating which version, they are typically referring to the current
:donh> incarnation.
:
:The incarnation of the language or that of the language's name? For it
:is often the case that the same name is used to label rather different
:languages, not more or less minor revisions of the same language.

The language. Yes, this only applies to languages with a single line of
descendants (eg. Ada, Eiffel). Where the evolutionary tree branches, it
only makes sense to speak of specific variants. 

[As an aside, it's tempting to suggest that the quality of an original 
language is inversely proportional to the number of branches from it (not 
necessarily with the same name) but this is overly simplistic. A single 
evolutionary path may indicate that the original was so good that there were 
few 'improvements' that could be made or it may have been that the language 
definition was tightly controlled].

:The obvious example is ``Algol'', where ALGOL 60 and ALGOL 68 are rather
:different. 

Yes, that's why "Algol 68" is used for ALGOL 68 and "Algol" is used to mean
ALGOL 60.

:But the difficulty exists even when the current language is a
:a greatly expanded superset of the previous language, but the name has
:not been changed. Both cases are somewhat common, and the Eiffel-Eiffel
:3 distinction is one of many example.
:
:Therefore the assumption above involves considerable difficulties.

Indeed.

:When one says ``C++'', which version of C++ is implied? The one with or
:without namespaces? The one with or without exception handling? And when
:one says ``Smalltalk''? And which version of ``FORTRAN'' is current? And
:nnwhen someone writes ``Ada is an OO language'', one should understand
:that phrase wrt Ada [83] or Ada 95? 

In the case of "Ada", they mean Ada95.

:What about Pascal? Pascal (either
:1st or 2nd edition), or ISO Pascal? Is ``C++'' the current ``C'', as it
:incldues the latter as a subset?

Hasn't C evolved separately? This is the real issue, IMO. BTW, I thought 
C++ *wasn't* a superset of C - at least, that's what Wiener & Pinson says.

:For Eiffel at least the situation is clear; there are three languages,
:Eiffel (which was never called Eiffel 1 AFAIK, even if occasionally the
:name is used, even by myself), Eiffel 2 and Eiffel 3.

Few languages would have a version 1 as their designers probably thought
at the time they had created something perfect. :)   

:Eiffel and Eiffel 2 are fairly similar, so not much is lost by using the
:same name for both; but Eiffel 3 is so different from Eiffel (being a
:greatly "expanded" :-) superset, and the things in the superset being so
:dramatically different in philosophy) that I think using the name of the
:latter to indicate the former is a bit of a strain (similarly for
:Sather, for which the version number is even more essential, as it has
:been for quite a while a research language, and has undergone even more
:frequent evolution).

While you may be strictly correct in using the term "Eiffel" for the original
language, everyone else uses it to mean Eiffel 3. Words in natural languages 
change their meanings over time, typically through popular misuse. Language 
names are no different in this regard, so "Eiffel" today means Eiffel 3 whereas 
in 1985, it meant the original Eiffel. Using "Eiffel" to mean the original 
Eiffel (as defined in OOSC?) will only cause confusion, IMO.

:Consider as an analogy the label ``Modula'': yes, Modula, Modula 2 and
:Modula 3 are somewhat similar languages, but Modula 3 is rather
:different from the other two (which are not compatible either way); what
:should one understand when one writes ``Modula''? The current
:``version''? Which one?

Modula is usually understood to mean the original language called "Modula" 
and its derivatives are specifically named.

:donh> They will typically only mention a specific version if
:donh> distinguishing between them (usually to update their
:donh> knowledge).
:
:But Eiffel has got no version number -- Eiffel 2 and Eiffel 3 have got
:it. You may have not noticed that in my article I was careful to Use
:Eiffel where I meant Eiffel, and Eiffel 3 where I meant Eiffel 3, as
:evident in the contrast in two consecutive paragraphs:

Yes, you expressed yourself with admirable precision. :)

:donh> In the case of "Eiffel", they usually mean Eiffel 3.
:
:This may well be the case, but it creates confusion...

Only if you use the term archaically. :)

:donh> If they mean OOSC Eiffel,
:
:But there is no such thing as OOSC Eiffel: what is described in OOSC is
:the language called "Eiffel", period, with no qualifiers whatsoever

That may well be. However, everyone will know what you are talking about but ...

:there are now _two_ ``OOSC Eiffels'': I haven't yet seen the
:second edition of OOSC, but I imagine it will no longer be using Eiffel
:but Eiffel 3 for examples).

No doubt, but I expect the term "Eiffel" will be used to mean the current 
version of the language.

:  I personally regard the title of Betrand Meyer's book "Eiffel the
:  language" as a bit of a misrepresentation: for the vast changes
:  between Eiffel and Eiffel 3 reflect some negative experience with
:  Eiffel (and Eiffel 2), and blurring the distinction between Eiffel 3
:  and Eiffel seems a way to sweep such past problems under the carpet,
:  as if there were a continuity that is not quite there. 

Well, there is continuity in that the term "Eiffel" has been used the whole
time to indicate the current version of a progressively improving language.

:There are vast
:  differences between the various ``C++''s too, and I cringe when people
:  speak of ``C++'' as if it were one and not at least four successive
:  rather different languages, but none imply regrets such as those
:  evident in the evolution from Eiffel to Eiffel 3.

Sadly, we humans are less than perfect. :)

:I personally try to use typographical conventions to indicate use of the
:specific vs. the generic term; for example Eiffel denotes the language
:called "Eiffel", and ``Eiffel'' means any of the languages called
:"Eiffel", "Eiffel 2", "Eiffel 3".

Okay, we'll know what you mean.

:I am especially keen on using such a convention when discussing
:``Smalltalk'', in part because there are so many different and often
:incompatible languages whose name includes the word "Smalltalk", and
:also because there is _no_ language called "Smalltalk" (while there is
:one called "Eiffel"), as the original ``Smalltalk''s were all, wisely,
:tagged with names of the form "Smalltalk-<year>".

Yes, that was helpful.

:donh> they are graciously informed that some things have changed since
:donh> then. :)
:
:Perhaps a better assumption would be to use the language's own full name
:(ALGOL 60 instead of Algol), 

Yes, that would help.

:or use some typographical convention to
:indicate ``fuzzy'' names, or simply to assume that the version, if
:missing is the one, if any, for which the phrase in which it appears
:makes sense; for exmaple something like "C++ does not have multiple
:inheritance" should be taken to refer to "C++ 1.0".

Yes, reading in context is always beneficial.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: The disturbing myth of Eiffel portability

[Robert Dewar]

Regarding names of languages:

"When one says ``C++'', which version of C++ is implied? The one with or
without namespaces? The one with or without exception handling? And when
one says ``Smalltalk''? And which version of ``FORTRAN'' is current? And
nnwhen someone writes ``Ada is an OO language'', one should understand
that phrase wrt Ada [83] or Ada 95? What about Pascal? Pascal (either
1st or 2nd edition), or ISO Pascal? And the differences between C and
ANSI C, and the (unnamed) C-like subset of ``C++''?"

  These are not similar questions. Some specific comments:

    The name of the language is Algol 68, not Algol, so unless you casually
    use incorrect names no confusion arises. I never heard anyone in the
    Algol community use the phrase Algol to refer to Algol 68.

    Fortran (thus spelled, it has not been spelled in caps for 20 years!)
    is a standardized language, so presumably one is referring to the latest
    standard of that name when using the term, but still in any serious
    discussion, it should be qualified, especially since more than one
    standard is current (an unusual situation).

    Ada unqualified always refers to Ada 95. The official name of the 
    language is Ada, and the new standard for Ada obsoletes the old one.
    When in doubt, it is certainly fine, but unnecessary to say Ada 95,
    but it is ALWAYS necessary to say Ada 83 when referring to the
    obsolete version of the language.

    Pascal is trickier because of the nasty situation that the ISO and
    ANSI sdtandards are not in sync.

    As for non-standardized languages like Eiffel and C++, the situation
    is indeed trickier. I would say it is reasonable to assume that C++
    unadorned refers to the draft international standard. Certainly at
    this stage C++ does include namespaces and exception handling. Some
    implementations may not, but we are talking languages here!

Re: The disturbing myth of Eiffel portability

[Robert Dewar]

"Perhaps a better assumption would be to use the language's own full name"


That's not quite a clear rule, for example the language name is
SNOBOL 4 and Algol 68, but the language name is Fortran or Ada 
(the common terms like Fortran 77 and Ada 95 are informal terms,
not the official names of the languages).

Of course with non-standard languages like Eiffel or Modula, it is not
so clear from a formaol point of view what the name of the language is
since one cannot use the standard to dictate this.

Re: The disturbing myth of Eiffel portability

[Piercarlo Grandi]

>>> "donh" == Don Harrison <donh@syd.csa.com.au> writes:

  donh> I think you'll find that when people refer to languages without
  donh> stating which version, they are typically referring to the
  donh> current incarnation.

piercarl> The incarnation of the language or that of the language's
piercarl> name? For it is often the case that the same name is used to
piercarl> label rather different languages, not more or less minor
piercarl> revisions of the same language.

donh> The language. Yes, this only applies to languages with a single
donh> line of descendants (eg. Ada, Eiffel). Where the evolutionary tree
donh> branches, it only makes sense to speak of specific variants. [
donh> ... ]

Ahhh, but it's not as simple as that. In part because it's often not
clear what is the ``current'' incarnation of a language; in part
because, and that was my main point w.r.t. to the Eiffel-Eiffel 3
distinction, to me Eiffel 3 is logically a branch on the Eiffel
descendancy tree, not a linear descendant, and that continuining to call
it ``Eiffel'' is thus somewhat misleading, for it implies a degree of
continuity that is not there.

  In the case of Eiffel-Eiffel 3 this device probably has been
  detrimental to the popularity language: for Eiffel and Eiffel 2 have
  earned here and there a reputation as somewhat impractical, because of
  limitations in the language; these *have been corrected* (somewhat
  ilegantly but rather effectively) in Eiffel 3. Giving an impression of
  continuity, instead of the underlining the very large differences in
  Eiffel 3, seems a good way to make those users that were skeptical
  about Eiffel/Eiffel 2 not give Eiffel 3 a second look.

  Conversely with ``C++'': having a name that closely recalls that of
  its predecessor, that predecessor being ``C'', can only help. In fact
  the various successive versions of ``C++'' are about as different from
  each other as ``C++'' is from ``C'': but indicating them all with the
  same generic label again helps, for they have all been popular and
  well accepted, and hiding, rather than underlining, their differences
  is a better strategy therefore than claiming loudly ``new improved'',
  as IMNHO should be done with Eiffel 3.

piercarl> [ ... more whining about the ambiguous meaning of language
piercarl> names without version number and rather different languages
piercarl> being distinguished rather misleadingly just by a version
piercarl> number, and whether ... ]

[ ... ]

piercarl> Is ``C++'' the current ``C'', as it incldues the latter as a
piercarl> subset?

donh> Hasn't C evolved separately? This is the real issue, IMO. BTW, I
donh> thought C++ *wasn't* a superset of C

Ahhhh, now this is amusing. Note that while you write "C++" and "C" as
they were well defined terms (and you did w the I wrote ``C'', not "C", for the
definiton of the latter term is precisely what the difficulty is
about. ``C++'' has always included a ``C'' subset, by design, to the
point that ANSI C has been based in large part on this ``C'' rather than
on ``K&R C''.

The situation is rather subtle here. At the very least there are
_several_ popular ``C'' languages out there, ignoring the very early
ones: the one that came with UNIX edition 6 (the one without 'enum's and
with the lax rule about 'struct' member names), the one that came with
UNIX edition 7 (the one with 'enum's and 'void' etc.) and documented in
K&R 1st edition, ANSI C (the one documented in K&R 2nd ed.), and various
versions of ``C++''.

Now, let's just call C (K&R 1st ed.), ANSI C (K&R 2nd ed.) and C++
(C++ARM) for convenience.

C++ includes both C and ANSI C as closely as possible; indeed Bjarne
Stroustrup quite correctly insists in his book on C++ evolution that
including some fairly narrowly defined sort of ``C'' as a subset of
``C++'' was important:

TDEC++> C compatibility was the first major controversial issue we had
TDEC++> to face. After some occasionally heated debate, it was decided
TDEC++> that 100% C/C++ compatibility wasn't an option. Neither was
TDEC++> significantly decreasing C compatibility. C++ is a separate
TDEC++> language and not a strict superset of ANSI C and can't be
TDEC++> changed to be such a superset without seriously weakening the
TDEC++> guarantees provided by the C++ type system -- and without
TDEC++> breaking millions of lines of C++ code. Similarly, any
TDEC++> significant decrease of C compatibility would break code,
TDEC++> complicate the creation and maintenance of mixed C and C++
TDEC++> systems, and complicate a transition from C to C++.

This means in practice extreme compatibility with other ``C''s to the
point that as he writes elsewhere in the same book the examples in K&R
2nd ed. were developed/checked using a C++ compiler:

TDEC++> This principle has lately been knows as "As close as possible to
TDEC++> C -- but not closer" after the title of a paper written by
TDEC++> Andrew Koenig and me. One measure of the success of this policy
TDEC++> is that every exmaple in K&R2 is written in the C subset of
TDEC++> C++. Cfront was the compiler used for the primary testing of the
TDEC++> K&R2 code samples.

As things stand, both ANSI C and C++ can well claim to be the current
``C'': both are extended versions of classic (K&R 1st ed., arguably) C;
it's also arguable (and I would agree) that C++ is a "better C" than
ANSI C, and perhaps by now it is also more popular. Indeed I suspect
that right now or perhaps soon most users will adopt the same point of
view as that reported by Bjarne Stroustrup above and come to use ``C''
as ``C++ lite''.

Not everywhere; another interesting remark is:

TDEC++> In addition to the many formal constraints on a standards
TDEC++> committee, there is an informal and practical one: Many
TDEC++> standards are simply ignored by their intended users. For
TDEC++> example, the Pascal and Pascal2 standards are almost completely
TDEC++> forgotten. For most Pascal programmers, ``Pascal'' means
TDEC++> Borland's greately extended Pascal dialect. The language defined
TDEC++> by the Pascal standard didn't provide features users considered
TDEC++> essential and the Pascal2 standard didn't appear until a
TDEC++> different informal ``industry standard'' had established
TDEC++> itself. Another cautionary observation is that on UNIX most work
TDEC++> is still done in K&R C; ANSI C is struggling in that
TDEC++> community. The reasons seems to be that some users don't see the
TDEC++> technical benefits of ANSI/ISO C compared to K&R C outweighing
TDEC++> the short term costs of a transition.

donh> - at least, that's what Wiener & Pinson says.

Correctly from a strict point of view: if only because the presence of
extra reserved words in C++ makes some valid ``C'' programs invalid in
``C++''. But as illustrated above, it's rather more subtle than that.

Re: The disturbing myth of Eiffel portability

[Graham C. Hughes]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

>OK, but here are only two examples, which kind of proves my point. Of these,

I'm going out on a wing here, but do Crays use IEEE?  Crays have a long
and established tradition of going their own separate ways on many things
(_Computer Organization and Design_ by Patterson and Hennessy mentions
the ... amusing ability of a Cray to generate a floating-point overflow
when computing z/x if x is very small but not zero).  And nobody's going
to claim you don't use Crays for serious work.

If Java fails to work on Crays, it makes my day ;)

Graham
-- 
Graham Hughes <ghughes@cs.ucsb.edu>
``I think it would be a good idea.'' -- Mahatma Ghandi, when asked what he
                                        thought of Western civilization
finger for PGP public key.

Re: The disturbing myth of Eiffel portability

[Robert Dewar]

Graham asks

"I'm going out on a wing here, but do Crays use IEEE?  Crays have a long
and established tradition of going their own separate ways on many things
(_Computer Organization and Design_ by Patterson and Hennessy mentions
the ... amusing ability of a Cray to generate a floating-point overflow
when computing z/x if x is very small but not zero).  And nobody's going
to claim you don't use Crays for serious work.

If Java fails to work on Crays, it makes my day ;)"

The old style vector machine Crays (to which P&H refers) definitely are
NOT IEEE, or even close, and as per my previous message use reciprocal
hardware for division, meaning that division results can be off by one bit.
Implementing Java efficiently on those machines, which are now largely
obsolete, is out of the question.

Newer Crays are multiprocessors using at the moment Alpha's, although
considering the ownership, one might expect them to shift to MIPS chips
in the future. But in either case, we are talking about chips that are
subtly IEEE incompatible, as per my previous message.

P.S. for another source of amusing war stories on bogus floating-point
implementations, and an easy introduction to IEEE arithmetic aimed at
software folks rather than hardware folks, see chapter 5 of my book
on Microprocessors (Microprocessors: A Programmer's View, McGraw Hill,
1990, Dewar & Smosna).

Re: The disturbing myth of Eiffel portability

[Jon S Anthony]

In article <yf3zpzzvcw4.fsf@sabi.demon.co.uk> piercarl@sabi.demon.co.uk (Piercarlo Grandi) writes:

> donh> The language. Yes, this only applies to languages with a single
> donh> line of descendants (eg. Ada, Eiffel). Where the evolutionary tree
> donh> branches, it only makes sense to speak of specific variants. [
> donh> ... ]
> 
> Ahhh, but it's not as simple as that. In part because it's often not
> clear what is the ``current'' incarnation of a language; in part
> because, and that was my main point w.r.t. to the Eiffel-Eiffel 3
> distinction, to me Eiffel 3 is logically a branch on the Eiffel
> descendancy tree, not a linear descendant, and that continuining to call
> it ``Eiffel'' is thus somewhat misleading, for it implies a degree of
> continuity that is not there.

I would tend to disagree with this.  Probably in general, but
certainly for the two particular cases mentioned.  There is really no
issue or problem or whatever concerning what is the current
"incarnation" of either Ada or Eiffel.  For Ada, ISO/IEC 8652:1995
explicitly refers to: "Information Technology -- Programming Languages
-- Ada".  Pretty clear.  For Eiffel, the direct analogue is "Eiffel
The Language", which does not say "Eiffel-3 The Language" or whatever.
In both cases there is a _great_ deal of continuity there and I don't
see anything particularly misleading about the unqualified names.


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: The disturbing myth of Eiffel portability

[Piercarlo Grandi]

>>> "jsa" == Jon S Anthony <jsa@alexandria> writes:

piercarl> Ahhh, but it's not as simple as that. In part because it's
piercarl> often not clear what is the ``current'' incarnation of a
piercarl> language; in part because, and that was my main point
piercarl> w.r.t. to the Eiffel-Eiffel 3 distinction, to me Eiffel 3 is
piercarl> logically a branch on the Eiffel descendancy tree, not a
piercarl> linear descendant, and that continuining to call it ``Eiffel''
piercarl> is thus somewhat misleading, for it implies a degree of
piercarl> continuity that is not there.

jsa> I would tend to disagree with this.  Probably in general, but
jsa> certainly for the two particular cases mentioned.  There is really
jsa> no issue or problem or whatever concerning what is the current
jsa> "incarnation" of either Ada or Eiffel.

Again, the issue, is whether we are discussing ``Ada'' the language or
"Ada" the label. Your argument here is that the name is used nowadays
officially to indicate the more recent language of that name:

jsa> For Ada, ISO/IEC 8652:1995 explicitly refers to: "Information
jsa> Technology -- Programming Languages -- Ada".  Pretty clear.  For
jsa> Eiffel, the direct analogue is "Eiffel The Language", which does
jsa> not say "Eiffel-3 The Language" or whatever.

Too bad. To me that is both misleading and counterproductive, as argued
later, for I don't think that in either case there is a indeed:

jsa> In both cases there is a _great_ deal of continuity there and I
jsa> don't see anything particularly misleading about the unqualified
jsa> names.

Well, to me Ada 83 and Ada 95 are very different languages, rather more
so than F77 vs. F90, for example; to a large extent one could argue that
the differences between Ada 83 and Ada 95 are almost as large as those
between ``C'' and ``C++'', and surely way more fundamental than those
between say C++ 1.x (nee` C84 apparently) and C++ 3.x; roughly
equivalent to those between Modula 2 and Modula 3, perhaps.

In particular I see a great deal of PR value in underlining that Ada 95
is a rather different beast in scope and possibilities from Ada 83, in
part because Ada 83 has not been a roaring success, and it has suffered
a reputation as a not-quite OO language. After all Ada 95 *is* a greatly
improved language, and that should be stressed, both for accuracy and
for expediency.

For the Eiffel-Eiffel 3 case it is some vital details of the language,
rather than its scope as in the ``Ada'' case, that have changed greatly,
turning it into a far more industrial strength tool than before. I have
seen some rather strong complaint in this newsgroup in recent times
about the limitations of Eiffel/Eiffel 2, and these limitations _have_
been repaired in Eiffel 3 (at the cost of a considerable loss in
eelgance, but then that seems patently irrelevant for market success).

Again, given that Eiffel 3 is greatly improved over Eiffel/Eiffel 2,
which did suffer from some important limitations, underlining the
difference seems expedient, not just correct.

Yes, Ada 95 includes (mostly) as a subset Ada 83; and Eiffel 3 includes
(mostly) as a subset Eiffel; but the extensions (OO, low level
facilities) are rather more essential than incidental, in both cases.

Thus in summary in both cases the programming styles and/or the scope of
applications possible in Ada 95 and Eiffel 3 wrt to their predecessors
are so vastly different that pretending there is substantial continuity
as in using identically the same name as the previous version is not
just misleading but counterproductive.

Let's be facetious: a bit as if the Ford Mondeo had been instead named
the Edsel 92 (or whatever year it was introduced), or perhaps as if the
32 bit Microsoft OS had been called Windows NT to underline a tenuous
link with Windows 3 :-).

Re: The disturbing myth of Eiffel portability

[Brian R. Hanson]

Robert Dewar wrote:

> The old style vector machine Crays (to which P&H refers) definitely are
> NOT IEEE, or even close, and as per my previous message use reciprocal
> hardware for division, meaning that division results can be off by one bit.
> Implementing Java efficiently on those machines, which are now largely
> obsolete, is out of the question.
> 
> Newer Crays are multiprocessors using at the moment Alpha's, although
> considering the ownership, one might expect them to shift to MIPS chips
> in the future. But in either case, we are talking about chips that are
> subtly IEEE incompatible, as per my previous message.

The machines refered to in the previous paragraph are the Massively
Parallel
machines but it is also true that the latest top of the line cray vector 
machines now do IEEE floating point.

-- Brian Hanson
-- brh@cray.com

Re: The disturbing myth of Eiffel portability

[Robert Dewar]

Brian Hanson says

"The machines refered to in the previous paragraph are the Massively
Parallel
machines but it is also true that the latest top of the line cray vector
machines now do IEEE floating point."

Are you sure, I thought they used Alphas, and from a practical point of view,
Alphas are not 100% IEEE compliant.

Re: The disturbing myth of Eiffel portability

[Brian R. Hanson]

Robert Dewar wrote:
> "The machines refered to in the previous paragraph are the Massively
> Parallel
> machines but it is also true that the latest top of the line cray vector
> machines now do IEEE floating point."
> 
> Are you sure, I thought they used Alphas, and from a practical point of view,
> Alphas are not 100% IEEE compliant.

The T3E line is an Massively Parallel computer (MPP) - it uses up to
4096 alpha
processors for a single machine.

The T90 line is is a Parallel Vector it does not use alpha but is a
genuine
descendent of the original Cray 1.  Cray 1 -> Cray XMP -> Cray YMP ->
Cray C90 ->
Cray T90.  It comes in two variants - standard cray floating point and
IEEE
floating point.  I do not know if it is 100% IEEE compliant.

-- Brian Hanson
-- brh@cray.com