Re: SI Units Solicitation - Upgrade from comments

Re: SI Units Solicitation - Upgrade from comments

[Brian Rogoff]

On Fri, 22 Aug 1997, William A Whitaker wrote:

> Give me a better name.  Float is out since it is pre-empted by Ada.  We
> are simulating ATLAS whlch uses the term "DECIMAL", which I believe is
> also pre-empted, and further is a poor discription for a binary floating
> point number.

Flt, Float_Type, Float15, F_Type, ....

-- Brian

SI Units Solicitation - Upgrade from comments

[William A Whitaker]

"... a decent respect to the opinions of mankind requires that 
they should declare the causes which impel them ..."

This is an interim report on the responses to the Solicitation
of comments on a SI Units proposal for IEEE P1446, Ada-Based 
Test Program Development.  I wish to thank those who provided comments. 
Addition/further/new comments are invited.


The revised proposal is given, with links to code, in 

http://www.erols.com/whitaker/iss_418.htm
                                         

A full accounting of comments is given in 

http://www.erols.com/whitaker/si_cmts.txt



Two general statements: 

First, the example given was abstracted, with very little modification,
from code used in IEEE P1446, which left a few footprints (e.g., there
was a subtype Number which was left over and has now been removed).

For the P1446 standard, it is important that it be concrete and allow
only
the use of the numeric type Real, defined elsewhere.  As a general
Ada facility, it is proper that it be generic.  A rephrasing of the
example as a generic looks a bit strange, but is given in

http://www.erols.com/whitaker/si_gen.txt

As an Ada facility, it is probably important to group the operations
with the Unit type definition for derivability (deriving is not
encouraged
in P1446, but then "possible" is not "required").  This has been done, 
requiring the additional "use type SI.Unit" in code, although 
I was rather hoping to reduce the number of with/use in code.


Second, the driving force of the proposal was to find a method of 
units checking in Ada that would be acceptable/comfortable to 
ordinary engineers.  If it was not fairly invisible, it would never 
be used.

The gimmick of naming the unit subtypes and the conversion functions
the same is considered important to that goal and drives the 
packaging.  Direct literals are not possible, this was the closest I
came.
The solution of packaging everything together and calling
the conversions To_Meter, To_Second, ... was used 5 years ago and
was rejected by users at that time.

Other changes include:

Spellcheck has been run on the text.

subtype Dimensionless has been redesignated Null_Unit.  There is
possible
confusion surrounding the word "dimension".

Function Nth_Root - a unique need for Unit.

Other observations:

On reflection, many 'Attributes would have no meaning for Unit.
Meter'First could only be an artificial flag.  Unit'First has no meaning 
at all.

Unit_Power could be restricted to 127, or less in some cases.  This was
done 
in 1226.  But the only real advantage would be (following an early
suggestion
by Leif) to encode the whole set of Unit_Powers in a single 32-bit
integer,
thereby allowing a smaller structure and literals for the Power.
Is there any interest in this modification?

Run-time costs are probably minimal in this day, and can be cut off
by using the non-checking version.  But there is one situation
in which this is not true, large compute/memory limited physics 
calculations with large unit-ed arrays.  Straightforward implementation
would make an array of Meter an array of type Meter.  For efficiency,
one could rather have a Meter_Array, a unit-ed type which has as 
Value an array of Real (and the appropriate operations).

Re: SI Units Solicitation - Upgrade from comments

[Robert Dewar]

<<For the P1446 standard, it is important that it be concrete and allow
only
the use of the numeric type Real, defined elsewhere.>>


I guess this is really a complaint at the P1446 standard (which I do not
have a copy of), but I really dislike the use of the term Real, as opposed
to Float, in programming languages. It just serves to feed confusion of the
kind that has been so evident in the separate thread on guidelines for use
of floating-point arithmetic.

Re: SI Units Solicitation - Upgrade from comments

[Brian Rogoff]

On 21 Aug 1997, Robert Dewar wrote:
> I guess this is really a complaint at the P1446 standard (which I do not
> have a copy of), but I really dislike the use of the term Real, as opposed
> to Float, in programming languages. It just serves to feed confusion of the
> kind that has been so evident in the separate thread on guidelines for use
> of floating-point arithmetic.

