comp.lang.ada
 help / color / mirror / Atom feed
From: FGD <presbeis@look.ca>
Subject: Re: Math Libraries (was Re: Ada2005)
Date: Sat, 22 Dec 2001 16:48:29 -0500
Date: 2001-12-22T16:48:29-05:00	[thread overview]
Message-ID: <3C24FFAD.4010002@look.ca> (raw)
In-Reply-To: 9vvtrf$iqq$1@nh.pace.co.uk

I'm not completely for extending Ada to include new math types. As I 
stressed earlier such extensions would generally be useless for most 
people. The only possible exception I can see is linear algebra...

Marin David Condic wrote:

> "FGD" <presbeis@look.ca> wrote in message news:3C236F94.7020101@look.ca...
> 
>>I agree that linear algebra types such as vector and matrix would be a
>>nice language extension. These would benefit the most from hardware
>>
> 
> I don't know that it needs to be a language extension. That starts asking
> for something that is harder to do than simply providing a package and I
> don't see an enormous amount of utility to it. Most Ada programmers would
> probably easily comprehend and work with a package that defined "+" and so
> on for a vector or matrix type so I think you could get the features (albeit
> maybe not quite as cleanly) without forcing the compiler writers to make the
> language itself more complex.


The reason why I mentionned it as a language extension is that the 
"matrix type" is simply not efficient when represented as an array of 
coefficients. Having a language defined matrix type acting on vector 
types leaved the compiler writers free to use whatever internal 
representation they like.

>>extensions such as SIMD, and having them within the language would
>>ensure that all target machines are exploited to their full potential.
>>
>>
> Obviously, it would be advantageous for a compiler writer to take advantage
> of any underlying hardware rather than rely strictly on Ada syntax to
> implement the type. The nice thing about implementing it as a package is
> that the body could be implementation dependent, but the spec could be
> portable. If you've got the hardware, implement it in assembler.


