From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00 autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,8c424d8135e68278 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-12-20 13:01:18 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!psinet-eu-nl!psiuk-p4!uknet!psiuk-p3!uknet!psiuk-n!news.pace.co.uk!nh.pace.co.uk!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada Subject: Re: Math Libraries (was Re: Ada2005) Date: Thu, 20 Dec 2001 15:34:33 -0500 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: <9vti0r$jrj$1@nh.pace.co.uk> References: <9v4jsj$bd1$1@infosun2.rus.uni-stuttgart.de> <9vt3vi$dmd$1@nh.pace.co.uk> <3C22468C.30901@look.ca> NNTP-Posting-Host: dhcp-200-133.miami.pace.co.uk X-Trace: nh.pace.co.uk 1008880475 20339 136.170.200.133 (20 Dec 2001 20:34:35 GMT) X-Complaints-To: newsmaster@news.cam.pace.co.uk NNTP-Posting-Date: 20 Dec 2001 20:34:35 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Xref: archiver1.google.com comp.lang.ada:18173 Date: 2001-12-20T20:34:35+00:00 List-Id: I could see that objection, but it still seems that it would be nice to have something like this available for other numeric types. Personally, I'd be willing to live with the possibility that for a number of particularly small fixed or decimal types, the computations might generate Constraint_Error so long as for the ones that were big enough I got a result. Its up to the user to define types of sufficient size and precision to have something like Sqrt make sense for it. Clearly, the original package was intended to line up nicely with hardware or OS supplied libraries and I see no reason that it should change. I'm thinking along the lines of extention in other packages that might have to do their computation strictly in the Ada language. It might not even need to be under Ada.Numerics. I might not object if the underlying implementation did conversions to some floating point type and converted the result back to whatever it had to. Sure, I could do it myself, but having things like Log and Sqrt available for fixed and decimal types seems almost as fundamental as having "+" and "-". Its pretty basic to most math that is just a bit more complex than balancing my checkbook. (Maybe even there as well - you need Sqrt to compute interest, don't you? :-) You're probably right about it being considered and rejected for Ada95. Maybe its time to reconsider? Other extensions I think would be useful here would be vector and matrix math. That shows up often enough to be generally useful and there are already a number of packages available to do it. So it could be a case of standardizing on an existing library - if I dare bring that up! :-) I'd also vote for statistics - partly because I think it would get used a lot and partly because I just like statistics. (A friend once described it this way: Statistics is to Math what The National Enquirer is to Journalism. :-) Other languages provide some math capabilities, but generally don't go this far. That would make Ada even more useful in the math realm than it already is. And I don't think its a stretch too far from the beaten path to cover vectors, matricese and statistics. Those areas are used often enough that it wouldn't seem "strange" to support them. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "FGD" wrote in message news:3C22468C.30901@look.ca... > > > There is a range issue here, most of these functions will map out of the > range of the original type or will have unsatisfactory precision within > the original type--such extensions are generally useless. Converting to > float and using the float result is usually the best solution. For most > of the remaining cases converting back from float to the original type > is the most efficient way to compute the desired result. For the very > few remaining cases, the programer should be able to supply efficient > algorithms. > > I think all of this was considered when designing Ada95. >