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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham 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 12:07:23 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!cyclone.bc.net!newsfeed.direct.ca!look.ca!brick.direct.ca!brie.direct.ca.POSTED!not-for-mail Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed From: FGD MIME-Version: 1.0 Message-ID: <3C22468C.30901@look.ca> NNTP-Posting-Date: Thu, 20 Dec 2001 12:04:16 PST NNTP-Posting-Host: 209.148.71.135 Newsgroups: comp.lang.ada Organization: Look Communications - http://www.look.ca References: <9v4jsj$bd1$1@infosun2.rus.uni-stuttgart.de> <9vt3vi$dmd$1@nh.pace.co.uk> Subject: Re: Math Libraries (was Re: Ada2005) User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us X-Complaints-To: abuse@look.ca X-Trace: brie.direct.ca 1008878656 209.148.71.135 (Thu, 20 Dec 2001 12:04:16 PST) Date: Thu, 20 Dec 2001 15:14:04 -0500 Xref: archiver1.google.com comp.lang.ada:18164 Date: 2001-12-20T15:14:04-05:00 List-Id: Marin David Condic wrote: > We have in Ada a useful package: Ada.Numerics.Generic_Elementary_Functions > that works fine for floating point types. > > Is there any reason not to include in Ada200x similar packages for generic > fixed and decimal types? It seems we ought to be able to compute logarithms, > square roots, etc. for numeric types other than floating point types, eh? 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. > Would there be any reason not to expand the math functions beyond what is > already there? Math is pretty cheap to implement when compared to some of > the other suggested extensions to the language and it would definitely be > attractive to a given audience that might currently still be relying on > Fortran. (See also the discussion elsewhere about standard libraries...) > > What math functions (or math branches) would be most desirable to add to the > language by way of some packages under Ada.Numerics? One thing I like about Ada.Numerics is that, with the exception of random numbers, it contains only functions which are commonly implemented directly in hardware or nearly so. I like this RIS approach---and I would like future extensions to adhere to this philosophy. (Although the use of the word "Elementary" could be used to distinguish extensions which do.) Should the numerics annex be extended to include more complex functions and types. I would like to see more discrete arithmetic types. I would love to see, in order of preference: (1) Binary Galois fields. (2) Crypto-secure random numbers. (3) More modular operations. (e.g. multiplicative inverses & efficient exponentiation.) (4) Built-in multiprecision types. These have in common that highly efficient but hopelessly target dependent algorithms are known for computing these. Most of the stuff I do now is discrete, so I really have no idea what would be best for continuous types. But I guess that operations that could take advantage of SIMD extensions of some processors would be useful. Well anything that would likely speed up a Fourier Transform would be a bonus. For example like Fortran, built-in point to point multiplication of arrays would be good. On the abstraction side, the fact that arrays and functions are addressed with the same syntax is a fun thing in Ada. Perhaps this could be taken further? -- Frank