How to strip the units from a length?

jackson_king

Hi All,
Is there a way to strip a length of it's units so the decimal number can be used in a "ceil(#/#)" equation?

I am trying to use configs to create an expanded metal/grating generation part studio and have it working well except for getting the desired sheet size to auto size.  I am using measure distance FS to get the lengths and widths for the distance of the pattern and am trying to use that measure distance number in the ceil function to drive the instance count. In this case, ceil(#Desired_Length/#Length) or ceil(#Desired_Width/#Width).

Here's the document:
https://cad.onshape.com/documents/07f282dcddf2935fa6750b71/w/2c0dd72f79a3f141eac8e0ae/e/de6fa0c8db0a64009288fb77

Thanks in advance!
Jackson

Jake_Rosenfeld

@jackson_king

You don't need to strip the units at all! A length divided by another length is just a number, so the expression you've proposed is perfectly fine.  It looks like you haven't tried it out yet, give it a shot in your document and it should work.  (I tried it myself and set one of the pattern instance counts to 'ceil(#Length/#Width)' and it worked as expected):
https://cad.onshape.com/documents/81e1def03ed3ef2f11e46393/w/cb6c92ffab42a4ee16d61ecc/e/cdd309359c16357ecef84025

ilya_baran

A better way of doing this is dividing by the unit.  If you want the number of inches in #length, use #length / in
Getting the value like @konstantin_shiriazdanov proposed will always give you the length in whatever internal units we're using, which may not be what you want.

Jake_Rosenfeld

@jackson_king

You don't need to strip the units at all! A length divided by another length is just a number, so the expression you've proposed is perfectly fine.  It looks like you haven't tried it out yet, give it a shot in your document and it should work.  (I tried it myself and set one of the pattern instance counts to 'ceil(#Length/#Width)' and it worked as expected):
https://cad.onshape.com/documents/81e1def03ed3ef2f11e46393/w/cb6c92ffab42a4ee16d61ecc/e/cdd309359c16357ecef84025

jackson_king

Thanks @Jake_Rosenfeld!  I was testing things before submitting the question and never had it as a #variable/#variable, just a number/#variable.  What you said makes perfect sense and it works!

jackson_king

@Jake_Rosenfeld, is there a way to remove the units if I needed too? 
Jackson

konstantin_shiriazdanov

value with units has internal structure of map type, so #length.value should give a unitless number

ilya_baran

A better way of doing this is dividing by the unit.  If you want the number of inches in #length, use #length / in
Getting the value like @konstantin_shiriazdanov proposed will always give you the length in whatever internal units we're using, which may not be what you want.

jackson_king

Thanks guys! It all works well now. I think my next attempt should be turning this thing into featurescript. Which should be interesting as featurescript and I don’t see eye to eye on things sometimes. 
Jackson

EvanReese

ilya_baran said:

A better way of doing this is dividing by the unit.  If you want the number of inches in #length, use #length / in
Getting the value like @konstantin_shiriazdanov proposed will always give you the length in whatever internal units we're using, which may not be what you want.

How might I approach this in Featurescript if I don't control which units the user selects? 

alnis

@Evan_Reese not sure if this is quite what you'd want, but for user inputs, could you have a length parameter and dropdown for units?

Jake_Rosenfeld

@Evan_Reese

It might be easier to answer if we had additional detail about what your user inputs are and what you are trying to do with them

EvanReese

alnis_smidchens said:

@Evan_Reese not sure if this is quite what you'd want, but for user inputs, could you have a length parameter and dropdown for units?

That's a good suggestion. That would get the job done, but my intuition is instant that there's a less kludgey way... or at least one where the user doesn't have to be aware of the kludgeyness. On the other hand, the fact that there doesn't seem to be an obvious answer probably indicates a deeper issue with my whole approach.

As a learning exercise, I'm trying to plot points to a sine wave like this:

y = amplitude*(e^(-decay/100*x))*cos(x*frequency*degree)+amplitude;

Amplitude, frequency, and x are all valueWithUnits (lengths), and I think that's what I want, but cos() wants an angle, not the unit mashup I have. Should I change all of them to just values? if so, how do I get the right units without the user having to think about it?

Jake_Rosenfeld

@Evan_Reese

Issues with units usually indicate an issue with the equation itself; if you were solving this equation on paper for a given x value, you would expect all the units to cancel appropriately to give you the right answer.  So to tackle it in parts:

(e^(-decay/100*x)): this is a scale factor, and should be unitless.  Since `x` is a distance, I would expect `decay` to be in distance units, describing how far along the x-axis you want this scale factor to be (e^(-1/100))

cos(x*frequency*degree): As this is right now, I would expect "frequency" to be in inverse distance units (i.e. "1 / distance"), and that (frequency * degree) forms a statement of "for every (1 / frequency), the cos wave changes by one degree".  I do not think this is the intention, it seems that you are having the user supply "frequency" meaning "how frequently does the cos wave pass through a full cycle".  In which case the correct equation would be: cos(x*(360*degree/frequency)); and you will see here that that the units just fall out correctly, without having to strip anything of its units.

EvanReese

Jake_Rosenfeld said:

@Evan_Reese

Issues with units usually indicate an issue with the equation itself; if you were solving this equation on paper for a given x value, you would expect all the units to cancel appropriately to give you the right answer.  So to tackle it in parts:

(e^(-decay/100*x)): this is a scale factor, and should be unitless.  Since `x` is a distance, I would expect `decay` to be in distance units, describing how far along the x-axis you want this scale factor to be (e^(-1/100))

cos(x*frequency*degree): As this is right now, I would expect "frequency" to be in inverse distance units (i.e. "1 / distance"), and that (frequency * degree) forms a statement of "for every (1 / frequency), the cos wave changes by one degree".  I do not think this is the intention, it seems that you are having the user supply "frequency" meaning "how frequently does the cos wave pass through a full cycle".  In which case the correct equation would be: cos(x*(360*degree/frequency)); and you will see here that that the units just fall out correctly, without having to strip anything of its units.

At least I was right about being wrong . my algebra has never been the best. Thanks for the rundown, I'll self-educate more.

ilia_mazlov

Hey! Not sure if I'm doing something wrong here or it's just a bug, but variable doesn't work in helix "target revolutions": niether it works with #BaseHeight / 1.5mm nor with #BaseHeight / 1.5, nor with just a single #BaseHeight.

_anton

ilia_mazlov said:

Hey! Not sure if I'm doing something wrong here or it's just a bug, but variable doesn't work in helix "target revolutions": niether it works with #BaseHeight / 1.5mm nor with #BaseHeight / 1.5, nor with just a single #BaseHeight.

This expression is equivalent to (#BaseHeight / 1.5) mm because, if it worked differently, you'd be unable to write, say, 1/2mm.

Simplest fix is something like #BaseHeight / (1.5mm).

jelte_steur814

@Evan_Reese
Like @Jake_Rosenfeld said; "Issues with units usually indicate an issue with the equation itself".

This is very true so probably you'd want to avoid having to use this. But just to satisfy my curiosity i had to think it through.

Because in isLength parameters, users are free to input e.g. this: "(100 millimeter * 1 inch )/ (0.1 meter)".
So what would the unit be?

If you'd ever want to use such a function, I think an isReal parameter with a Unit Enum would be the only way to go.
Users are then still free to use expression to come to the number value. (but it has to be unitless)
 Inside the feature, a multiplication of the unit with the parameter would create the valueWithUnits.

ilya_baran

@jelte_steur814
The result of your expression is a length, which can be shown in any length units.  Onshape will use the length units specified in your workspace to show the value.  I think the thing that people seem to find a little hard to digest is that "1 in" and ".0254 m" evaluate to the exact same length value -- it doesn't matter what units were specified in the expression; what matters is the represented length.

jelte_steur814

@ilya_baran. Agree. And my point is that you cannot derive from inputs what Unit the user was thinking/intending/inputting because it can be a mix as long as it evaluates to a lenght.

ilia_mazlov

@_anton thank you for giving this advice, now I see that the "units operator" is applied after meth operators. Thank you very much!

ilia_mazlov

_anton said:

ilia_mazlov said:

Hey! Not sure if I'm doing something wrong here or it's just a bug, but variable doesn't work in helix "target revolutions": niether it works with #BaseHeight / 1.5mm nor with #BaseHeight / 1.5, nor with just a single #BaseHeight.

This expression is equivalent to (#BaseHeight / 1.5) mm because, if it worked differently, you'd be unable to write, say, 1/2mm.

Simplest fix is something like #BaseHeight / (1.5mm).

I haven't noticed low "units operator" precedence. Thank you very much, the parentheses works like charm!