Re: C++ wrapper

Re: C++ wrapper

[E. Robert Tisdale]

Brian Gough wrote:

> If I understand correctly,
> an API is not generally subject to copyright.
> There are certainly cloned proprietary libraries on the market,
> e.g. Motif versus Lesstif.

Rogue Wave owns the Math.h++ API.
No one else participates in the design of their proprietary API.
There is nothing you can do if Rogue Wave decides to change their API
(to frustrate library developers who attempt to clone it for example.)

Who owns the GSL API?
Are GSL application programmers permitted
to participate in the design of the GSL API?
This is a real problem for application programmers
who are trying to decide whether or not it is safe
to use the GSL API.
What happens if you decide to change the GSL API
so that their applications, which depend upon it, break?
I don't think you are promising to cover the cost
of rewriting all of their application source code
to accommodate the changes that you make to the GSL API.

Re: C++ wrapper

[Brian Gough]

I believe these questions were covered in the earlier thread, "Who
owns GSL?" http://sources.redhat.com/ml/gsl-discuss/2000/msg00502.html

Anyone is free to post specific API suggestions to the list for the
developers to consider.  We certainly read and consider everything on
the list, but we have our own opinions too so it would be a question
of persuading us that something is worthwhile in the context of GSL
for the amount of work involved.

regards
Brian Gough

E. Robert Tisdale writes:
 > Who owns the GSL API?
 > Are GSL application programmers permitted
 > to participate in the design of the GSL API?
 > This is a real problem for application programmers
 > who are trying to decide whether or not it is safe
 > to use the GSL API.
 > What happens if you decide to change the GSL API
 > so that their applications, which depend upon it, break?
 > I don't think you are promising to cover the cost
 > of rewriting all of their application source code
 > to accommodate the changes that you make to the GSL API.
 > 

Re: C++ wrapper

[E. Robert Tisdale]

Brian Gough wrote:

> I believe these questions were covered in the earlier thread,
> "Who owns GSL?"
> 
> 	http://sources.redhat.com/ml/gsl-discuss/2000/msg00502.html
> 
> Anyone is free to post specific API suggestions to the list
> for the developers to consider.
> We certainly read and consider everything on the list
> but we have our own opinions too
> so it would be a question of persuading us that
> something is worthwhile in the context of GSL
> for the amount of work involved.

It appears that the GSL API is owned
by the GSL developers/maintainers.
Apparently, this means that the GSL API
belongs to Gerard Jungman and Brian Gough.
The GSL API is their property.
Application programmers may offer suggestions
but only the owners decide
what will be included and what will not be included.
Application programmers can't really participate
in the design of the GSL API
any more than they can participate
in the design of the Rogue Wave API.
Any application programmer who uses the GSL API
is vulnerable to the whims of the owners.
If they decide to change the API
so that it breaks applications which depend upon it,
there is nothing that application programmers can do
short of assuming maintenance of the GSL themselves.

The GSL is, therefore, a practical option
only for programmers who write short-lived disposable
application programs.

Re: C++ wrapper

[Brian Gough]

E. Robert Tisdale writes:
 > This API is the property of Rogue Wave.

If I understand correctly an API is not generally subject to
copyright.  There are certainly cloned proprietary libraries on the
market, e.g. Motif vs Lesstif.

 > > 
 > >	http://www.network-theory.clara.co.uk/gslrw.tar.gz
 > 
 > I get garbage when I click on this URL.
 > 

The file contents are ok, but the mime type is set to text. It should
be ok if anyone uses 'Save link as ...'

Re: C++ wrapper

[E. Robert Tisdale]

Ivo Kwee wrote:

> GSL is a great library
> but math-intensive code in C++ is rather unreadable
> using the standard C-namings.
> 
> I am thinking to start coding up a simple (?) C++ wrapper
> providing operator overloading etc.
> Why has no one started this yet?

The GSL library developers have not yet finalized the API.
If you implement a C++ wrapper on top of the GSL API,
you should expect to revise you wrappers to accommodate
GSL revisions at least until version 1.0 is released.

> Anyway, I would be OK to code something up
> but I need some ready established interface specification. 
> 
> Earlier, SVMT has been mentioned.
> Is this the "best" one to go for?

Yes.
Mostly because it is the ONLY proposal for a standard API
besides the one proposed by the BLAS Technical Forum

http://netlib.uow.edu.au/utk/papers/blast-forum.old/blast-forum.html

> Anyone knows "better" or more "accepted" standards?
> I was thinking myself
> if MatLab-like conventions would be better
> but they are not really OO style.  Suggestions?

There are serious problems with the existing Matlab API.
Matlab supports just one type: a double precision matrix.
This simplifies the interface and is convenient
for developing short application programs
but it creates problems when you try to implement
larger more complicated application programs.
The MathWorks may eventually extent the Matlab language
to provide support single and extended precision floating-point
as well as fixed-point (integral) types
and vector and third order and higher order tensor objects
as well as matrix objects so that numerical programmers
can write fast, efficient reliable applications in Matlab.

Re: C++ wrapper

[E. Robert Tisdale]

Gerard Jungman wrote:

> I've been thinking alot about native C++ implementations
> for some of the GSL functionality,
> so I am interested in what people want to do.  Anyway,
> I see that this is a fairly straightforward wrapper project,
> so maybe they thought it would not be sufficiently whiz-bang
> to bring up in this forum.  But still,
> any sort of general discussion about C++ is welcome here.

It is hard to write numerical application programs in ANSI C
clearly and concisely so that they are easy for other programmers
to read, understand and maintain.  An application program
written in ANSI C will, on average, be THREE TIMES LARGER
than the same application program written in C++ --
any way you choose to measure program size.

> I am especially interested in new object-oriented designs.
> As an example, consider the following.
> You can get these situations
> where you want to calculate a series of values
> or you want both the function and its derivative
> (say for the functions associated to second-order equations,
>  Bessel being the canonical example).
> Then there are often ways to calculate the necessary extra values 
> more optimally than just doing consecutive calculations
> (this is clear for the case of a sequence of values
> related by recursion, for example).  In the procedural world,
> you deal with this by providing multiple interfaces, such as
> 
>     o calculate f(x)
>     o calculate both f(x) and f'(x)
>     o . . .
>     o calculate f_n(x), f_{n+1}(x), ... f_m(x)
>
> The multiplicity of interfaces here
> reminds one of the kind of multiplicity
> which occurs in the standard procedural interfaces
> for things like linear algebra (lapack or blas,
>  with their exponential explosion of interface
>  for all the different types and algorithms).

It isn't exponential.

> It is not nearly so bad here
> but we are still talking about
> an increase in the size of the interface specification
> by a factor of 3 or so, over the "naive" notion
> of "Bessel function".  That's annoying for various reasons.
> 
>   o user perspective: more functions to understand
>     and wade through when looking for what you want
> 
>   o advanced user perspective: may want to reuse
>     the library algorithms in his own setting,
>     but there is no way to look into a library procedure,
>     other than a disagreeable copy-paste-edit-debug cycle
> 
>   o implementor perspective: more isolated
>     but closely related functionalities to support,
>     therefore more opportunity for problems
>     like functional duplication

You should specify as little as possible
about how a numerical class library is to be implemented.
Even the most subtle assumption
about the actual data representation or algorithm implementation
may preclude a better implementation without changing the API
and breaking all of the existing applications which depend upon it.

