[ODE] 0.9-rc1

[Oleh Derevenko]

----- Original Message ----- 
From: "Irrisor"
Subject: Re: [ODE] 0.9-rc1


>> Well, you think it is better to produce incorrect result and keep working
>> even if user may not notice that error?
> I agree that the user/application should notice the error, yes. But YES, 
> it is
> better to keep the rest of a system working if one tiny part fails.
>
Well, if that is possible. But usually, invalid operations such as division 
by zero, negative argument to square root or logarithm or nomalization of 
zero vector indicate an algorithm defect. So, in most cases defective 
algorithm will lead to unpredictable results including incorrect output or 
data loss.
Surely, it is up to application to decide what is the severity of the fault 
and if execution can be continued after it. That's why we introduce 
dSafeNormalize(). If you know that in some particular case error could be 
expected or it is not expected but it is not fatal as well, you can use 
dSafeNormalize() and check the result. However, if you use function with 
void result, it is not allowed for it to silently give up its job and return 
a dummy output.

> Building the release version without assertions (as you suggested)
> wouldn't make much sense, because the problem might arise after shipping 
> an
> application the first time.

You do not understand the purpose of assertion check. If you assert 
something it means that the condition CAN NEVER BE FALSE. If it is possible 
for condition to be ever violated you must use conditional operator and 
handle both cases. Therefore it is illegal to assert results of system 
calls, even though they should normally succeed - they CAN FAIL 
THEORETICALLY. And therefore program functionality must not depend on 
assertin checks. If you suspect that the condition can be violated, you 
should handle that case explicitly with "if" operator. And assertions are 
just HELPER VALIDATIONS WITH NO SIDE EFFECTS that assist in debugging the 
code.

Oleh Derevenko
-- ICQ: 36361783