Integer Function Bug

Hello Everyone

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

 

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

Mark
Hello Everyone

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

 

Its just giving you the integer bit, as designed, correct?
You probably want the rounding function instead.
There should be one .... I'd expect.

 

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

Muggs
Hello Everyone

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.

Mark

 

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

Bob
Hello Everyone

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

 

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

Hello Everyone

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

 

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
2. 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 http://en.wikipedia.org/wiki/IEEE_floating-point_standard
You may also try searching on numerical analysis.

Jonathan Anderson

 

Mark,
It may be that the result is actually a floating point number,
not an integer, and very slightly less than an exact integer
to the last decimal point *in the computer's storage*,
which is rarely exact (it only has so many bits for
any number, right?)
Try the rounding function.

 

Don't forget to consider storing integers in integer data
types too <G>.

 

DANG !!!
Where was poor jb on this one?
LOL ....

 

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

 

Your dimension values probably have more decimal places internally.
Don't assume.
When you want integer data out use integer functions properly to
get proper results.

 

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

 

Cliff

You may be correct that the decimal places for the dimensions are
carried out further than displayed. The problem I have with that
explanation is that I entered the dimensions to 3 decimal places so why
does SolidWorks have more decimals than what was entered?

Now that I know about the rounding function I can avoid this in the
future.

Regards

Mark Downey

 

All floating point data is stored in a binary floating point
format using X bits.
In addition, if anything was moved/translated .... trig errors
may change things slightly.
Same for angled stuff.
And, if this is associated with anything else, SW *might* be making
small adjustments so that it all comes out right.

HTH

 

This seems a bit odd .....
D2@Sketch1 on the left should be an integer data type but
D1@Sketch1 is a floating type on the right.
Did you get to define/declare D2@Sketch1 as an integer data
type?
BASIC was so long ago ....