Re: Math Libraries (was Re: Ada2005)

[FGD <presbeis@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 
extensions such as SIMD, and having them within the language would 
ensure that all target machines are exploited to their full potential.

I would like to be able to write

    type Domain_Space is vector (1 .. D) of Float;
    type Range_Space  is vector (1 .. R) of Float;
    type Transform is matrix (Domain_Space, Range_Space);

    F, G : Transform;
    U, V : Domain_Space;
    X, Y : Range_Space;
    S : Float;

    ...................

    X := F * U;
    Y := (F + G) * (U + S * V) - X;

where all operators are defined within the language, all checks made at 
compile time. Note that the semantics become pretty complicated here for 
language defined objects---some might object to that. It's very unusual 
to have predefined mixed-type operations. I think vector and matrix 
should be fairly distinct from array. It would be very inconvenient if 
any array of floats came with predefined +, -, *, etc.

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...

-- Frank

Marin David Condic wrote:

> 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" <presbeis@look.ca> 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.
>>
>>
> 
> 
>