I emphatically agree that "Real" should not be used as the name for the 
floating point type of a language.

Even the term "Real" itself for real numbers is suspicious. All numbers are 
really imaginary, unless you believe Kronecker in which case integers
aren't. :-) :-)

-- Brian

Re: SI Units Solicitation - Upgrade from comments

[William A Whitaker]

Robert Dewar wrote:
> 
> <<For the P1446 standard, it is important that it be concrete and allow
> only
> the use of the numeric type Real, defined elsewhere.>>
> 
> I guess this is really a complaint at the P1446 standard (which I do not
> have a copy of), but I really dislike the use of the term Real, as opposed
> to Float, in programming languages. It just serves to feed confusion of the
> kind that has been so evident in the separate thread on guidelines for use
> of floating-point arithmetic.

For this applications standard, the user is restricted to a single
15-digit floating type.  It must be a subtype of the appropriate
implementation type (rather than "is digits 15") since this application
must smoothly interact with other applications.  The standard then
expends/derives/employs the type.  

The standard calls that type Real.  It cannot be called Float.  In most
compilers it is probably a subtype of Long_Float, but you cannot count
on that.  I would be delighted to consider another term, if it can be
generally agreed upon.  (I do not believe that the users would be happy
with a multisyballic name, like AdaTPD_Float, or even Float_15).  So far
the only one that has won acceptance (besides Float) is "Real".

Whitaker

Re: SI Units Solicitation - Upgrade from comments

[William A Whitaker]

Give me a better name.  Float is out since it is pre-empted by Ada.  We
are simulating ATLAS whlch uses the term "DECIMAL", which I believe is
also pre-empted, and further is a poor discription for a binary floating
point number.

I cannot use the term "INTEGER" either.  This has been repaced by
"NUMBER" and is used to count the number of cycles or pulses, designate
the Nth harmonic, etc.

Remember AdaTPD (P1446) is not a language itself.  It is a thick
applications binding to ATLAS and code using AdaTPD packages will be
freely mixed with pure Ada. 

Whitaker


Brian Rogoff wrote:
> 
> On 21 Aug 1997, Robert Dewar wrote:
> > I guess this is really a complaint at the P1446 standard (which I do not
> > have a copy of), but I really dislike the use of the term Real, as opposed
> > to Float, in programming languages. It just serves to feed confusion of the
> > kind that has been so evident in the separate thread on guidelines for use
> > of floating-point arithmetic.
> 
> I emphatically agree that "Real" should not be used as the name for the
> floating point type of a language.
> 
> Even the term "Real" itself for real numbers is suspicious. All numbers are
> really imaginary, unless you believe Kronecker in which case integers
> aren't. :-) :-)
> 
> -- Brian

Re: SI Units Solicitation - Upgrade from comments

[Michael F Brenner]

William A Whitaker asked:
> Give me a better name.  Float is out since it is pre-empted by Ada.  We
> are simulating ATLAS whlch uses the term "DECIMAL", which I believe is
> also pre-empted, and further is a poor discription for a binary floating
> point number.

It is hard to come up with a better set of names than those used
originally in the design of the DOD-1 language (later renamed Ada).
Those two types were approximates and exacts, reflecting their
true nature, use, and limitations. Use of these names includes many
grammatical features which help avoid mistakes, such as: (1) they
are both plural noun phrases representing sets of nouns so they
fit into English-language sentences, (2) they clearly identify when
things are being counted with precision log N versus when things
are being measured approximately cut off at an arbitrary precision,
(3) they clearly distinguish between algorithms whose complexity
changes when you are permitted to use approximate numbers or to
expect approximate answers, (4) they are not trite rehashes 
of FORTRAN or Pascal words, (5) they represent some of the most
important thoughts that went into the original design of Ada, 
and (6) they give an acceptable alternative to using predefined
types.

Re: SI Units Solicitation - Upgrade from comments

[Robert Dewar]

Bill wrote

<<Give me a better name.  Float is out since it is pre-empted by Ada.  We
are simulating ATLAS whlch uses the term "DECIMAL", which I believe is
also pre-empted, and further is a poor discription for a binary floating
point number.>>

