Page MenuHome

Moving negative imperial units works incorrectly
Closed, ResolvedPublicBUG


System Information
Operating system: Windows-10-10.0.18362-SP0 64 Bits
Graphics card: Quadro M5000/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 388.16

Blender Version
Broken: version: 2.82 (sub 7), branch: master, commit date: 2020-02-12 16:20, hash: rB77d23b0bd76f
Worked: None

Moving an object negative imperial units works incorrectly. Moving an object -X' Y" moves the object negative X feet but positive Y inches. It requires you to type -X' -Y" or -(X'Y") instead which is not how negative imperial units are written.

Exact steps for others to reproduce the error

  • Open blender
  • Click on the splash screen image to make it go away
  • In the scene properties, change the "Unit System" under "Units" to "Imperial"
  • Delete the default cube
  • Add a cube
  • Type "G" type "Z" type "-1" hit "Enter"
  • In the "Operator Panel" on the lower left hand side, type in -1'6"
  • Notice the cube move up 6" instead of down
  • The final position shows as -0.5 instead of -1.5

12 inches = 1 foot
3 feet = 1 yard
1,760 yards = 1 mile

Note: Everything including architectural plans/shop drawing in the US are in imperial units. We are so sorry world.

Event Timeline

I can confirm this behavior, but I don't understand much about imperial unity to understand how it should be.

Analyzing the user_string_to_number function, -1'6" is converted to (-1 * 1 + 6 * 0.0833333313) * 0.304800004
I suppose it should be converted to (-(1*1+6*0.0833333313 ))*0.304800004
But I need to do some research to confirm this.

I suppose it should be converted to (-(1*1+6*0.0833333313 ))*0.304800004
But I need to do some research to confirm this.

As an American, I can confirm that movement of -1.5ft is the expected result when entering -1'6".

Writing it out as -1'-6" (as seen below) makes no sense to me.

I am guessing that it is rare to write -1m50cm in metric, and that writing -1.5m would be more common.
So the fact that -1 m 50 cm and -1m50cm both result in -0.5m might be the expected norm in metric, but I suspect that this too is an odd "Blenderism."

Evan Wilson (EAW) renamed this task from Moving negative imperial units to Moving negative imperial units works incorrectly.Mar 9 2020, 6:29 PM
Evan Wilson (EAW) changed the task status from Needs Triage to Confirmed.
Germano Cavalcante (mano-wii) changed the subtype of this task from "Report" to "Bug".Mar 9 2020, 7:00 PM

In general, I'd suggest to avoid doing anything two clever here, it's fairly likely to back-fire consider users may mix these with Python expressions.
Having said that, both cases look like they could be handled.
For - there could be an implicit conversion from - to -( ... )
The trick would be to do it without breaking statements like
-4 + 0.5 / -1.1

Regarding evaluating
1'6 as 1'6"
this seems simpler, since we could make a rule that ensures the next lower unit type is added if a unit-type was the suffix of the previous number and the next number has none.

Although we might only do this in simple cases, as there are limits to what could be realistically supported.


1'(4+4) to 1'(4+4)" ? - probably not.

1'2.5 to 1'2.5" ... might be reasonable.

For both of these we might want to define a "simple" expression, so if the expression doesn't involve maths / parenthesis, some assumptions can be made.
Although I don't really like this as it means
1'6 might evaluate differently to 2+1'6

Perhaps the same part of the code that replaces ' could do a look-ahead and add the " after the next number.
And try to be robust and support cases like:
10_0.1e-10'9_0.1e+2 to 10_0.1e-10'9_0.1e+2"

Or, we could stop trying to mix Python and unit's as we do now, and instead, only support one or the other.
Only allowing explicit mixing:

{1"2}+{2m3cm} so first we evaluate everything in the {}.
as units. Then pass to Python.

As {...} are used for dictionaries & set's in Python, the chance people want to construct these in a math expression in very low.

In simple cases like 1"2, no need for surrounding by {...}.