Paul Libbrecht wrote:

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


No, not too far at all, thats a great usage example for why exceptions here may be more beneficial in the long run!



-- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to