Well, your example would fail with

#(1.0e300 5.0e300 6.0e300) solveQuadraticEquation

because of NaNs, but that would be detected in the post conditions,
though solution is obviously #(-3 -2).

And your postcondition might fail with

 #(3.0e100 5.0e100 2.0e100) solveQuadraticEquation

because residual error might well get bigger than the 1.0e-10 tolerance, though accuracy on solutions would be quite good.

(sorry i have not a running image to assert what i say, but you will soon find similar example).

In the above case, you could catch this NaN and maybe retry with another algorithm that would first normalize first or last coefficient of you polynomial.
The example is not very good because we cannot figure why we need two algorithms here. But think of solving an eigenvalue problem or a Riccati equation, then we have several possible algorithms an could retry with matrix balancing or with another algorithm before giving up with an error notification.

Nicolas


 

Markus Gaelli:
 
 On Mar 17, 2006, at 3:49 PM, ncellier at ifrance.com wrote:
 
 > Once you have put these exceptions at critical low levels, it is in  
 > some cases (i do not say all cases) far more comfortable to squeeze  
 > higher level precondition/postcondition tests and use exception  
 > handling instead. This is where i am speaking of programming style.
 >
 > Lost of performance come not only from low level defense, but also  
 > from testing several times the same assertion in the call chain.  
 > Removing second half is not risky.
 
 Ah...ok. Sure, I don't like checking the same stuff over and over again.
 To quote myself from earlier in this thread:
 >
 > Example: I have a method to solve the quadratic equation f(x)=axx+bx+c
 >
 > Array >> #solveQuadraticEquation
 > 	|a b c discriminant solutions |
 > 	self precondition: [self size = 3 and: [self allSatisfy: [:each |  
 > each isNumber]]].
 > 	"Do I have to state here that the discriminant should be >= 0? I  
 > do not think so."
 > 	a:= self first.
 > 	b:= self second.
 > 	c:= self third.
 > 	discriminant:=(b*b)-(4*a*c).
 > 	solutions := Set new.
 > 	solutions
 > 		add:((0-b+discriminant sqrt)/(2*a));
 > 		add:((0-b-discriminant sqrt)/(2*a)).
 > 	^solutions
 >
 > If the discriminant<0 the precondition of sqrt should fail. I do  
 > not want to state that here also as I am lazy and as I have not  
 > computed the discriminant in the beginning.
 >
 
 Meanwhile I came to the conclusion that a better style for above  
 method would certainly be to always return a collection of solutions,  
 in the case of a negative discriminant the collection should just be  
 empty.
 So it better looked like:
 
 Array >> #solveQuadraticEquation
 	|a b c discriminant solutions |
 	self precondition: [self size = 3 and: [self allSatisfy: [:each |  
 each isNumber]]].
 	a:= self first.
 	b:= self second.
 	c:= self third.
 	discriminant:=(b*b)-(4*a*c).
 	discriminant < 0 ifTrue: [^#()].
 	solutions := Set new.
 	solutions
 		add:((0-b+discriminant sqrt)/(2*a));
 		add:((0-b-discriminant sqrt)/(2*a)).
 	self postcondition: [
 		(solutions size between: 1 and: 2)  and: [
 			solutions allSatisfy: [:each | ((a*each*each)+(b*each)+c) abs <=  
 1.0e-10]]].
 	^solutions
 
 A typical case for a predictable situation which can be handled  
 perfectly well without having to deal with any exceptions.
 
 I still fail to see why I would have to introduce exception handling  
 at a higher level due to not stating the same assertion over and over  
 again:
 I did not understand your NaN example, could you elaborate on that or  
 send another example?
 
 Note that I added a post condition, so here come a
 
 PRICE QUESTION: (the person answering to this one last gets a beer  
 (or bounty?) next time we meet personally... ;-)
 
 Would test cases for that method still need to state the expected  
 outcome?
 Sth. along the line of
 
 ArrayTest >> testSolveQuadaticEquation
 	self assert: (#(1 -4 4) solveQuadraticEquation asArray = #(2.0))
 	(...)
 
 Or would it be sufficient to just provide examples a la:
 
 ArrayTest >> testSolveQuadaticEquation
 	#(1 -4 4) solveQuadraticEquation.
 	(...)
 
 as the postcondition here is already basically an inverse function,  
 and "nothing" should go wrong....
 Any opinions on that?
 
 Cheers,
 
 Markus
 
 
 
 
________________________________________________________________________
iFRANCE, exprimez-vous !
http://web.ifrance.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20060317/3c263f3a/attachment.htm