Of course, that's what we currently do---in Ada and all other 
general-purpose languages. But one of the main advantages of Ada is low 
maintenace cost. I, for one, write and maintain a lot of such packages 
but almost all of my maintenance work goes into code that looks like:

    procedure Whatever ...
    begin
        case Machine is
        when Alpha_EV4 =>
             Asm(....
        when X86_Pentium_3 =>
             Asm(....
        when others =>
             ....
        end case;
    end Whatever;

For example, when Intel released the Pentum 4, I spent weeks rewrite and 
test asm code for relatively basic little things. I still have months to 
go writing and testing new code for the Itanium chip... and then the 
AMD-64... Sigh! :-(

For such code, Ada doesn't present any more advantages than any other 
language. Of course, that only leaves the burden of asm maintenance to 
compiler writers. Still having a few non-elementary types such as matrix 
and vector would make my life a lot simpler sometimes.

>>I'm not too sure about stats. Basic stats can be handled with linear
>>algebra and elementary math. The problem is that it's not clear where to
>>stop. It's something to think about...
>>
>>
> I'm thinking that some packages to get you things like mean, variance,
> standard deviation, etc., from arrays of various numeric types would be
> enough - for now. :-) (I've got some packages that do this already - it
> really isn't that hard to implement.) Sure, you could imagine all kinds of
> wonerful sophistication that one might get from a true statistical package,
> but why push our luck? Settle for some nice, basic statistics that let
> people throw some analysis into their run-of-the-mill apps rather than shoot
> for something that would satisfy the full-blown statisticians. It would
> still be ahead of most other languages I'm aware of and wouldn't require
> some major revision to the language syntax or semantics.


There are already lots of stuff out there to satisfy "full-blown" 
statisticians and mathematicians. Ada has no business there. We should 
focus on stuff that is useful to a great deal of people. As far as I can 
tell, linear algebra with all of its applications is the only branch of 
math which is useful to a great deal of people. BTW mean, variance and 
standard deviation are all linear algebra except maybe for a few square 
roots here and there.

-- Frank




  parent reply	other threads:[~2001-12-22 21:48 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-12-11  9:33 Ada2005 Peter Hermann
2001-12-11 11:05 ` Ada2005 M. A. Alves
2001-12-11 11:55   ` Ada2005 Aaro Koskinen
2001-12-11 14:49     ` Ada2005 Wes Groleau
2001-12-11 14:58     ` Ada2005 Marin David Condic
2001-12-11 15:18       ` Ada2005 Ted Dennison
2001-12-12  8:37       ` Ada2005 Alfred Hilscher
2001-12-11 11:23 ` Ada2005 Martin Dowie
2001-12-11 11:54 ` Ada2005 Preben Randhol
2001-12-11 12:06 ` Ada2005 Larry Kilgallen
2001-12-11 14:39 ` Ada2005 Ted Dennison
2001-12-12  4:39   ` Ada2005 Jeffrey Carter
2001-12-13 18:39   ` Ada2005 Randy Brukardt
2001-12-12 11:29 ` Ada2005 Peter Hermann
2001-12-12 12:42   ` Ada2005 Larry Kilgallen
2001-12-12 12:51   ` Ada2005 Martin Dowie
2001-12-12 12:59   ` Ada2005 Carsten Freining
2001-12-12 14:40     ` Ada2005 Peter Hermann
2001-12-12 15:16       ` Ada2005 Ted Dennison
2001-12-12 15:37         ` Ada2005 Larry Kilgallen
2001-12-12 17:49           ` Ada2005 Ted Dennison
2001-12-12 18:02         ` Ada2005 tmoran
2001-12-12 18:17           ` Ada2005 Ted Dennison
2001-12-12 18:31             ` Ada2005 Sergey Koshcheyev
2001-12-12 19:08               ` Ada2005 Ted Dennison
2001-12-12 18:14         ` Ada2005 Mark Lundquist
2001-12-12 18:40           ` Ada2005 Ted Dennison
2001-12-12 19:12             ` Ada2005 Mark Lundquist
2001-12-12 19:41               ` Ada2005 Ted Dennison
2001-12-13 20:07         ` Ada2005 Ted Dennison
2001-12-14  4:40       ` Ada2005 Patrick Hohmeyer
2001-12-14  9:55         ` Ada2005 Lutz Donnerhacke
2001-12-14 10:36         ` Ada2005 Dmitry A. Kazakov
2001-12-17 18:40         ` Ada2005 Matthew Heaney
2001-12-12 18:04     ` Ada2005 Mark Lundquist
2001-12-12 21:25       ` Ada2005 Mark Lundquist
2001-12-13 18:40         ` Ada2005 Stephen Leake
2001-12-13 19:01           ` Ada2005 Mark Lundquist
2001-12-14 17:17             ` Ada2005 Stephen Leake
2001-12-13  9:11       ` Ada2005 Dmitry A. Kazakov
2001-12-17 17:50         ` Ada2005 Ray Blaak
2001-12-18 11:55           ` Ada2005 Dmitry A. Kazakov
2001-12-18 19:51             ` Ada2005 Ray Blaak
2001-12-19  8:34               ` Ada2005 Dmitry A. Kazakov
2001-12-19 13:30                 ` Ada2005 Mark Lundquist
2001-12-19 18:23                 ` Ada2005 Ray Blaak
2001-12-19 18:20           ` Ada2005 Mark Lundquist
2001-12-19 19:19             ` Ada2005 Ray Blaak
2001-12-20 14:17             ` Ada2005 Dmitry A. Kazakov
2001-12-20 11:24       ` Ada2005 Carsten Freining
2001-12-20 14:27         ` Ada2005 Mark Lundquist
2001-12-20 15:01         ` Ada2005 Matthew Woodcraft
2001-12-20 15:45         ` Ada2005 Mark Lundquist
2001-12-20 16:20           ` Ada2005 Mark Lundquist
2001-12-13 18:13     ` Ada2005 Georg Bauhaus
2001-12-20 16:34 ` Math Libraries (was Re: Ada2005) Marin David Condic
2001-12-20 20:14   ` FGD
2001-12-20 20:34     ` Marin David Condic
2001-12-21 17:21       ` FGD
2001-12-21 18:08         ` Marin David Condic
2001-12-21 19:40           ` tmoran
2001-12-21 19:45             ` Marin David Condic
2001-12-21 20:35             ` Dan Nagle
2001-12-21 20:31           ` Eric Merritt
2001-12-22 16:56           ` Math Update for Ada 2005 Steven Deller
2001-12-23 15:13             ` Robert Dewar
2001-12-23 22:43               ` Brian Rogoff
2001-12-22 21:48           ` FGD [this message]
2002-01-02 14:20         ` Math Libraries (was Re: Ada2005) Jacob Sparre Andersen
2001-12-20 23:20   ` Robert C. Leif, Ph.D.
2001-12-21 14:49     ` Marin David Condic
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox