Boost logo

Boost :

From: Kevin Lynch (krlynch_at_[hidden])
Date: 2001-09-07 12:59:12


Eric Ford wrote:

> I thought a little bit about this and made up a straw man interface.
> Comments are invited.

Boy, that's a hideous interface :-)

But I mean that in a good way. I think it might be a good starting
point for discussion. It does seem to include the major types of
information that one might want/need to obtain the variant behaviors
that have been discussed. It just seems a bit involved and complicated
if the target is the end user. But as an interface to build a library
on, I don't see it as probably the right level of complexity: "As
simple as possible, but no simpler!"

Some things I'm worried about:

-> Can this possibly be efficient, what with all that
construction/destruction going on? Maybe it is and I'm worried about
nothing. If it isn't, maybe it can be made so by appropriate static
constructions at start time of "standard" checkers. Building some more
complex examples and comparing space/time use to similarly coded bare
functions would be a good idea.

-> The examples are of implementing some pretty silly functions (this is
not a complaint, since they aren't bad examples, just pretty trivial).
I would just like to see some examples of how this works out in more
elaborate settings. What about, for example, multiple argument
functions; does this interface still work well? What about more
elaborate functions like, say, the bessel functions? What about
standard functions that take reals and integers as arguments (think the
standard polynomials of mathematical physics)... does the interface
expand appropriately? Probably, but I'm not sure how horrible it gets,
or how many special cases you need.

-> Can we hide the complexity from USERS of the interface? Can one
provide efficient implementations of a more standard function call
interface with no checking on top of this class interface? Can that
function interface be made efficient in both space and time (such that a
library won't have to construct thousands of small classes at start time
to avoid construction/destruction at run time, and will run quickly).
Most of the time, you will want to just say BesselJ(x, n) where you need
it, rather than constructing an instance of BesselJ<double, double,
int, ......> that you then call... or maybe you won't.

-> Can the functions already in the standard library be reimplemented to
fit the interface without breaking legacy code? (again, this would
require a more conventional function interface with no checking)

-> Since I keep asking about a more standard function call interface,
can one do away with the class interface entirely? Can it be made a
completely template function based interface, or does the interface NEED
to be a class based interface for language reasons? I'm not sure what
all the pros and cons of both types of interfaces are... certainly, for
passing "functions" to "algorithms" (think integrators, or
interpolators, etc....), a class based approach is more useful, since
you would otherwise end up writing little classes to wrap functions.
But in most other cases, you simply want to call the function without
constructing objects all over the place. One thing I'm worried about is
that using a class interface for functions will scare off a large number
of potential users; but you might be willing to lose a few users for
demonstrable benefits. Are those benefits there?

-> You mention using tuple for multiple returns... I thought of that
myself, but how efficient is tuple? Would array<> or something similar
work better? Would this interface be yet another good example of how
useful a fundamental tuple type would be? Pulling items out of tuples
seems to require construction of a number of temporaries... is the speed
hit sufficiently small to be a non-issue? What about array<>'s?

-> Thinking about passing these things into algorithms, can those
algorithms be built on top of this interface effectively? I think this
is an important consideration for any mathematical function interface...
after all, calling a function is important, but to be useful for real
work, you need to be able to feed them to generic algorithms easily and
efficiently. It would be nice if you could build a function interface
that would make it easily to build a generic, arbitrary argument, monte
carlo integrator, for example. Can that be done here, or do we need
something more? or less?

Lots of thoughts are bouncing around in my head right now, and I'm not
sure I'm doing a good job of getting them out to the keyboard :-) In
any case, I'll take a closer look at all the files and see if I can wrap
my brain around some of these questions and figure out which ones are
silly... assuming that I can find the time in the next few days :-) I'm
liking what I'm seeing as a starting point, however. Thanks for jump
starting the discussion Eric!

-- 
-------------------------------------------------------------------------------
Kevin Lynch				voice:	 (617) 353-6065
Physics Department			Fax: (617) 353-6062
Boston University			office:	 PRB-565
590 Commonwealth Ave.			e-mail:	 krlynch_at_[hidden]
Boston, MA 02215 USA			http://physics.bu.edu/~krlynch
-------------------------------------------------------------------------------

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk