Integer Function Bug

By the way, I used SW2005 SP4.0 to create this example.

I have a problem with the integer function in equations. The problem is that when an equation evaluates to a whole number the integer function is rounding it down. A pdf showing the steps and the associated model can be downloaded with the following links.

PDF

SW model

I have also tried this same model in SW2006 and it performs the same way. Can anyone double check this reply to the group what they find?

Thank you

Mark

Yep, Sure enough. Same thing here SW 2005 SP 3.1 (because I can't 4.0 to load). Very odd!

I have a problem with the integer function in equations. The problem is that when an equation evaluates to a whole number the integer function is rounding it down. A pdf showing the steps and the associated model can be downloaded with the following links.

PDF

SW model

I have also tried this same model in SW2006 and it performs the same way. Can anyone double check this reply to the group what they find?

Thank you

Mark

Cliff

The problem is that when the result of the equation is a whole number integer the integer function should not change the result and that is what is happening.

if you want to "round to the nearest integer" then round = integer(number+.5)

I have a problem with the integer function in equations. The problem is that when an equation evaluates to a whole number the integer function is rounding it down. A pdf showing the steps and the associated model can be downloaded with the following links.

PDF

SW model

I have also tried this same model in SW2006 and it performs the same way. Can anyone double check this reply to the group what they find?

Thank you

Mark

This is correct. Int() simply strips any fractional values off. Use:

Round(expression [,numdecimalplaces])

After rereading your post, I see the problem is not explicictly the need for the round function instead of int. If I set up a simple example (05sp4.0), it works as you would expect. Int(10) returns 10. Int(9.5) returns 9. However int(9.999999) returns 9 even though the input appears as

10 in SW.I think you need to replace int with int(round(,4)) where 4 is the desired rounding precision.

I just tried your file on SW2005 SP4.0 with the same results. So I tried a simple test piece with one equation and it performed properly with or without the INT function. I don't have time to really break this down, but maybe you have a circular reference happening that is forcing an evaluation differently that what it appears it should be. Try turning off one equation or something, etc.

WT

I have a problem with the integer function in equations. The problem is that when an equation evaluates to a whole number the integer function is rounding it down. A pdf showing the steps and the associated model can be downloaded with the following links.

PDF

SW model

I have also tried this same model in SW2006 and it performs the same way. Can anyone double check this reply to the group what they find?

Thank you

Mark

The issue in this case is that I don't want the result to be rounded. I want the integer value even if the result is 3.99999.

Mark

Wayne Tiffany wrote:

simple test piece with one equation and it performed properly with or without the INT function. I don't have time to really break this down, but maybe you have a circular reference happening that is forcing an evaluation differently that what it appears it should be. Try turning off one equation or something, etc.

that when an equation evaluates to a whole number the integer function is rounding it down. A pdf showing the steps and the associated model can be downloaded with the following links.

Can anyone double check this reply to the group what they find?

A whole number in decimal or base2? The computer is thinking in base 2 while you are thinking in base 10.

Okay, I just typed a big long reply about this that didn't get posted and was lost, so here's something close:

In SolidWorks, numbers are stored internally in a base 2 floating point format (probably double precision IEEE because that's what's exposed in all their API calls) which has inherent limitations in the accuracy of computation. Actually our base 10 representation also has errors, but we don't notice those so much, and when the computer produces a different answer from the "obvious" base 10 approach we cry foul. For example, one tenth (0.1) does not have a finite representation in base

1. So if you add it together 10 times, you get a number slightly less than one. Try this in a macro:

x = 0.1 MsgBox 1 - (x + x + x + x + x + x + x + x + x + x)

What's that? 1x10^-16 or so? So you see that it's not quite 1. This is a little problem because in the UI it's impractical to show

0.999999999999999, so it just shows 1. But then you call the integer function on that number, and you get zero because that's what's stored internally. It's not a bug in SolidWorks, but it is just one of the limits of numerical computation.

You can't eliminate this error, but there are some principles and methods you can follow to reduce it. For more information on the binary representation as well as a few good links at the bottom, look at

may also try searching on numerical analysis.

Jonathan Anderson

Thank you for the in depth description. I figured it had to do with what you described. If someone wasn't paying attention to the results this type of error could be costly. Anyway thanks for the input.

Regards

Mark Downey

I just went back to the model to try adding rounding to the equation and it is not available; go figure. I reviewed the equation again and I am confused as to why (19.625-7.625)/3=12/3=4 would evaluate to 3 when the integer function is applied. When I enter the equation int(12/3) the result comes out as 4. Even the equation int((19.625-7.625)/3) evaluates to 4 when it is entered as numbers but when the dimension values are used the result is different. It just doesn't make sense!

Mark

Rounding _is_ available in equations. The little calculator-editor only scratches the surface of what equations can do. Equations use VB functions and syntax. So, just about any arithmetic operator in VB can be used, such as rnd() for random numbers. (It also has the same limitatins. You won't find a secant function, for example.)

Here's an equation I just tested:

"D2@Sketch1" = INT(ROUND("D1@Sketch1",3))

This returns 15.000 for D2, even if I set D1 to 14.999999999.

Dale

Thank you for the clarification. I had tried RND instead of ROUND. I didn't see any options in the help menu so I didn't go any further. I like this solution and will definitely use it in the future.

FYI. I built the same equation using variables in Excel and the result from the INT function came to 4 instead of 3. There must be a difference in the precision levels somewhere.

Thanks again for the feedback and assistance.

Regards

Mark Downey

Dale Dunn wrote: