NICE-ESG-Libs Digest Fri, 12 May 95 Volume 1 : Issue 219
Today's Topics:
Format of FTP-able documents
General comments on PELKS 7
NUMERIC, REAL, DOUBLE, INTEGER - first thoughts
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: Fri, 12 May 95 09:20:43 PDT
From: bertrand@vienna.eiffel.com (Bertrand Meyer)
Subject: Format of FTP-able documents
To: nice.lang@vienna.eiffel.com, nice.lib@vienna.eiffel.com
Copy to:
From: Bertrand Meyer
Mailer: BOOM
Dear Colleagues:
The submitted forms of both the Kernel Library and Language
draft standard proposals (please note the three qualifiers
``submitted'', ``draft'' and ``proposal'') are available through
FTP from our site, in FrameMaker 4 as well as PostScript formats.
(The PELKS is also available in ASCII.)
FrameMaker has announced a new version, 5.0, which seems
interesting; in particular it supports HTML. We haven't received
it yet but it seems that if it indeed works as advertized we
will probably want to switch to it soon. This would mean that
future versions of the documents would also be in the 5.0 format,
which (barring miracles) will probably not be readable under earlier
releases. The Postscript format should not be affected.
Is that a problem for those of you that have been using the
FrameMaker forms?
-- BM
Date: Fri, 12 May 1995 15:38:50 +0100 (BST)
From: S M Fisher
Subject: General comments on PELKS 7
To: NICE Library Committee
Hi,
1) The standard now (unlike the ADA standard) allows vendors to
provide more but not less. I would like to require vendors claiming
PELKS compatability to agreee to list in some form all that they
provide in their kernel which is not part of PELKS and to provide a
basic PELKS as well as their enhanced one. Users wanting portability
can use the basic PELKS and be sure that their code will port to
another vendor who supports PELKS.
2) The standard does not describe the interdependencies between
features and classes. For example the connections between copy, clone
and is_equal which cannot (I think) be addressed readily by pre and
postconditions. If a user inherits and redefines something in PELKS
which he will certainly have to do for any container classes he builds
to ensure sensible behaviour of copy/clone/is_equal then he has to be
aware of the implemenation of that feature. Typically one has to
modify copy and is_equal because clone calls copy (maybe via twin) -
but this is not guaranteed. (This has already been mentioned in
NICE-ESG_libs Digest 211, 212 and 213). Another example, also from class
GENERAL are the output features. The Tower version of `print' is
simply `io.putstring(some.out)' so if a user redefines `out' then
`print' follows automatically. This problem exists in principle for
all features which make use of other features (except for the few
which are frozen). What is the solution? I can suggest a few:
a) Make the code the standard - this is probably not practical for
those classes which are recognised by the compiler itself and for
those calling out to vendor specific C routines. It would however
obviously eliminate the annoying differences between the
libraries if they were identical (apart from the very lowest
level) and reduce work.
b) Tell people that to use PELKS in a way which guarantees
portability they may not redefine features except for some cases
which will be listed. Sufficient cases must of course be listed
for this to be useful. This means a lot of care defining
dependencies.
c) Tell people that to use PELKS in a way which guarantees
portability they may not redefine features at all - in which case
they may as well all be frozen. This is simple but is too
restrictive.
I prefer a or b
3) I would like to see the changes which have been agreed so far to
PELKS 7 to be incorporated in a new document ... PELKS 8. Maybe it
already exists somewhere. The version number should be prominent on
the front cover.
4) Christine has just asked for comments on NUMERIC, INTEGER, REAL and
DOUBLE. Could we not do ARRAY and STRING at the same time. There is
little coupling between the first four classes and these two so it
should allow us to speed up a bit.
Steve Fisher
Date: Fri, 12 May 1995 17:46:36 +0100 (BST)
From: S M Fisher
Subject: NUMERIC, REAL, DOUBLE, INTEGER - first thoughts
To: NICE Library Committee
NUMERIC
I prefer to define the infix "^" as taking only a integer argument
This is then always defined for exponent > 0
a ^ 4 = a * a * a * a.
a ^ zero = one
a ^ -n = one / a ^ n
This will then work properly for square matrices for example. I think
that the current SiG and Tower libraries which only accept positive
integers are unnecessarily restrictive.
REAL / DOUBLE
the precise format of the string returned by the `out' feature needs
defining, otherwise test results vary from compiler to compiler. This
includes field width, number of significant figures, when to switch to
`scientific notation', whether or not to precede the exponent with 0s
e.g. 1.23E01 or 1.23E1
We need all the common functions to avoid the necessity for single and
double precision maths classes. This will allow a class to work easily
with mixed double and single precision without having to do a lot of
renaming.
I would like to see features cos, sin, tan, sinh, cosh, tanh, asin,
acos, atan, asinh, acosh and atanh, ln, log (or log and log10) and pi
However I do NOT want to see rndm.
`pow' or `power' is needed to take a real/double argument and return a
real/double
This just leaves atan2 which is a nuisance because as a function it has
two arguments. a := y.atan2(x) is a possibility.
REAL / DOUBLE / INTEGER
I suggest instead of features such as truncated_to_integer we use
to_integer, to_real and to_double. In some cases this is not as explicit,
but it means that when we have an INTEGER or a DOUBLE and we want a REAL
then to_real will do the job irrespective of whether or not there will be
some loss of precision.
Regards,
Steve Fisher
 |