No, the type name Decimal is nowhere used in the Ada 95 RM, not even in
Interfaces.COBOL, so it is certainly not "preempted". I agree however,
that it is a truly horrible choice of names for binary floating-point.

Re: SI Units Solicitation - Upgrade from comments

[Robert Dewar]

Bill wrote

<<The standard calls that type Real.  It cannot be called Float.  In most
compilers it is probably a subtype of Long_Float, but you cannot count
on that.  I would be delighted to consider another term, if it can be
generally agreed upon.  (I do not believe that the users would be happy
with a multisyballic name, like AdaTPD_Float, or even Float_15).  So far
the only one that has won acceptance (besides Float) is "Real".>>

I am confused, if the standard specifies the name, then how can we
consider another term at all?

Actually it seeems to me that the package should in any case be generic,
rather than relying on a particular predefined floating-point type. Packages
that introduce specified types of this kind do not work well together!

Re: SI Units Solicitation - Upgrade from comments

[Brian Rogoff]

On Fri, 22 Aug 1997, Shmuel (Seymour J.) Metz wrote:
> > Brian Rogoff wrote:
> > > Even the term "Real" itself for real numbers is suspicious. All numbers are
> > > really imaginary, unless you believe Kronecker in which case integers
> > > aren't. :-) :-)
> > >
> > > -- Brian
> 
> Brian overlloks the fact that our nomenclature stems in part from
> Mathematics,

No, it is more likely that Shmuel overlooked those two hidden smileys 
at the end of Brian's post. I am quite aware of the relevance of
mathematics to the world Shmuel refers to as "real", and of the fact 
that words in mathematics (group, ring, field, category) have different 
meanings in English. 

If Shmuel were aware of modern mathematics, he might know that all of "real
analysis" could  be expressed in terms of other number systems (the
hyperreals of nonstandard analysis or Conway's "surreal numbers", probably 
more) which include infinitesimals. Appropriating the term real for 
one limited set can be seen as an example of numeric bigotry :-). 

> If you believe that complex numbers are irrelevant to the real world,
> talk to an 
> EE or to someone that has to deal with Quantum Mechanics.

I really have no idea how you can make so many assumptions about what I
know or believe. Perhaps you shouldn't assume that everyone who posts is
uneducated in mathematics.

-- Brian

Re: SI Units Solicitation - Upgrade from comments

[Shmuel (Seymour J.) Metz]

Brian Rogoff wrote:
> 
> If Shmuel were aware of modern mathematics, he might know that all of "real
> analysis" could  be expressed in terms of other number systems (the
> hyperreals of nonstandard analysis or Conway's "surreal numbers", probably
> more) which include infinitesimals.

If Brian were aware of modern Mathematics, then he would understand the
difference
between an axiom system and a model of an axiom system. 

> Appropriating the term real for one limited set can be seen as an example of > numeric bigotry :-).

Frankly, I dislike the nomenclature, but it is centuries too late to
change it. I just object to mudying the waters by having to types of
real numbers and labelling only of them as REAL. That will make for real
fun nomenclature if you have to deal with complex data: do you want to
call Gaussian integers "COMPLEX INTEGER" and complex floating point
"COMPLEX REAL"?
 
> I really have no idea how you can make so many assumptions about what I
> know or believe. Perhaps you shouldn't assume that everyone who posts is
> uneducated in mathematics.

You made similar assumptions in your message, with less justification.
Why do assume that I haven't heard of Robinson?

> -- Brian

-- 

                        Shmuel (Seymour J.) Metz
                        Senior Software SE

The values in from and reply-to are for the benefit of spammers:
reply to domain eds.com, user msustys1.smetz or to domain gsg.eds.com,
user smetz. Do not reply to spamtrap@library.lspace.org

Re: SI Units Solicitation - Upgrade from comments

[W. Wesley Groleau x4923]

Forgive me if I'm repeating someone else.  I had a News hiccup 
and lost everything in this thread except the original message.

Regarding a scientist's suggestion on packing the exponents into
eight bits each:  You could define exponents as

   type xxx is range -127 .. 127;

allowing the compiler to choose whether to use 8 bits or more
(and indirectly, the user that chooses the compiler).

In the generic version, you could even allow the user to specify
the type of the exponent.

-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be
                    wwgrol AT pseserv3.fw.hac.com

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------