Ah, i have forgotten another thing: your algorithm would almost work with Complex, except you should remove the discriminant < 0 test and change the precondition...

There, you can introduce exception for handling -2 sqrt, with two possibilities:
- return with empty collection
- return with complex solutions
This is just one possible style of programming (i would not say the best).
I think it would be better with a handler block as extra argument in this simple case.
 
 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/d03e9410/attachment.htm