Attack of the DoubleForEquals

[MegaJerk]

Well... Maybe I shouldn't blame DoubleForEquals. 

No matter, I'm still having a hell of a time with what I thought was some pretty basic floating point conversion (for Inventor). 

Attached is a part (2012 - so that everyone should be able to open it) that has few userParameters inside of it that I've made for this demo. 

Essentially, the expression 

(testParameter1 - (testParameter2 + (testParameter3*2))

 when used inside of iLogic, will evaluate to a very very non-precise number if I'm using a real number 440.0625 and up*. 

This wouldn't be a problem at all if I could just evaluate it inside of the parameters (as I have done in testParameter4), however I need to use iLogic to 'logic' some other factors and then use the above expression or a different one. NO matter, using a parameter that is 440.25 inside of any iLogic expression results in bad things happening. 

Is there anyone out there who might know why this is? I've never ran into an issue using smaller numbers, and the reason I put that little red (*) up there was because I later found out that that statement was false. Using values like 1440.25 (which would, in the expression above become : 

(1440.25 - (1437.25 + 3))

will evaluate down to 0 with no problem. It's only certain numbers, in certain rangers that really really mess with Inventor, and I can't figure out why!!!!

If you have no idea what on earth I'm talking about, please download that part and see for yourself. You'll also notice some commented out code, which contains various other tests and ways of getting around the limitations of how iLogic seems to be parsing things, but most of those would seem rather redundant if there is some easier way to achieve precision. 

Thank you all for your help! 

[BrandonBG]

It appears to be a problem with the units -- probably some kind of Inventor conversion to centimeters.

If I change the User Parameters to unitless, everything works fine.

I don't get it.

BrandonBG

[MegaJerk]

It's very very strange. 

At first I suspected that because DoubleForEquals stores things as if they were singles (7 digits instead of 15), despite resolving to Double, it was causing an obscure overflow / underflow error, but turning it off (assuming that that option even works... I'm not really sure if that's testable), doesn't do a darn thing. 

Being that these are relatively sane numbers, I'm not really sure why I don't see more threads on stuff like this, and it makes me suspect that something is broken. I mean, people make assemblies and parts far larger than 400" from what I've seen, so this shouldn't be an extreme case. 

The last perplexing thing is the fact that as I stated in the previous post, it only happens to certain numbers in certain ranges. At some point in the future I plan on dumping a log to see just which numbers end up getting screwy to maybe establish a pattern. 

If anyone else would like to test (especially those of you who make big stuff) it would be interesting to see what the results would be if you just recreated all of the parameters without using the provided part. 

Maybe some redistributable package has changed how the iLogic internals are evaluating things. 😕 

[BrandonBG]

Here's my own example of something that probably should be ZERO, but isn't.

Dim oDrawing as DrawingDocument
oDrawing = ThisDrawing.Document

Dim oSheet As Sheet
oSheet = oDrawing.ActiveSheet

Dim oView As DrawingView

While True

oView = ThisApplication.CommandManager.Pick(SelectionFilterEnum.kDrawingViewFilter, "Select view to display Camera.UpVector. ESC to end.")

If IsNothing(oView) Then Exit While

oParentView = oView.ParentView
MessageBox.Show(oView.Camera.UpVector.X & ", " & oView.Camera.UpVector.Y & ", " & oView.Camera.UpVector.Z, "VIEW " & oView.Name & " UpVector(x,y,z)")

End While 

I'm using the standard projected views. Start with a base view which has an UpVector of (0,1,0) [(x,y,z)]. However, the UpVector on up/north and down/south projections are (0, 2.96651592179842E-13, -1) and (0, 2.96651592179842E-13, 1). They *should* be (0,0,-1) and (0,0,1).

BrandonBG

[MegaJerk]

Ah, Camera fun!

I recently also had some terrible issues with the Camera as highlighted here : How to Crash Inventor

If you were to re-work some of that code to VBA, you could very easily step through the code to see where and when it overflows the Double container of the Camera. I’ll have to mess around with your code later to see if I get similar results.

Anyone else out there having fun math problems with inventor?

[xiaodong_liang]

Hi,

I opened this test *.ipt in Inventor 2016. When running the iLogic rule, it pops out the result 0 with the dialog title 'Parameters ONLY = CORRECT!!', which looks fine to me. i.e. the code evaluates the equations correctly.

Could you elaborate this problem with any snapshot, video that can help me better understand? or it occurs with specific version?

btw, when you said ' if I'm using a real number 440.0625', i believe you actually meant by '1440.0625' because testParamerer1 = 1440.0625 in.

[MegaJerk]

Yeah. Sorry. I thought that I had it set to 440.0625 default, and not the 1440.0625. I actually had intended it to be the lower value which results in bad things happening.

I have included screenshots of the behavior

[rjay75 · Accepted solution]

Seems to be something with translating the values from Inventor to iLogic. A rounding issue happens that gives a really small not quite 0 value. Here's some of the different tests I did.

SyntaxEditor Code Snippet

tp4 = TP1 - (TP2 + (TP3 * 2 ul))
MessageBox.Show("Value of TP4: " & tp4)

MessageBox.Show("From Equal Tolerance 0 " & EqualWithinTolerance(tp4, 0, 0.001))

MessageBox.Show("From Numbers Direct: " & (440.25 - ((440.25 - (1.5 * 2)) + (1.5 * 2))))

Dim uom As UnitsOfMeasure = ThisDoc.Document.UnitsOfMeasure

MessageBox.Show("From Expession: " & uom.GetValueFromExpression("TP1 - (TP2 + (TP3 * 2 ul))", "in"))

tp1 = Parameter.ValueForEquals("TP1")
tp2 = Parameter.ValueForEquals("TP2")
tp3 = Parameter.ValueForEquals("TP3")

MessageBox.Show(String.Format("From Values: {0} - ({1} + ({2} * 2 ul)) = {3}", tp1, tp2, tp3, tp & tp1 - (tp2 + (tp3 * 2))))

I also tried it outside of Inventor to see what happens.

Not necessarilly caused by double for equals but seems to be some type of floating point precision issue happening. Use EqualsWithinTolerance when using paramater values to ensure proper rounding is happening.

[xiaodong_liang · Accepted solution]

Hi,

i can reproduce thi issue now. And I agree with the analysis that rjay75 shared in message 8.I have not found a workaround, but have logged this issue with our engineer team:
TFS- 97290

[MegaJerk]

Thank you so much for confirming / reporting this, and a big thank you to everyone who helped test this in various ways!!!

This is rather critical (at least for us), so it is helpful to have that bug / tracking info.

Later on today, I will make another topic about a different internal Inventor math issue that can result in a full-on crash! Exciting!

Again, thank you to everyone!

[MjDeck]

DoubleForEquals stores numbers and does all math operations in double precision (15 decimal places). But it does comparisons in single precision (7 decimal places). The reason for doing comparisons that way is to hide the effects of round-off error.

Here's some VBA code that demonstrates the problem, without using Inventor or iLogic:

Sub PrecisionTest()
 
 Dim d1_in_inches As Double
 d1_in_inches = 440.25
 
 Dim d1_in_database As Double
 d1_in_database = d1_in_inches * 2.54
 
 Dim d1_converted_back_from_database As Double
 d1_converted_back_from_database = d1_in_database / 2.54
 
 Debug.Print ("Round-off error = " & d1_converted_back_from_database - d1_in_inches)
 
End Sub

All dimensions are stored in the Inventor database in units of cm. The conversions that put it in and get it out of the database both introduce some round-off error.

You can reduce the error in calculations in iLogic rules by using Decimal instead of Double.