Re: [math] Users Abilities vs. Developers was RE: [math] Very legitimate reasons to draw up Presicison Unit Tests.

[Phil Steitz <ph...@steitz.com>]

Hope, Matthew wrote:
> 
>>-----Original Message-----
>>From: Phil Steitz [mailto:phil@steitz.com] 
>>Sent: 27 May 2003 02:01
>>To: Jakarta Commons Developers List
>>Subject: Re: [math] Very legitimate reasons to draw up 
>>Presicison Unit Tests.
> 
> <snip>
> 
>>* Support multiple algorithms when appropriate and let the 
>>users decide.
>>   For example, we will likely want to add an alternative to Cholesky
>>   decomposition and allow the user to choose.
> 
> <snip>
> 
> I think there is a question here form the users point of view. How much
> mathematical and numerical knowledge should be assumed.

Not much, I hope. We will not have met the goals outlined in the 
proposal if users *need* to know very much math to be able to use the 
tools effectively.

> 
> It is reasonable to my mind to assume that a user of this libraray should be
> aware of performance considerations with regards to which algortihm is used
> (since in any case if it's important to them they should be testing it!) But
> understanding of the intricacies of numerical programming strikes me as
> something that would be best hidden away unless the user *really* wants to
> play.

I agree.  The key thing is to "let" the user decide without "forcing" 
the user to decide.  Reasonable default behavior should be easy to get. 
  Hopefully, we have not (yet) violated that in what has actually been 
implemented up to now.  We need to keep looking at this.
> 
> I did a Maths and Comp degree and found the [math] threads wonderfully
> refreshing after so long programming business code but realistically would
> expect most users to just want to get a reasonable answer without worrying
> about whether the values they were passing in reuired one or the other
> algorithms...

I agree, but this is a little bit tricky in some cases.

> 
> An explicit parameter such as precisionBits or some such which would allow
> the lib to decide on algorithms behind the scenes sounds more user friendly
> (and would allow the lib to grow/improve without breaking code which really
> doesn't care *how* the matrix is being solved/ mean is being calculated and
> really only wants the numbers.

I agree with the spirit of this.  User-specified bit-level precision 
contracts would be very hard to satisfy in practice, however.  Probably 
best to just have "extended precision" or "extended domain" 
implementations for some things, but I agree with your main point.

> 
> I have a high degree of trust in the code from the jakarta project and am
> normally confident to use it in production without reading the source
> (something I normally do to any other library even if it means decompiling
> it). I would prefer to just trust it to give me as good an answer as it can
> give and let the javadocs state how much precision I can expect.
> 

> Random numbers are a good example of this - if java's default one was better
> there would be no need to provide multiple different approaches to the
> average user. 

Personally, I see nothing fundamentally wrong with the JDK generator for 
the vast majority of actual application use cases and I see our 
RandomData stuff as just providing easy-to-use applications of this (or 
some other pluggable) generator to satisfy common random data generation 
needs. This is an example where providing a default implementation based 
on the JDK generator makes sense.  *Allowing* users to select a 
different generator without *forcing* them to think about this is what 
we should do, IMHO.

I don't care* if it's a mersenne twister or not, I just want
> fast
  decent random numbers, beyond a certain point there is no improvement
> to me worth the additional effort of *thinking* about which to use; I
> appreciate someone with more experience thinking about it for me.
> 
> Matt
> 
> * OK I *do* care but that's because I have an unhealthy liking for
> algorithms - I' not _paid_ to care would be a better statement ;¬)

Pls keep asking these questions as we start to stabilize interfaces. 
Thanks.

Phil


>  
> **************************************************************************
> The information transmitted herewith is sensitive information intended only
> for use by the individual or entity to which it is addressed. If the reader
> of this message is not the intended recipient, you are hereby notified that
> any review, retransmission, dissemination, distribution, copying or other
> use of, or taking of any action in reliance upon this information is
> strictly prohibited. If you have received this communication in error,
> please contact the sender and delete the material from your computer.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 




---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [math] Users Abilities vs. Developers was RE: [math] Very legitimate reasons to draw up Presicison Unit Tests.

[Al Chou <ho...@yahoo.com>]

--- Phil Steitz <ph...@steitz.com> wrote:
> Hope, Matthew wrote:
> >>-----Original Message-----
> >>From: Phil Steitz [mailto:phil@steitz.com] 
> >>Sent: 27 May 2003 02:01
> >>To: Jakarta Commons Developers List
> >>Subject: Re: [math] Very legitimate reasons to draw up 
> >>Presicison Unit Tests.
> > 
> > <snip>
> > 
> >>* Support multiple algorithms when appropriate and let the 
> >>users decide.
> >>   For example, we will likely want to add an alternative to Cholesky
> >>   decomposition and allow the user to choose.
> > 
> > <snip>
> > 
> > I think there is a question here form the users point of view. How much
> > mathematical and numerical knowledge should be assumed.
> 
> Not much, I hope. We will not have met the goals outlined in the 
> proposal if users *need* to know very much math to be able to use the 
> tools effectively.
> 
>
> > It is reasonable to my mind to assume that a user of this libraray should
> be
> > aware of performance considerations with regards to which algortihm is used
> > (since in any case if it's important to them they should be testing it!)
> But
> > understanding of the intricacies of numerical programming strikes me as
> > something that would be best hidden away unless the user *really* wants to
> > play.
> 
> I agree.  The key thing is to "let" the user decide without "forcing" 
> the user to decide.  Reasonable default behavior should be easy to get. 
>   Hopefully, we have not (yet) violated that in what has actually been 
> implemented up to now.  We need to keep looking at this.
> > 
> > I did a Maths and Comp degree and found the [math] threads wonderfully
> > refreshing after so long programming business code but realistically would
> > expect most users to just want to get a reasonable answer without worrying
> > about whether the values they were passing in reuired one or the other
> > algorithms...
> 
> I agree, but this is a little bit tricky in some cases.

Amen to that.  The success of a numerical algorithm is sometimes determined by
what problem it is asked to solve (e.g., some matrix problems are
ill-conditioned because of the specific values in the matrix), which is why
problem solving often requires forethought.  I support trying to make tools
easy to use, but that can often be very difficult and sometimes impossible. 
Still, we should strive for it, all the while remembering that we're not in the
AI business here, and sometimes the user will really have to provide
information they might not have known a priori they would need to know.


Al

=====
Albert Davidson Chou

    Get answers to Mac questions at http://www.Mac-Mgrs.org/ .

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org