Re: Math Functions

From: Kevin Lynch (krlynch_at_[hidden])
Date: 2001-09-10 12:49:02

Eric Ford wrote:

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

> I guess that I'm so used to constructing functions, I don't think much of
> it.  Is it really that undesirable?

No, it isn't, as long as it doesn't add up to a non-trivial cost in
standard usage.  I doubt it will, but I haven't seen any data recently
to convince me that it is never an issue.

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

> I'm not entirely sure if I'm understanding you correctly.  But I think
> we'd probably want to reimplement most of those, possibly using the
> standard library functions for some parameter values

I was thinking longer term, perhaps:  Basically, if the "final
interface" turns out to be useful, powerful, efficient, and effective,
one would probably want to reimplement the standard C math library (and
the C++ extensions) in terms of the new interface, so that these
standard functions could be used everywhere that other functions built
to this new interface can be used.  In other words, if the function
interface makes it easy to build a "mathematical algorithms" library
including integration for example, you would want to be able to use the
standard library functions there to, without having "special" support
for them.  Therefore, you would want to reimplement them in terms of
this new function interface.  BUT, by doing so, you have to ensure that
all valid prior uses remain valid uses.  So, this question was a more
longterm concern of not wanting to develop an interface that couldn't
grow to subsume the current standard library as a completely dependent
subset. I'm not worried about name conflicts or similar "trivia"; I'm
really worrying about the big picture.

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

> I beleive the benefits are there.

I think they are too, I just wanted to make sure that I wasn't missing
anything important that would dictate a purely function based approach. 
I still can't think of anything that would suggest against a class based
interface.

> I'd say it sounds like, except
> in extreme cases, returning two or three values in a tuple is probably
> not too big of a performance penalty.  

I didn't mean to suggest that tuple wasn't efficient.  I just haven't
had the opportunity to try it out and see for myself.  I wouldn't be
surprised if it was far more efficient than most methods of passing
multiple results out of functions!

I'll take a look at your new code, and sometime this afternoon I'll send
some more thoughts if I have any...

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