The Ada Scalar, Vector, Matrix and Tensor arithmetic library?

The Ada Scalar, Vector, Matrix and Tensor arithmetic library?

[E. Robert Tisdale]

Is anyone interested in helping to design (and implement)
an Ada language binding
for scalar, vector, matrix and tensor arithmetic
and object oriented numerical computing like

The C++ Scalar, Vector, Matrix and Tensor class library

	http://www.netwood.net/~edwin/svmt/


E. Robert Tisdale <edwin@netwood.net>

Re: The Ada Scalar, Vector, Matrix and Tensor arithmetic library?

[David Starner]

On 4 Dec 1999 20:32:24 GMT, David Starner <dvdeug@x8b4e53cd.dhcp.okstate.edu> wrote:
>An Ada binding is inappropriate. Stuff like this is usually written in 
>inline generics in languages like C++ & Ada for high speed 
Let's try that sentence again. "Matrix libraries are usually written in
the language they are intended to be used in to take advantage of
inline generics that give it decent speed. (This is only true for languages
that have good inline generics, like C++ and Ada.)"

-- 
David Starner - dstarner98@aasaa.ofe.org
I see no trend at all, except toward women playing mean and ugly 
sociopaths who are good at killing and who enjoy dark powers. Maybe 
it's just my friends?
	-- Dr. Kromm, on who plays what type of character in RPGs

Re: The Ada Scalar, Vector, Matrix and Tensor arithmetic library?

[David Starner]

On Sat, 04 Dec 1999 19:57:41 +0000, E. Robert Tisdale <edwin@netwood.net> wrote:
>Is anyone interested in helping to design (and implement)
>an Ada language binding
>for scalar, vector, matrix and tensor arithmetic
>and object oriented numerical computing like
>
>The C++ Scalar, Vector, Matrix and Tensor class library
>
>	http://www.netwood.net/~edwin/svmt/

An Ada binding is inappropriate. Stuff like this is usually written in 
inline generics in languages like C++ & Ada for high speed 
(which is necessary for the types of program that use matrices and 
vectors.) If you want to do OO bindings to a numerical computing
library, use the Fortran BLAS/LAPACK as your underlying library 
(it's been tweaked for speed for years) and do the OO in Ada.

Alternately, Mat Webb's library has some matrix manipulation in 
it, and I'm sure there's other libraries out there that can
already handle this in Ada.
-- 
David Starner - dstarner98@aasaa.ofe.org
I see no trend at all, except toward women playing mean and ugly 
sociopaths who are good at killing and who enjoy dark powers. Maybe 
it's just my friends?
	-- Dr. Kromm, on who plays what type of character in RPGs

Re: The Ada Scalar, Vector, Matrix and Tensor arithmetic library?

[E. Robert Tisdale]

David Starner wrote:

> On 4 Dec 1999 20:32:24 GMT,
> David Starner <dvdeug@x8b4e53cd.dhcp.okstate.edu> wrote:
> > An Ada binding is inappropriate.
> > Stuff like this is usually written in inline generics
> > in languages like C++ & Ada for high speed
>
> Let's try that sentence again.
> "Matrix libraries are usually written in
> the language they are intended to be used in
> to take advantage of inline generics that give it decent speed.
> (This is only true for languages that have good inline generics,
>  like C++ and Ada.)"

No one actually cares how matrix libraries are implemented
except that the implementation should be optimized
appropriately for the target platform and problem domain.
Only the Application Programmer's Interface (API)
is really important.
If the application programmer uses a standard API,
it should be possible to port the application to any platform
where there is a library that supports the standard API.
There are other good reasons for a standard API.
The application programmer may use one version of the library
to compile quickly and do extensive run time error checking
to aid in debugging then recompile with another version of the library
which compiles more slowly but does a better job of optimizing
and omits all of the run time error checking
once all testing and debugging is completed.

All of the existing vector and matrix libraries in Ada
are older implementations.
None of the have all the capabilities of SVMT
or other modern libraries based upon vector, matrix
and tensor "views" of a one dimensional array of numbers.
The API for each existing Ada library was designed
around a particular implementation which precludes
any other implementation.

E. Robert Tisdale <edwin@netwood.net>

Re: The Ada Scalar, Vector, Matrix and Tensor arithmetic library?

[David Starner]

On Sat, 04 Dec 1999 21:59:13 +0000, E. Robert Tisdale <edwin@netwood.net> wrote:
>David Starner wrote:
>
>> On 4 Dec 1999 20:32:24 GMT,
>> David Starner <dvdeug@x8b4e53cd.dhcp.okstate.edu> wrote:
>> > An Ada binding is inappropriate.
>> > Stuff like this is usually written in inline generics
>> > in languages like C++ & Ada for high speed
>>
>> Let's try that sentence again.
>> "Matrix libraries are usually written in
>> the language they are intended to be used in
>> to take advantage of inline generics that give it decent speed.
>> (This is only true for languages that have good inline generics,
>>  like C++ and Ada.)"
>
>No one actually cares how matrix libraries are implemented
>except that the implementation should be optimized
>appropriately for the target platform and problem domain.
Sure, but the way of doing that for Ada is most likely not
a wrapper around a C++ library, it's more likely to be use
inline generics.

>Only the Application Programmer's Interface (API)
>is really important.
>If the application programmer uses a standard API,
>it should be possible to port the application to any platform
>where there is a library that supports the standard API.
But there is no standard API for this in Ada. So why worry about
it? One way to get a standard API is to create a library that
implements a clean API, and get it used to the point that anything
trying to replace it will have to implement its API.

>The API for each existing Ada library was designed
>around a particular implementation which precludes
>any other implementation.
Huh? Your statement makes me start thinking about the
multitude of standards that originally were a particular
implementation - UNIX, C, Fortran, recently OpenSSH and
OpenPGP, etc. There is no reason you can't take any API
and design a implementation around it.

-- 
David Starner - dstarner98@aasaa.ofe.org
I see no trend at all, except toward women playing mean and ugly 
sociopaths who are good at killing and who enjoy dark powers. Maybe 
it's just my friends?
	-- Dr. Kromm, on who plays what type of character in RPGs

Re: The Ada Scalar, Vector, Matrix and Tensor arithmetic library?

[E. Robert Tisdale]

David Starner wrote:

> On Sat, 04 Dec 1999 21:59:13 +0000,
> E. Robert Tisdale <edwin@netwood.net> wrote:
>
> > No one actually cares how matrix libraries are implemented
> > except that the implementation should be optimized
> > appropriately for the target platform and problem domain.
>
> Sure, but the way of doing that for Ada
> is most likely not a wrapper around a C++ library.
> It's more likely to be use inline generics.

Who said anything about a C++ library?
The library might be implemented in Ada, Fortran, C, assembler
or any combination of programming languages.
All Ada applications programmers care about
is what they should write to access the library.

> > Only the Application Programmer's Interface (API)
> > is really important.
> > If the application programmer uses a standard API,
> > it should be possible to port the application to any platform
> > where there is a library that supports the standard API.
>
> But there is no standard API for this in Ada.
> So why worry about it?
> One way to get a standard API
> is to create a library that implements a clean API,
> and get it used to the point that anything trying to replace it
> will have to implement its API.

But it is a very bad way to get a standard API.
It's better to design an API that liberates library developers
to implement the library as they see fit.

> > The API for each existing Ada library was designed
> > around a particular implementation which precludes
> > any other implementation.
>
> Huh? Your statement makes me start thinking
> about the multitude of standards
> that originally were a particular implementation -
> UNIX, C, Fortran, recently OpenSSH and OpenPGP, etc.
> There is no reason you can't take any API
> and design a implementation around it.

Sure you can if you have unlimited resources
and don't care about performance.
But most programmers who write numerical applications
expect their code to run as fast and efficiently as possible.

E. Robert Tisdale <edwin@netwood.net>

Re: The Ada Scalar, Vector, Matrix and Tensor arithmetic library?

[David Starner]

On Sun, 05 Dec 1999 03:59:16 +0000, E. Robert Tisdale <edwin@netwood.net> wrote:
>David Starner wrote:
>
>> On Sat, 04 Dec 1999 21:59:13 +0000,
>> E. Robert Tisdale <edwin@netwood.net> wrote:
>>
>> > No one actually cares how matrix libraries are implemented
>> > except that the implementation should be optimized
>> > appropriately for the target platform and problem domain.
>>
>> Sure, but the way of doing that for Ada
>> is most likely not a wrapper around a C++ library.
>> It's more likely to be use inline generics.
>
>Who said anything about a C++ library?
Your first message mentioned an Ada binding to a C++ library.

>The library might be implemented in Ada, Fortran, C, assembler
>or any combination of programming languages.
>All Ada applications programmers care about
>is what they should write to access the library.
No. I develop programs. I care about
* The license of the library I'm linking to
* The size of the program
* The number of libraries the users will need
* If the users will already have them
* The compilers users will need
* How portable it is

For example, I probably wouldn't use a multiple precision library 
written in Caml, that's 2/3 MB. Portability issues, the users would 
need OCaml, the size, etc. I would use libgmp, even if it was 
slower and the interface was much worse.

>But it is a very bad way to get a standard API.
>It's better to design an API that liberates library developers
>to implement the library as they see fit.

I disagree - it's better to design an API that lets programers
do what they need, and lets library developers make a efficent
implementation, even if they don't have much choice in how to
do it. For example, the C function memcpy has a decent interface,
but there is one way to implement it. I fail to see how changing
that would improve memcpy.

>> There is no reason you can't take any API
>> and design a implementation around it.
>
>Sure you can if you have unlimited resources
>and don't care about performance.
>But most programmers who write numerical applications
>expect their code to run as fast and efficiently as possible.

That's a non-sequitor. If an API for a numeric library is 
commonly used, it will be that for an efficent library. 
Hence, there will be a way to write to that API efficently.

-- 
David Starner - dstarner98@aasaa.ofe.org
I see no trend at all, except toward women playing mean and ugly 
sociopaths who are good at killing and who enjoy dark powers. Maybe 
it's just my friends?
	-- Dr. Kromm, on who plays what type of character in RPGs

Re: The Ada Scalar, Vector, Matrix and Tensor arithmetic library?

[David C. Hoos, Sr.]

David Starner <dvdeug@x8b4e53cd.dhcp.okstate.edu> wrote in message
news:82cors$9281@news.cis.okstate.edu...
> On Sun, 05 Dec 1999 03:59:16 +0000, E. Robert Tisdale <edwin@netwood.net>
wrote:
> >David Starner wrote:
> >
> >> On Sat, 04 Dec 1999 21:59:13 +0000,
> >> E. Robert Tisdale <edwin@netwood.net> wrote:
> >>
<snip>

> >But it is a very bad way to get a standard API.
> >It's better to design an API that liberates library developers
> >to implement the library as they see fit.
>
> I disagree - it's better to design an API that lets programers
> do what they need, and lets library developers make a efficent
> implementation, even if they don't have much choice in how to
> do it. For example, the C function memcpy has a decent interface,
> but there is one way to implement it. I fail to see how changing
> that would improve memcpy.
>
I would say that an API should liberate its clients' programmers
to concentrate on their client application, by presenting a good
abstraction of the functionality provided by the library.

If that makes the implementation more difficult, then so be it.
Even, performance, in my view should play a role secondary to
the presentation of a good abstraction, given that today the costs
of machine performance continue to plummet, while the cost of
software development, and the cost of correcting software errors
continue to escalate.

<snip>

Re: The Ada Scalar, Vector, Matrix and Tensor arithmetic library?

[Greg Martin]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 472 bytes --]

On 5 Dec 1999 15:37:58 GMT, "Pascal Obry" <pascal_obry@csi.com> wrote:

>
>
>Pascal Obry <pascal_obry@csi.com> a �crit dans l'article
><01bf3f36$43ebbd50$022a6282@dieppe>...
>> It cost less today to buy a new fastest machine than to jungle around
>                                                                           
>       ^^^^^^^^
>Please read juggle here.
>
Looking out at the snow on the ground, jungling around sounds pretty
good.
Regards,
Greg Martin.

Re: The Ada Scalar, Vector, Matrix and Tensor arithmetic library?

[E. Robert Tisdale]

David Starner wrote:

> I disagree -
> it's better to design an API that lets programers do what they need
> and lets library developers make a efficient implementation
> even if they don't have much choice in how to do it.
> For example, the C function memcpy has a decent interface,
> but there is one way to implement it.
> I fail to see how changing that would improve memcpy.

You are confused.
The memcpy function liberates library developers
to implement it as they see fit.  The result is undefined
if the source and destination memory areas overlap.
The application programmer is cautioned to use
the memmove function instead
if the source and destination might overlap.
The memmove function is safer
but requires unnecessary overhead
when the source and destination do not overlap.

E. Robert Tisdale <edwin@netwood.net>

Re: The Ada Scalar, Vector, Matrix and Tensor arithmetic library?

[E. Robert Tisdale]

Pascal Obry wrote:

> David C. Hoos, Sr. <david.c.hoos.sr@ada95.com>
> a �crit dans l'article <82dk7t$5ka$1@birch.prod.itd.earthlink.net>...
> > I would say that an API should liberate its clients' programmers
> > to concentrate on their client application, by presenting a good
> > abstraction of the functionality provided by the library.
> >
> > If that makes the implementation more difficult, then so be it.
> > Even, performance, in my view should play a role secondary to
> > the presentation of a good abstraction, given that today the costs
> > of machine performance continue to plummet, while the cost of
> > software development, and the cost of correcting software errors
> > continue to escalate.
>
> Right, I completely agree. We really want to make any abstraction
> usable for a *human* and just let the compiler do its job.
>
> It cost less today to buy a new fastest machine than to juggle around
> with the code in the hope to gain some percent of performance.
> It takes a lot of time to tune the code
> and it is often a real nightmare to maintain this kind code.

