Prev: Dhrystone
Next: Learning Ada
From: Ada novice on
Hi guys, thanks for raising these subtle points. It's very informative
to read the discussions.

YC
From: Simon Wright on
"Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> writes:

> On Fri, 06 Aug 2010 17:49:14 +0100, Simon Wright wrote:
>
>> "Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> writes:
>>
>>> On Fri, 06 Aug 2010 10:04:24 +0200, Jacob Sparre Andersen wrote:
>>>
>>>> Ada novice <posts(a)gmx.us> wrote:
>>>>
>>>>> Can we change the subtype to Long_Long_Float? This will be of 18
>>>>> precision digits [...]
>>>>
>>>> That's not guaranteed. If you want 18 digits, you should declare the
>>>> type (My_Float?) as:
>>>>
>>>> type My_Float is digits 18;
>>>
>>> Further, practically you should never use subtype in the form
>>>
>>> subtype My_Float is Long_Float;
>>>
>>> except for special cases like:
>>>
>>> subtype Non_IEEE_Float is Long_Float range Long_Float'Range;
>>>
>>> or
>>>
>>> subtype Non_Negative_Float is Long_Float range 0.0..Long_Float'Last;
>>
>> Depends what you mean by "practically".
>>
>> The thought process was, "I'm going to be writing a set of demo cases
>> which should work for arbitrary floating-point types, I'll call the type
>> My_Float. Shall I use type My_Float is new ... or subtype My_Float is
>> ...? Doesn't really matter, go for subtype."
>
> I am not sure what do you mean. If the code meant to be used with any type,
> then it should be generic (My_Float is digits <>). If the code is to work
> with some yet unknown type (to be determined later) then it should be
> My_Float is new Long_Float. That would protect me from mixing Long_Float
> and My_Float.

You're clearly right for serious code (in this case, for serious unit
tests which I may well make generic). But this wasn't a serious test, it
was an exploratory hack. Perhaps I shouldn't have let it out into the
wild without a bit more polishing.

I do feel that writing a demo like this one as a set of generics
instantiated for various floating types would probably have obscured the
point.
From: John B. Matthews on
In article <m2pqxvbi8l.fsf(a)pushface.org>,
Simon Wright <simon(a)pushface.org> wrote:

[...]
> >> The thought process was, "I'm going to be writing a set of demo
> >> cases which should work for arbitrary floating-point types, I'll
> >> call the type My_Float. Shall I use type My_Float is new ... or
> >> subtype My_Float is ...? Doesn't really matter, go for subtype."
> >
> > I am not sure what do you mean. If the code meant to be used with
> > any type, then it should be generic (My_Float is digits <>). If the
> > code is to work with some yet unknown type (to be determined later)
> > then it should be My_Float is new Long_Float. That would protect me
> > from mixing Long_Float and My_Float.
>
> You're clearly right for serious code (in this case, for serious unit
> tests which I may well make generic). But this wasn't a serious test,
> it was an exploratory hack. Perhaps I shouldn't have let it out into
> the wild without a bit more polishing.

No! Release Early, Release Often:

<http://catb.org/esr/writings/homesteading/cathedral-bazaar/ar01s04.html>

> I do feel that writing a demo like this one as a set of generics
> instantiated for various floating types would probably have obscured
> the point.

--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>
From: Randy Brukardt on
"Ada novice" <posts(a)gmx.us> wrote in message
news:aca699e9-90a9-4fba-b424-b75d249e260e(a)z10g2000yqb.googlegroups.com...
>On Aug 6, 11:49 am, Peter Hermann <h...(a)h.de> wrote:
>...
>> 14 will run everywhere,
>> 18 not.
>>
>> ph
>
>Is this because all (modern) platforms/architectures can easily
>provide for 14 but not for 18? Most likely, all 32-bit Intel machines
>are able to provide for 18. Am I right?

Intel architectures might, but that doesn't mean that Ada compilers will.
Most of the early Ada compilers (for Ada 83) didn't support anything beyond
digits 15. Janus/Ada still doesn't. The original reason was that I couldn't
be sure that the operations on the 80-bit type met the Ada 83 requirements
for numeric precision.

It's OK to ignore those requirements in Ada 95 (unless you are running in
"strict" mode), but I don't think most compilers actually have separate
strict and relaxed modes. In any case, it might very well be OK to support
the 80-bit type, I've just never tried to figure out whether it is. (The
majority of ACATS tests only apply to Float, Short_Float, and Long_Float, so
those tests wouldn't apply to the 80-bit type anyway, so passing the ACATS
doesn't prove anything either way.)

Besides, there is no analog to those types on any other processor that we
ever considered porting Janus/Ada to; we wanted code to be reasonably
portable between implementations.

Obviously, GNAT has made a different choice, but it's not one I would count
on being available elsewhere.

Randy.


YC


From: Dmitry A. Kazakov on
On Fri, 06 Aug 2010 20:46:37 -0400, John B. Matthews wrote:

> In article <m2pqxvbi8l.fsf(a)pushface.org>,
> Simon Wright <simon(a)pushface.org> wrote:
>
>> Perhaps I shouldn't have let it out into
>> the wild without a bit more polishing.
>
> No! Release Early, Release Often:
>
> <http://catb.org/esr/writings/homesteading/cathedral-bazaar/ar01s04.html>

Yes!

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
First  |  Prev  |  Next  |  Last
Pages: 13 14 15 16 17 18 19 20 21 22 23 24
Prev: Dhrystone
Next: Learning Ada