Bug - CC expression evaluator gets confused when units end up in denominator

I set up a project in mm, stock is 100x100. Size doesn’t matter.

Create a rectangle, then edit its properties.

  • I can set the width to 3in, this works and is converted to 76.2mm, correct!
  • I can set the width to 90/2, converted to 45mm, correct!
  • 3in/2 → 38.100mm, correct
  • 3/2in - 0.059 mm ???, I expect the same as previous.

It appears units are binding very early, but if they end up as the denominator I think it needs to bind ‘outwards’ until it’s on top.

1/in is accepted, but treated at 1mm
1/1in is 0.039 mm, i.e 1/25.4.

Another issue - units and parentheses don’t work well together
(3+1)/2in - expect 50.8mm, get 0.079
(3+1)in/2 - expect 50.8mm, get ERROR
(3+1)in - ERROR
(3in+1in)/2 - correct.

This all makes sense to me (I think). All numbers without a unit declared are treated as mm in your first post.

The second post also makes sense: same , all numbers without a unit declared are treated as mm. (3+1)in is treated as (3mm+1mm)in which is what?

4 Likes

Any value without a forced type case will defaults to set default, in this case mm.
Therefore:
1:(3+1)/2in
(3mm+1mm)/50.8mm
(4mm)/50.8mm = 0.0787 mm

2: (3mm+1mm)in/2mm would create an error
3: (3mm+1mm)in same error situation. The numbers were told they are in mm, then I assume you now want to “convert” the answer in the () to inches, which would be a function not a decoration ( type cast ) It only converts the preceding number before it does any calculations. You cant convert a “)” to a number prior to doing any calculations. Think of it as a pre calculation before it does math

4: (3in+1in)/2
(76.2mm + 25.4mm)/2
(101.6mm)/2 = 50.8mm

hope that helps

It seems the expression evaluator is playing pretty fast and loose with units, and that makes it hard to understand what it’s doing.

If each number has an implicit attached unit, then 3/2 is not 1.5mm is just 1.5. It’s unitless. That’s wrong of course, we want the whole expression to have units of mm (or inches, whatever the project it in).

In reality, it appears that the “units” are actually implicit multipliers, the numbers themselves have no units, and then the resulting value is accepted as the number of units of the project. Also, as implicit multipliers, they bind more tightly than explicit mutiplcation or division. Except when they don’t (i.e., parentheses).

It seems the rule is really “Units bind to the number to the left and are immediately converted to the equivalent number of units of the project. The unit is discarded, all math is unitless, and the final result is interpreted in the units of the project”.

With no unit it assumes the default as set up in Settings>>Job setup >> Units

You are correct it does not say in the field. The unit is displayed next to the field
and all units in the field are in the default unit unless it is explicitly overridden.
You are correct you can think of it as each number has a unit assign to it. If you override or Type Cast the unit for that number, it does a simple conversion to the default unit before it does the math. They only bind to the number and not the operand / function. [ ±/x()^√ ]. It is a very simple pre conversion. Handy though

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.