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...<br /><br />There, you can introduce exception for handling -2 sqrt, with two possibilities:<br />- return with empty collection<br />- return with complex solutions<br />This is just one possible style of programming (i would not say the best).<br />I think it would be better with a handler block as extra argument in this simple case.<br /> <br /> Nicolas<br /><br />Markus Gaelli:<br /> <blockquote style="border-left: 1px solid blue; border-right: 1px solid blue; margin: 10px"><br /> On Mar 17, 2006, at 3:49 PM, ncellier@ifrance.com wrote:<br /> <br /> > Once you have put these exceptions at critical low levels, it is in <br /> > some cases (i do not say all cases) far more comfortable to squeeze <br /> > higher level precondition/postcondition tests and use exception <br /> > handling instead. T
his is where i am speaking of programming style.<br /> ><br /> > Lost of performance come not only from low level defense, but also <br /> > from testing several times the same assertion in the call chain. <br /> > Removing second half is not risky.<br /> <br /> Ah...ok. Sure, I don't like checking the same stuff over and over again.<br /> To quote myself from earlier in this thread:<br /> ><br /> > Example: I have a method to solve the quadratic equation f(x)=axx+bx+c<br /> ><br /> > Array >> #solveQuadraticEquation<br /> >         |a b c discriminant solutions |<br /> >         self precondition: [self size = 3 and: [self allSatisfy: [:each | <br /> > each isNumber]]].<br /> >         "Do I have to state here that the discriminant should be >= 0? I <br /> > do not think so."<br /> >         a:= self first.<br /> >         b:= self second.<br /> >         c:= self third.<br /> >         discriminant:=(b*b)-(4*a*c).<br /> >         solutions := Set new.<
br /> >         solutions<br /> >                 add:((0-b+discriminant sqrt)/(2*a));<br /> >                 add:((0-b-discriminant sqrt)/(2*a)).<br /> >         ^solutions<br /> ><br /> > If the discriminant<0 the precondition of sqrt should fail. I do <br /> > not want to state that here also as I am lazy and as I have not <br /> > computed the discriminant in the beginning.<br /> ><br /> <br /> Meanwhile I came to the conclusion that a better style for above <br /> method would certainly be to always return a collection of solutions, <br /> in the case of a negative discriminant the collection should just be <br /> empty.<br /> So it better looked like:<br /> <br /> Array >> #solveQuadraticEquation<br />         |a b c discriminant solutions |<br />         self precondition: [self size = 3 and: [self allSatisfy: [:each | <br /> each isNumber]]].<br />         a:= self first.<br />         b:= self second.<br />         c:= self third.<br />         discriminant:=(b*b)-(4*a*c).<br />         discriminant < 0 ifTrue
: [^#()].<br />         solutions := Set new.<br />         solutions<br />                 add:((0-b+discriminant sqrt)/(2*a));<br />                 add:((0-b-discriminant sqrt)/(2*a)).<br />         self postcondition: [<br />                 (solutions size between: 1 and: 2) and: [<br />                         solutions allSatisfy: [:each | ((a*each*each)+(b*each)+c) abs <= <br /> 1.0e-10]]].<br />         ^solutions<br /> <br /> A typical case for a predictable situation which can be handled <br /> perfectly well without having to deal with any exceptions.<br /> <br /> I still fail to see why I would have to introduce exception handling <br /> at a higher level due to not stating the same assertion over and over <br /> again:<br /> I did not understand your NaN example, could you elaborate on that or <br /> send another example?<br /> <br /> Note that I added a post condition, so here come a<br /> <br /> PRICE QUESTION: (the person answering to this one last gets a beer <br /> (or bounty?) next time we meet personally... ;-)<br /> <br /> Would tes
t cases for that method still need to state the expected <br /> outcome?<br /> Sth. along the line of<br /> <br /> ArrayTest >> testSolveQuadaticEquation<br />         self assert: (#(1 -4 4) solveQuadraticEquation asArray = #(2.0))<br />         (...)<br /> <br /> Or would it be sufficient to just provide examples a la:<br /> <br /> ArrayTest >> testSolveQuadaticEquation<br />         #(1 -4 4) solveQuadraticEquation.<br />         (...)<br /> <br /> as the postcondition here is already basically an inverse function, <br /> and "nothing" should go wrong....<br /> Any opinions on that?<br /> <br /> Cheers,<br /> <br /> Markus<br /> <br /> <br /> <br /> </blockquote>
<br><br><hr style="border:0;height:1px;color:#d1d1db;background-color:#d1d1db;">
<table cellpadding=0 cellspacing=0><tr><td><a href="http://web.ifrance.com/"><img border=0 align=left src="http://image.ifrance.com/mail/colibri.gif"></a></td>
<td style="line-height:7px"><a href="http://web.ifrance.com/" style="line-height:11px;font-family:arial;font-size:11px;color:#1b174a;text-decoration:none"><b><span style="color:#9b90d5">i</span>FRANCE</b></a>
<br><a href="http://web.ifrance.com/services/" style="line-height:6px;font-family:arial;font-size:11px;color:#1b174a;text-decoration:none">exprimez-vous !</a></td></tr></table>