Hi,
I have a strategy that I want to re-code in v5.
The difference occurs when I am summing 20 numbers in v3,
where some of them are NAN. WL3 seems to just ignore it, whereas
v5 will build the sum = n. def.
Is this correct?
QUOTE:
v3:
5 + 5 + 5 + NAN = 15
v5:
5 + 5 + 5 + n. def. = n. def.
Size:
Color:
Code? What does the mysterious "n. def" mean?
Size:
Color:
Please try the following code:
CODE:
Please log in to see this code.
Size:
Color:
There is something called "IEEE 754". This is a worldwide standard for binary floating-point arithmetic. In particular, it states that arithmetic operations between NaN and anything else always result in NaN.
You should check explicitly if added values are not NaN before summing them:
Double.IsNaN Method
Size:
Color:
and was that handled different in v3?
Size:
Color:
I don't have v3. Nonetheless, it's not a v5 thing at all - it's a global standard, and every C# application will produce a NaN here:
CODE:
Please log in to see this code.
Size:
Color:
Okay, there seems to be a difference between v3 and v5. which is okay, but how can I replicate same behaviour in v5?
v3 code:
CODE:
Please log in to see this code.
v5 code:
CODE:
Please log in to see this code.
Size:
Color:
QUOTE:
I don't have v3. Nonetheless, it's not a v5 thing at all - it's a global standard, and every C# application will produce a NaN here:
Please dont misunderstand me....this is totally okay. In this process I try to understand
a) what the difference is and
b) what the solution is to replicate v3 results.
dansmo
Size:
Color:
Of course, it's up to you if you'd like to replicate the V3's behavior that went against the IEEE standard. Please see the link in my reply from 3/2/2010 6:47 AM on how to handle NaN gracefully.
Size:
Color:
I found my mistake and it was not against IEEE standard. When recoding the script I mistakenly added a sqrt where there was a sqr in v3. I did not see the difference until now.
Size:
Color:
Glad you found it.
Size:
Color: