Interfacing Ada with C
in [ADA]
|
Prev: Dhrystone
Next: Learning Ada
From: Ada novice on 6 Aug 2010 14:15 Hi guys, thanks for raising these subtle points. It's very informative to read the discussions. YC
From: Simon Wright on 6 Aug 2010 16:26 "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 6 Aug 2010 20:46 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 7 Aug 2010 00:07 "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 7 Aug 2010 03:59
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 |