More fun with equations

Can't explain it - does the same thing here, but why not just use "D" wherever you were going to use "E"?

WT

Perhaps try something like:

"E" = Val("D")

-or-

"E" = Cdbl("D")

Or maybe...

"E" = 1.0 * "D"

Or maybe "E" = ("D")

"E" = "D" was a simplification. The real equation was "Offset1_Sketch2"= (2 * tan(5) * ("OverallHeight"-"StackOverlap")) + "WallTopWidth"

"E" = Val("D") - Evaluates to 0 (an incorrect value)

"E" = Cdbl("D") - Doesn't work

"E" = 1.0*"D" - Doesn't work

Changing "D"=IIF("A" > 0, "C"-2*"B","C") to "D"=IIF("A" > 0,( "C"- (2*"B")),"C") works with all of the above! Still doesn't answer why SW calculates a correct value for "D", but can't use it.

Here's a good one.

"a"=100*360/500

The "100" can be any number > 92 and the /500 is actually irrelevant.

95*360 fails all on its own.

Got a really lame explanation from VAR on this one. Some BS about SW trying to save memory useage.

On Feb 14, 1:49 pm, "Brian" wrote: > Here's a good one. >

Interesting. It seems that any multiplication (maybe other functions too) that results in a value >= 32768 fails. That number is 2^15. Seems to close to some sort of 16 bit limit to be a coincidence.

The equations are actually evaluated by VB after a little internal massaging by SW. That's why you can use some VB functions in equations. 'Way back in 99 or 2000 or thereabouts you could see some of it action during certain macro editing problems.

It may be that your examples are being evaluated as integers, since there are no decimals specified. I just tried it in 06 and got this:

"a"=100*360/500 fails "a"=100.0*360/500 returns 72

Hmm. I'll have to remember that. It could be dangerous. I wouldn't call it a bug though, because there are situations where I might want to do integer math in an equation (# of pattern instances, etc.).

Don't think its an integer thing, else 1/3 would not evaluate to

0.333333 . I was aware of adding .0 to have it evaluate properly. However if your equation were instead : x = a*b and your driven values for a and b meet the criteria , it still fails. Which is how I discovered it in the first place. IE 99.0000+1.0000 evaluates to a value of 100 , not 100.0000. Dropping the trailing zeroes, and passing the integer value along for further processing.

This issue has to do with something called casting.

100*360/500 results in a value that is an integer. Therefore VB will cast the problem in short integers witha 32k cap. Since 100 * 360 exceeds that cap and is evaluated before the division the calculation dies. I suspect that if the operation is grouped like this:

100*(360/5)/100 it would succeed since none of the intermediate values would exceed 32k and it would still be cast as an integer operation.

1/3 works because VB is forced to cast it as a floating point problem. 100*360/500 doesn't work because VB is casting it as short integers. This is where the comment from the VAR about SW saving memory comes in since a short integer uses less memory than a long integer and this is a good thing to know about. The whole thing strikes me as funny since just about every API example SW provides casts integers as long explicitly.

The next test would be to see whether SW is using single or double precision in it's floating point operations.

Based on what has been said here, and the slowness of equations in general, I think that it's fair to say that SW equations are totally fubar. Sad that such a valuable and important feature can't be relied on. Once again, they need to fix what is already in SW and stop adding more at least for a little while.

Ok, so I was in the ballpark, anyway... Would it be safe to say that adding a decimal point as a sort of informal type declaration should ensure correct evaluation?

Still, I would say that stricly speaking, it's not a bug. It IS a hole that we can fall into, and I hope they close it if they ever get around to overhauling equations (which I've been wanting since I started using SW). I would also say that it was a bad call on the part of the developer who decided to make it this way. Saving 16 bits of memory per integer seems like nothing compared to any other calculations SW does, even on the memory constrained systems SW was first developed for.

This may not be a coding bug but it is most certainly a design bug. It is reasonable to expect the equation 100*360/500 to evaluate correctly. It is a design flaw of the worst kind for it not to. In a programming environment it is reasonable to expect the user to pay attention to type and to know where and when to be explicit. In a cad/ modeling environment where the type decision is more often than not out of the users control it is an unforgivable design flaw for this to not work as a reasonable user would expect. As has been mentioned earlier in this thread; this is not the place to save bytes or cpu cycles. We use computers for modeling and design because they are quicker and more editable than paper and pencil and most importantly because they are more accurate. This kind of program behavior once discovered will cause the user to be wary of its accuacy and foster a need to validate every little thing the program does. This wastes alot of time and brings into question whether or not any model is truly accurate.

Kevin,

It would certainly seem that SolidWorks is on the wrong side of the saving bytes fence. With 2007 taking up as many gigabytes as it does and VISTA requiring about ten times the disk space that XP required maybe a little machine language on the part of the programmers would be in order, but for the ordinary user you are absolutely right that saving bytes by casting the values in a equation to short is bound to lead to errors, especially when this is not explicitly pointed out in the help.

I certainly don' t think user's have to worry about accuracy per se*, but rather programming mistakes. This just goes to emphasize that you shouldn' t assume anything with any program until you verify it. This is stated in the SolidWorks EULA in one way or another.

TOP

• formatting link

I love those EULAs. I wonder how long any of the companies that we work for would last if we told our customers the widgets we design "may work for what we designed them for, but you better test it because we won't stand behind the design even if the problem is a horrendous mistake on our part". Not long, I'd wager.

Sounds like this is one of those executive decisions in programming that just needs to get fixed NOW.

Bo