commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Libbrecht <p...@activemath.org>
Subject Re: [Math] common-math and bloated 3rd party libraries
Date Mon, 17 Nov 2003 23:26:26 GMT
Mark R. Diggory wrote:
> 
> 
> Paul Libbrecht wrote:
> 
>> Mark R. Diggory wrote:
>>
>>> I removed instances of this Logging entry in an earlier commit. I 
>>> think awhile back there was allot of discussion about if this should 
>>> throw an exception or return NaN. The origin of this exception is a 
>>> Convergence Exception in ContinuedFraction. The big question is the 
>>> same as before, should this convergence exception be passed out and 
>>> handled by the application or should it be suppressed internally the 
>>> way it is here>>
>> As a developer I would like to get it configurable. But I guess I'd be 
>> hated by people of requesting so...
>>
>> Returning NaN is almost certain to raise some exception later, or ?
> 
> 
> That sounds kinda cynical ;-)

By no means !

> My ultimate sentiment is to just get it passed on out and let the 
> application manage exceptions dealing with non-convergence. Maybe thats 
> the simplest possible comprimise? Then the user can decide what they 
> will do when convergence fails instead of having the application 
> suppress the exception and force them to test for NaN conditions all the 
> time?

But I would expect that it is not the application itself and not even 
the user which will receive the NaN but some other, say a 
graph-component (they should be quite happy with that), or something else...

I had a case recently where I made a little integrer calculator offering 
+-*/ within a kind of console. And it turned out was important for this 
usage to have a message that said that the 7 was not dividable by 3. 
Having NaN >somewhere< (hence everywhere with these operations) would 
have just told the user something like "Huh ?".

(plus some people tend even to indicate wether this is positive-zero or 
negative-zero (when doing elementary limits) which would yeald us 
positive-NaN or negative-NaN !!).

But maybe I'm going too far... sorry...

Paul


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


Mime
View raw message