> The abstract problem is that these more involved calculations
> and composite calculations have state,
> and the basic design problem is encapsulating that state.
> In the procedural design you encapsulate that state
> solely in the procedure local variables.
> I would like to see an object-oriented design
> where that state gets stored in the obvious place:
> some object designed for it.
> 
> Note that there is an implicit assumption here
> about layering the design, so that average end users
> are not exposed to complexity that they are not interested in.
> However, the layer will be there to support users with special needs.
> In particular, the user with the most demanding special needs
> is the implementor himself
> who would ideally be able to compose pieces of the implementation
> from well-encapsulated and orthogonal base parts.
> 
> This may seem like alot of discussion
> for something as simple as "calculate J0(x)".
> But when you start thinking about efficient and clean implementations,
> you realize it is not so simple to get what you want
> out of the obvious mapping from functions of mathematics
> to functions in a procedural language.
> 
> I have written codes which were naively dominated
> by function evaluation and had to be structured
> in non-naive ways in order to make use of properties
> like recurrences to get the optimal performance
> (we're talking factors of 10 here, not fiddling at the 20% level).
> That sort of restructuring is often not the way
> that one thinks about the problem from a mathematical point of view
> and so you get an extra layer of confusion.
> I wonder if it would be possible to express what you mean
> in these sorts of situations rather than how the computer must do it.
> 
> Furthermore, I don't see anybody talking about this at all.
> Most of the work I see in high-performance C++
> is for vector/matrix/linear-algebra functionality.
> Very important stuff.  But the question of how to create
> efficient clean and usable high-performance components
> in other, perhaps more classical (and therefore boring?),
> areas of numerical computing is not often addressed.
> 
> Here is a basic question: Is this going to be harder or easier
> than the work being done on vector/matrix libraries?
> I don't know. Maybe some new things will have to be invented.
> Certainly we get new abstractions to play with,
> along with their associated implementation problems.

The scalar, vector, matrix and tensor arithmetic class libraries
are the basic foundation for virtually all of the more specialized
numerical class libraries.  You need to settle on a SVMT API standard
before you can make much progress with higher level class libraries.
Beyond SVMT arithmetic is linear algebra, signal processing,
image processing, numerical integration, ODE and PDE solvers, etc.
The Table of Contents from Numerical Recipes is probably as good
a place as any to outline the contents of a numerical class library.

The FFTW plan object is a DFT object.
Take a look at
The C++ Scalar, Vector, Matrix and Tensor class library

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

Download, decompress and unarchive svmt.tgz
and read "The C++ Digital Signal Processing classes"
in the .../svmt/doc/signal.pdf portable document format file.
Take a look at Robert Davies' Newmat library

	http://webnz.com/robert/

He defines matrix decomposition objects.
Take a look at
the Vector, Signal and Image Processing Library (VSIPL)

	http://www.vsipl.org/

The VSIPL defines objects of all sorts --
not just vector, matrix and tensor objects.


Numerical programmers usually aren't
software engineers or even professional programmers.
They are usually amateur programmers who were hired
and are paid to do some other kind of professional work
but are expected to write the application programs
that they need to complete their work.
They try to learn as little about programming
and/or software engineering as is required
to complete the application programs that they need to write.
They seldom recognize the advantage
in writing programs that are reusable
and easier for other application programmers
to read, understand and maintain.
They don't have time to learn and evaluate
all of the existing numerical libraries
before deciding which one is best suited
to their purposes so they are inclined
to simply implement their own version from scratch.
They may realize that their version
is not the best possible implementation
but they feel that, at least, they understand it
and have complete control over the source code
so that they can modify it if necessary.

The advantage of a standard API is that
application programmers can begin program development
before they have finished evaluating
all of the different implementations
and deciding which implementation is most suitable.
They don't need to learn a new API
for each implementation and comparisons
between implementations are relatively straight forward.
ANSI C application programmers don't really need
to know anything about object oriented programming
or even C++ to use C++ class libraries
because they appear to be simple extensions
to the ANSI C programming language.

Re: C++ wrapper

[E. Robert Tisdale]

Brian Gough <bjg at network-theory dot co dot uk> wrote:

> Ivo Kwee writes:
> 
> > I am thinking to start coding up a simple (?) C++ wrapper
> > providing operator overloading etc.
> > Why has no one started this yet? 
> 
> Lack of resources, mainly.  There is also the question
> of whether it is better to spend your time wrapping a C library,
> or writing a new C++ library from scratch --
> taking full advantage of the features of the language.
> (I think there was an earlier thread on the mailing list
>  which discussed this somewhere).

No.
I don't think that there is much to be gained
by reimplementing the GSL in C++.
The C++ "wrapper" around the ANSI C implementation
can be defined as "inline" so it won't cost anything.

> > Anyway, I would be OK to code something up
> > but I need some ready established interface specification.
> 
> My personal opinion:
> Rogue Wave's Math.h++ is an established commercial API.
> I think that it is
> the main commercial C++ numerical library on the market.
> I wouldn't make great claims for its design,
> but they have continued to sell it for a long time --
> so there must be some demand for that sort of thing.
> It is worth looking at, if nothing else,
> from that point of view.

This API is the property of Rogue Wave.
It probably can't be a standard API.
The proposed SVMT API standard was inspired, in part,
by the Roge Wave API but it is more up-to-date and avoids most
of the more obvious the difficulties with the Rogue Wave API.

> I once started doing something like that, a long time ago,
> which you can see here:
> 
>	http://www.network-theory.clara.co.uk/gslrw.tar.gz

I get garbage when I click on this URL.

Re: C++ wrapper

[Brian Gough]

Gerard Jungman writes:
 > Furthermore, I don't see anybody talking about this at all.

I recommend looking at GNU Sather.

 > Most of the work I see in high-performance C++ is for
 > vector/matrix/linear-algebra functionality.  Very important
 > stuff. But the question of how to create efficient clean and usable
 > high-performance components in other, perhaps more classical (and
 > therefore boring?), areas of numerical computing is not often
 > addressed.

Re: C++ wrapper

[Brian Gough]

Hi,

Ivo Kwee writes:
 > I am thinking to start coding up a simple (?) C++ wrapper providing
 > operator overloading etc. Why has no one started this yet? 

Lack of resources, mainly.  There is also the question of whether it
is better to spend your time wrapping a C library, or writing a new
C++ library from scratch -- taking full advantage of the features of
the language. (I think there was an earlier thread on the mailing list
which discussed this somewhere).

 > Anyway, I would be OK to code something up but I need some ready
 > established interface specification.

My personal opinion: Rogue Wave's Math.h++ is an established
commercial API.  I think that it is the main commercial C++ numerical
library on the market.  I wouldn't make great claims for its design,
but they have continued to sell it for a long time -- so there must be
some demand for that sort of thing.  It is worth looking at, if
nothing else, from that point of view.

I once started doing something like that, a long time ago, which you
can see here: http://www.network-theory.clara.co.uk/gslrw.tar.gz

regards
Brian

Re: C++ wrapper

[Gerard Jungman]

Dave Morrison wrote:
> http://www.fnal.gov/docs/working-groups/fpcltf/Pkg/SpecialFunctions/doc/html/0SpecialFunctions.html

Hmmm. Ok. This is not meant as a criticism (really, it's not),
but how come this is the first time I have heard about this?
I know a little about ZOOM, but I didn't know they were
wrapping GSL special functions (other stuff too...?).

I'm just interested in making sure that we keep open lines
of communication. I've been thinking alot about native
C++ implementations for some of the GSL functionality,
so I am interested in what people want to do. Anyway,
I see that this is a fairly straightforward wrapper
project, so maybe they thought it would not be
sufficiently whiz-bang to bring up in this forum.
But still, any sort of general discussion about
C++ is welcome here.

I am especially interested in new object-oriented
designs. As an example, consider the following.
You can get these situations where you want to calculate
a series of values, or you want both the function and its
derivative (say for the functions associated to second-order
equations, Bessel being the canonical example). Then there
are often ways to calculate the necessary extra values 
more optimally than just doing consecutive calculations
(this is clear for the case of a sequence of values
related by recursion, for example). In the procedural
world you deal with this by providing multiple interfaces,
such as
    o calculate f(x)
    o calculate both f(x) and f'(x)
    o calculate f_n(x), f_{n+1}(x), ... f_m(x)

The multiplicity of interfaces here reminds one
of the kind of multiplicity which occurs in the
standard procedural interfaces for things like
linear algebra (lapack or blas, with their exponential
explosion of interface for all the different types and
algorithms). It is not nearly so bad here, but we are still
talking about an increase in the size of the interface
specification by a factor of 3 or so, over the "naive"
notion of "Bessel function". That's annoying for various
reasons.

  o user perspective: more functions to understand and
    wade through when looking for what you want

  o advanced user perspective: may want to reuse the
    library algorithms in his own setting, but there
    is no way to look into a library procedure, other than
    a disagreeable copy-paste-edit-debug cycle

  o implementor perspective: more isolated but closely
    related functionalities to support, therefore more
    opportunity for problems like functional duplication

The abstract problem is that these more involved
calculations and composite calculations have
state, and the basic design problem is encapsulating
that state. In the procedural design you encapsulate
that state solely in the procedure local variables.
I would like to see an object-oriented design where
that state gets stored in the obvious place: some
object designed for it.

Note that there is an implicit assumption here
about layering the design, so that average end
users are not exposed to complexity that they
are not interested in. However, the layer will
be there to support users with special needs.
In particular, the user with the most demanding
special needs is the implementor himself who
would ideally be able to compose pieces of the
implementation from well-encapsulated and orthogonal
base parts.


This may seem like alot of discussion for something
as simple as "calculate J0(x)". But when you
start thinking about efficient and clean
implementations, you realize it is not so
simple to get what you want out of the obvious
mapping from functions of mathematics to functions
in a procedural language.

I have written codes which were naively dominated
by function evaluation and had to be structured
in non-naive ways in order to make use of properties
like recurrences to get the optimal performance
(we're talking factors of 10 here, not fiddling
at the 20% level). That sort of restructuring is
often not the way one thinks about the problem
from a mathematical point of view, and so you
get an extra layer of confusion. I wonder if it
would be possible to express what you mean in
these sorts of situations rather than how the
computer must do it.

Furthermore, I don't see anybody talking about this
at all. Most of the work I see in high-performance C++
is for vector/matrix/linear-algebra functionality.
Very important stuff. But the question of how to create
efficient clean and usable high-performance components
in other, perhaps more classical (and therefore boring?),
areas of numerical computing is not often addressed.

Here is a basic question: Is this going to be harder
or easier than the work being done on vector/matrix
libraries? I don't know. Maybe some new things
will have to be invented. Certainly we get new
abstractions to play with, along with their
associated implementation problems.


-- 
G. Jungman

Re: C++ wrapper

[Dave Morrison]

Hi,

Folks might be interested in perusing the C++-ification of the special
functions part of GSL that people at Fermilab have done.  Looks
interesting to me.  Here's a (very long) URL:

http://www.fnal.gov/docs/working-groups/fpcltf/Pkg/SpecialFunctions/doc/html/0SpecialFunctions.html

Cheers,
Dave

-- 
David Morrison  Brookhaven National Laboratory  phone: 631-344-5840
                Physics Department, Bldg 510 C    fax: 631-344-3253
		          Upton, NY 11973-5000  email: dave@bnl.gov

Re: C++ wrapper

[Steve ROBBINS]

On Wed, 22 Nov 2000, Ivo Kwee wrote:

> Dear all,
> 
> GSL is a great library but math-intensive code in C++ is rather
> unreadable using the standard C-namings.
> 
> I am thinking to start coding up a simple (?) C++ wrapper providing
> operator overloading etc. Why has no one started this yet? Anyway, I
> would be OK to code something up but I need some ready established
> interface specification. 
> 
> Earlier, SVMT has been mentioned. Is this the "best" one to go for?
> Anyone knows "better" or more "accepted" standards? I was thinking
> myself if MatLab-like conventions would be better, but they are not
> really OO style. Suggestions?

I haven't used it myself, but I believe that Octave comes with C++
wrappers around a bunch of numerical libraries.  Mostly linear algebra,
I'd guess, but there should be some others.   I'd be interested in
comments from folks that have looked into using this in their own C++
programs (as opposed to using octave proper).

-S

C++ wrapper

[Ivo Kwee]

Dear all,

GSL is a great library but math-intensive code in C++ is rather
unreadable using the standard C-namings.

I am thinking to start coding up a simple (?) C++ wrapper providing
operator overloading etc. Why has no one started this yet? Anyway, I
would be OK to code something up but I need some ready established
interface specification. 

Earlier, SVMT has been mentioned. Is this the "best" one to go for?
Anyone knows "better" or more "accepted" standards? I was thinking
myself if MatLab-like conventions would be better, but they are not
really OO style. Suggestions?

Ivo


-- 
IDSIA - instituto Dalle Molle di studi sull'intelligenza artificiale

Ivo W. Kwee                        phone:  +41-91-610-8671/66   
Galleria 2                           fax:  +41-91-610-8661 
CH-6928 Manno, SWITZERLAND           web:  www.idsia.ch