More fun with equations

Now this is wierd. Enter the following equations in the Equation
Manager:

"A"= 1
"B"= 0.125
"C"=0.5
"D"=IIF("A" > 0, "C"-2*"B","C")
"E"="D"

The first four work just fine. But that final simple equation
doesn't. If SW has a valid value for "D", then why won't it calculate
"E"? Disclaimer: The equations were simplified for clarity.

(That noise you hear is me pulling my hair out).

 

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.

 

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.

 

Interesting. It seems that any multiplication (maybe other functions

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?

<rant>
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.
</rant>

 

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

* http://en.wikipedia.org/wiki/Per_se_(phrase)

 

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