Disturbing Bug? While using the “Floor” function in iLogic

[HermJan.Otterman]

Hello everyone, I have to dimensions. One from a calculation and it is 30 mm

I have a second value that is 3mm.

Because the 30 can also be any other number, I use the “floor” function, to round it down to the next whole number. So far so good.

If I create a new parameter and put the calculation in the equation field, the outcome is 10, as it should be!

If I do the same, in the same document, in an iLogic rule the outcome is 9…!!!! And this is WRONG..!!??

I could fix this by rounding the “divider” but than I have to round every value…?!

Also If I use the MOD function, it returns 3 but it should return 0.

Now you can say that it has to do with the rounding after 15 digits, but why does to work in the parameter editor…

What am I missing here??

And why is the result of the same calculation different in the parameters and iLogic I the same document!!

Has anyone else come across this issue?

Look at my screencast

[Anonymous]

Done some testing, and it shows strange behaviour on other parameters as well.

All parameters shown in the image were created by typing the value with lots of zero's...

Why do the values "3" and "6" have a different behaviour compared to the others?

Since "3" is not really "3" the floor function will also respond to that.

 

[MechMachineMan]

It's important to understand what the code is doing.

This includes:

a) return values -- from calling the parameter directly, and also calling floor

b) data types - ex// Double vs Decimal

c) How called functions operate to generate that return value; ie floor.

The results aren't disturbing. They're expected when using incompatible data types.

res = Floor(CDec(a)/CDec(b))

MsgBox("a: " & a & vbLf & _
	   "b: " & b & vbLf & _
	   "res: " & res)

[HermJan.Otterman]

I disagree with you on this.

especially when using the same "Formula" / code in the parameter, and in iLogic, where the parameter returns 10 and iLogic returns 9. (all Doubles..)

iLogic was also created for engineers that are no programmers. this can't be right.

that should mean that EVERY value has to be converted to a decimal. I have never seen any code where that is done

I agree with you that you have to have some understanding of what code is doing, but this is not right.

also, the parameters are doubles, right?

why does the value get 10 if I enter the "formula" in the parameter equation?

what is happening with the values Leon is showing?  so with 3 and 6 I have a problem and not with the rest.

if the parameters would be showing me the not precise number than it maybe would be different.

but when I use the MOD function, and it gives me also 3 (or 6).. than it should give me some thing like 2.9999999999999964533

[HermJan.Otterman]

Can someone of Autodesk comment on this issue? to get an "Official" statement?

that would be nice, thanks.

[MjDeck]

Herm Jan,

 Most of the math functions in iLogic (including Floor) are standard .NET math functions. I'm not sure why the floor function in the Parameters dialog works better in this case. I'll try to find out.

One significant source of inaccuracy in parameter values is units conversion. Length parameter values are stored internally as cm. Any other unit must be converted. That introduces very small inaccuracies, which will produce the wrong value for a function like floor, which is sensitive to small changes.

I recommend rounding the argument to 8 decimal places:

result = Floor(Round(num / denom, 8))

[HermJan.Otterman]

Thanks for your answer Mike.

I can imagine that conversions may cause rounding inaccuracies, but from cm to mm is shifting the comma one place...??!!... but ok.

why is this happening only with the three and the six? and not with the other numbers as you can see in the screenshot that Leon Send?

(in vb.net I don't have these problems)

I will (have to!) use your work methode, and round the values, before using any other math functions like "floor"

I hope you can come back with an answer on why the answer in a parameter is different than in iLogic. thanks in advance

[MjDeck]

To address your statement:
> (in vb.net I don't have these problems)

Please see the attached .vb file. It converts units to cm and back, in a way that's similar to what Inventor does. If you try it out, you'll see inaccuracies in the result of the Floor function.

Note that you don't have to round before using all math functions. Floor is particularly sensitive to round-off error. A very small change in the input can result in a large change in the output value.

[HermJan.Otterman]

Hello Mike,

I'm running jet into an other verry strange problem that also looks like it have to do something with rounding values.

there is a difference between writing ELSE IF and ELSEIF ....... look at my screencast.

by rounding the value the ELSE IF works fine...?

I'm a bit confused...

(I used Inventor 2017)

[MjDeck]

HI Herm Jan,

 You're right: this is a iLogic defect. Thanks for finding it. We should be able to fix it in a future release.
Here's what's happening: to support comparison of double-precision real numbers in the presence of round-off errors, iLogic uses its own DoubleForEquals data type. But it's failing to do the comparison with DoubleForEquals when Else If is used. Instead, it's using the standard Double type. Because of unit conversion, Double will fail the equality test in this case. I would recommend using ElseIf instead. ElseIf is more common in VB.