AngrySamsquanch
New Member
How would I go about multiplying a distance by a count. I get a dimensionality not valid error.
Multiplying different types equation editor
- Thread starter AngrySamsquanch
- Start date
AngrySamsquanch
New Member
Thanks, I couldn't find info about that anywhere. Just like casting in programming.
gwbruce
Senior Member
@Ex Machina was the one who explained it to me. @AngrySamsquanch check out the attached file. He sent it to me to help me with some stuff.
Ex Machina
Senior Member
Thankss for the shout out, Gary! And if I am not sorely mistaken, the original author of the article is @DavidJ.
NateLiquidGravity
Alibre Super User
Be especially careful to check the results of any functions too. This one was driving me mad less than a week ago:
Model display units were set to inches.
sqrt(9) = 1.1811" Wrong and no error displayed.
sqrt(9") = 1.8824" Wrong and error displayed "Dimensionality Not Valid".
sqrt(3"^2) = 1.7321" Wrong and no error displayed.
sqrt(MyScale) = 1.1811" Wrong and error displayed "Dimensionality Not Valid". MyScale was a scale value = 9
sqrt(MyCount) = 1.1811" Wrong and error displayed "Dimensionality Not Valid". MyCount was a count value = 9
sqrt(9)*1" = 3" Yields the correct answer but only after tricking Alibre Design to do it.
sqrt(3"*3") = 3" Yields the correct answer.
Now obviously I was not doing such simple square roots. These values were only to test after I discovered the error using different values.
I personally consider that a big bug.
Model display units were set to inches.
sqrt(9) = 1.1811" Wrong and no error displayed.
sqrt(9") = 1.8824" Wrong and error displayed "Dimensionality Not Valid".
sqrt(3"^2) = 1.7321" Wrong and no error displayed.
sqrt(MyScale) = 1.1811" Wrong and error displayed "Dimensionality Not Valid". MyScale was a scale value = 9
sqrt(MyCount) = 1.1811" Wrong and error displayed "Dimensionality Not Valid". MyCount was a count value = 9
sqrt(9)*1" = 3" Yields the correct answer but only after tricking Alibre Design to do it.
sqrt(3"*3") = 3" Yields the correct answer.
Now obviously I was not doing such simple square roots. These values were only to test after I discovered the error using different values.
I personally consider that a big bug.
But dimensionally the sqrt of a distance is meaningless. In real life we often ignore dimensionality/units when it suits us and just use the raw number, Equation Editor always takes note of dimensionality.
Also note that internally the calculations are all done in cm for distances. So unless dimensionality is all good, and hence the conversions pan out, you can get seemingly weird values.
I won't debate whether the EE should be as pedantic, I just explain why it behaves as it does.
Also note that internally the calculations are all done in cm for distances. So unless dimensionality is all good, and hence the conversions pan out, you can get seemingly weird values.
I won't debate whether the EE should be as pedantic, I just explain why it behaves as it does.
NateLiquidGravity
Alibre Super User
Why is sqrt(3"^2) wrong then?
Alibre can try to be more user friendly and output results as expected - or they can adhere to archaic obscure methods with obtuse nonsense results.
Alibre can try to be more user friendly and output results as expected - or they can adhere to archaic obscure methods with obtuse nonsense results.
Last edited:
As mentioned in my original note, the amount of 'stuff' you can do in a single cell in Alibre is limited - so you have to break it down with intermediate steps to get the 'expected' behaviour
(I'm not suggesting that is 'good', just the way it currently is and I have requested improved abilities in that regard).
I disagree that dimensionality is nonsense. If you want to ignore dimensionality you can convert lengths to scale values by (in this example) dividing by 1", then do the calculation with the scale values.
A spreadsheet such as Excel works with raw numbers, it has no idea of dimensionality - this is both good and bad. It's very flexible and allows you to do almost any calculation you want, but there are no checks as to whether the result makes physical sense.
(I'm not suggesting that is 'good', just the way it currently is and I have requested improved abilities in that regard).
I disagree that dimensionality is nonsense. If you want to ignore dimensionality you can convert lengths to scale values by (in this example) dividing by 1", then do the calculation with the scale values.
A spreadsheet such as Excel works with raw numbers, it has no idea of dimensionality - this is both good and bad. It's very flexible and allows you to do almost any calculation you want, but there are no checks as to whether the result makes physical sense.
NateLiquidGravity
Alibre Super User
Sorry, I meant to say "archaic obscure methods with obtuse nonsense results." I've fixed that in my post.
Toybuilder
Senior Member
I was playing around with this issue recently and found that a scale value can be derived from a count; and then the scale can be used to multiply distance:
I'm not sure that it's necessarily the best way, but it seemed to work for my purposes.
I'm not sure that it's necessarily the best way, but it seemed to work for my purposes.
bolsover
Senior Member
I know this has been discussed before but personally, I'd much rather Alibre did not use dimensionality.
My guess is that internally, Alibre uses Double, Integer and Boolean values with maybe the odd Floating point number for special occasions.
I am quite able to convert from degrees to radians, inches to mm and pounds to Kg - I just don't get any value from the EE enforcing dimensionality.
David
My guess is that internally, Alibre uses Double, Integer and Boolean values with maybe the odd Floating point number for special occasions.
I am quite able to convert from degrees to radians, inches to mm and pounds to Kg - I just don't get any value from the EE enforcing dimensionality.
David
Toybuilder
Senior Member
AFAIAC, I don't mind having separate count and dimension types -- but count being unitless, I feel like I should be able to do N*D and have it be valid. I can explicitly specify an integer like 2*D and it's fine, so why not let a count multiply (or divide) distances?
stepalibre
Alibre Super User
The equation editor is designed to work with features and is not meant to be a freeform variable editor. I've noticed it does require significantly more parameters because of dimensionality, where in a more open editor you could have combined formulas reducing the number of parameters. Equations with types is more efficient to calculate/regen/update especially in configurations and design libraries. There is a close relationship between the equation editor, parameter types, configurations and the design library system that is driving the enforcement of dimensionality.
Example:
This all make sense in the context of building design libraries and configurations where the end goal is to have a dynamic model. Parameter types help map the data. It would otherwise require a more complex database system to map everything over. It is greatly simplifed in Alibre compared to SolidWork's Toolbox or Inventor's content center. I use Smath Studio, Excel and code when the equation editor is not enough or when I prefer to have math live outside of Alibre. Using the API you could implement your own frontend to the Parameter API removing or adding parameter types, handling the details in your custom code. Everything is cm or unitless internally, the parameter types only matter to features where they are used. Nothing in the API restricts how you treat parameter values.
Example:
This all make sense in the context of building design libraries and configurations where the end goal is to have a dynamic model. Parameter types help map the data. It would otherwise require a more complex database system to map everything over. It is greatly simplifed in Alibre compared to SolidWork's Toolbox or Inventor's content center. I use Smath Studio, Excel and code when the equation editor is not enough or when I prefer to have math live outside of Alibre. Using the API you could implement your own frontend to the Parameter API removing or adding parameter types, handling the details in your custom code. Everything is cm or unitless internally, the parameter types only matter to features where they are used. Nothing in the API restricts how you treat parameter values.