I agree.  But compiler technology isn't as good as it should be yet --
especially for Ada compilers.  It is easy to write numerical codes
that are thousands of times slower than they need to be.
Library developers should decide how much tuning and maintenance
they need to do to make their implementation competitive
with other implementations.
Competition benefits application programmers
only if library developers all support a standard API
and can substitute one implementation for another at any time.

E. Robert Tisdale <edwin@netwood.net>

Re: The Ada Scalar, Vector, Matrix and Tensor arithmetic library?

[David Starner]

On 5 Dec 1999 15:34:20 GMT, Pascal Obry <pascal_obry@csi.com> wrote:
>Right, I completly agree. We really want to make any abstraction
>usable for a *human* and just let the compiler do its job.
>
>It cost less today to buy a new fastest machine than to jungle around
>with the code in the hope to gain some percent of performance. It takes
>a lot of time to tune the code and it is often a real nightmare to maintain
>this kind code.

But in the aplications where vector and matrix libraries are used, this
isn't always true. Sometimes, you need to do a simulation once or twice,
because tomorrow's fastest machine and tomorrow's theories will call for
a whole new simulation with different simplifications. But every 5% you
shave off means a day or two in time saved each time it runs. 

No worries about maintainability, you already have the fastest machine/
your budgets gone for this year (with man power is already payed for), but
it would be nice not to have everything waiting on the program to finish.

-- 
David Starner - dstarner98@aasaa.ofe.org
I see no trend at all, except toward women playing mean and ugly 
sociopaths who are good at killing and who enjoy dark powers. Maybe 
it's just my friends?
	-- Dr. Kromm, on who plays what type of character in RPGs

Re: The Ada Scalar, Vector, Matrix and Tensor arithmetic library?

[David C. Hoos, Sr.]

David Starner <dvdeug@x8b4e53cd.dhcp.okstate.edu> wrote in message
news:82e6pv$79q1@news.cis.okstate.edu...
> On 5 Dec 1999 15:34:20 GMT, Pascal Obry <pascal_obry@csi.com> wrote:
> >Right, I completly agree. We really want to make any abstraction
> >usable for a *human* and just let the compiler do its job.
> >
> >It cost less today to buy a new fastest machine than to jungle around
> >with the code in the hope to gain some percent of performance. It takes
> >a lot of time to tune the code and it is often a real nightmare to
maintain
> >this kind code.
>
> But in the aplications where vector and matrix libraries are used, this
> isn't always true. Sometimes, you need to do a simulation once or twice,
> because tomorrow's fastest machine and tomorrow's theories will call for
> a whole new simulation with different simplifications. But every 5% you
> shave off means a day or two in time saved each time it runs.
<snip>
Yes... but how many runs do you have to make with that 5% faster program
to make up for one bad run because the API was obtuse and the programmer got
it wrong, as a result?

Re: The Ada Scalar, Vector, Matrix and Tensor arithmetic library?

[David Starner]

On Sun, 05 Dec 1999 17:38:01 +0000, E. Robert Tisdale <edwin@netwood.net> wrote:
>Competition benefits application programmers
>only if library developers all support a standard API
>and can substitute one implementation for another at any time.

I disagree. One of the reasons to choose one library over the other is
the API. The usual reason, in fact. Very rarely have I seen libraries
compete with the same API - slang/ncurses, motif/lesstif are the 
exceptions. So, it seems to me, the standard API kills competetion in
the library world. 

-- 
David Starner - dstarner98@aasaa.ofe.org
I see no trend at all, except toward women playing mean and ugly 
sociopaths who are good at killing and who enjoy dark powers. Maybe 
it's just my friends?
	-- Dr. Kromm, on who plays what type of character in RPGs

Re: The Ada Scalar, Vector, Matrix and Tensor arithmetic library?

[E. Robert Tisdale]

"David C. Hoos, Sr." wrote:

> Yes... but how many runs do you have to make
> with that 5% faster program to make up for one bad run
> because the API was obtuse
> and the programmer got it wrong, as a result?

It's easy to knock down a straw man.
It is much harder to design a standard API
for numerical libraries which limits overhead to 5%
and is both easy and safe to use.
It is much easier to design an API
which makes every implementation
a thousand times slower than it needs to be
and is so obtuse that there is almost no chance
that the application programmer can get it right.

E. Robert Tisdale <edwin@netwood.net>

Re: The Ada Scalar, Vector, Matrix and Tensor arithmetic library?

[E. Robert Tisdale]

David Starner wrote:

> On Sun, 05 Dec 1999 17:38:01 +0000,
> E. Robert Tisdale <edwin@netwood.net> wrote:
> > Competition benefits application programmers
> > only if library developers all support a standard API
> > and can substitute one implementation for another at any time.
>
> I disagree.
> One of the reasons to choose one library over the other is the API.
> The usual reason, in fact.
> Very rarely have I seen libraries compete with the same API -
> slang/ncurses, motif/lesstif are the exceptions.
> So, it seems to me,
> the standard API kills competition in the library world.

But, in fact, differences between APIs are arbitrary
and superficial for most vector and matrix libraries.
Most library developers could easily support a standard API
including a standard language binding for C++ and Ada.
A standard API doesn't preclude other APIs
or even other standard APIs.

Re: The Ada Scalar, Vector, Matrix and Tensor arithmetic library?

[David Starner]

On Mon, 06 Dec 1999 02:05:21 +0000, E. Robert Tisdale <edwin@netwood.net> wrote:
>Most library developers could easily support a standard API
>including a standard language binding for C++ and Ada.
They could. But there are two ways to get a standard API:
get everyone to use one API until it's a standard or get
a standards body to define a standard. Neither have been
done in this field for Ada. (Or for C, or for C++, for
that matter. Fortran, on the other hand, has LAPACK and BLAS,
which I understand are defacto standards.)

-- 
David Starner - dstarner98@aasaa.ofe.org
I see no trend at all, except toward women playing mean and ugly 
sociopaths who are good at killing and who enjoy dark powers. Maybe 
it's just my friends?
	-- Dr. Kromm, on who plays what type of character in RPGs

Re: The Ada Scalar, Vector, Matrix and Tensor arithmetic library?

[Robert A Duff]

"E. Robert Tisdale" <edwin@netwood.net> writes:

> You are confused.
> The memcpy function liberates library developers
>...

It's highly amusing to see folks singing the praises of memcpy and
memmove on comp.lang.ada.

- Bob

Re: The Ada Scalar, Vector, Matrix and Tensor arithmetic library?

[E. Robert Tisdale]

Robert A Duff wrote:

> "E. Robert Tisdale" <edwin@netwood.net> writes:
>
> > You are confused.
> > The memcpy function liberates library developers
>
> It's highly amusing to see folks singing the praises
> of memcpy and memmove on comp.lang.ada.

Praise?  I don't think so.
The memcpy function is far too dangerous
for Ada programmers to play with.

E. Robert Tisdale <edwin@netwood.net>

SIMD extensions in Ada :-(. Was: Re: The Ada Scalar, Vector, Matrix and Tensor arithmetic library?

[Vladimir Olensky]

David Starner wrote in message <82e6pv$79q1@news.cis.okstate.edu>...

>But in the aplications where vector and matrix libraries are used, this
>isn't always true. Sometimes, you need to do a simulation once or twice,
>because tomorrow's fastest machine and tomorrow's theories will call for
>a whole new simulation with different simplifications. But every 5% you
>shave off means a day or two in time saved each time it runs.


This is  just  those case when Ada compiler support for  IA32+ SIMD
extensions could drastically improve efficiency ( not only  in percents
but in times).

This topic was discussed recently but it seems that  it is not among
priority issues among Ada compiler implementators ;-(

Actually it is not too bad as one could implement that using assembler
which has all SIMD operations available for the particular chip.
Then that routines could be easily imported into Ada library package
that provides interface to them.


Regards,
Vladimir Olensky

Re: SIMD extensions in Ada :-(. Was: Re: The Ada Scalar, Vector, Matrix and Tensor arithmetic library?

[Gautier]

* What about MIMD that Ada95 can provide (e.g. GNAT) ?
I may be wrong, but MIMD can be much more efficient than
data parallelisation in SIMD.

A link about it... http://fedelma.astro.univie.ac.at/web/

* Another question is: could one day Ada compilers admit
that implementing

  A:= (others=> (others=> 0.0) );

by filling directly the matrix A with 0.0 is as safe as creating
a matrix in the stack, zeroing it, then copying it to A ...
Generally, when direct filling or copy is obiously safe,
it should be implemented as such. (IMHO)

-- 
Gautier

_____\\________________\_______\
http://members.xoom.com/gdemont/