ceil() and floor() functions not working properly

[khackbarth]

The ceil() and floor() functions aren't working properly (see "test" and "ceiltest" below).  The correct value for ceiltest should be 11 but instead it is evaluated to 20.  A similar problem exists for the floor() function.

[jhackney1972]

I receive the same error only if I use a variable for the argument and only in the "ceiling" function, "floor" works OK in both instances.  Ceiling works if your apply it directly to the value minus the units.  The units are picked up from the Units column.  You should report this a a bug.

[Phil.E]

Hi,

Thanks this is a bug, sort of. It should reject any use of units, which is the bug. We'd like to make it work with units rather than rejecting them, or acting in a confusing manner as it does today.

In the documentation for parameters, it lists ceil and floor as accepting "unitless" or "ul". 

 Sorry for any confusion, please let me know if you have more questions.

Thanks,

[Anonymous]

I'm experiencing the same problem. The floor function is rounding to cm when I am working in mm. The docs describes the function as rounding to the nearest whole number, so it is intended to behave independently of units. The problem is it is not, either because of a bug or some sort of setting that is not obvious to me (which is also a "bug"... kinda).

[Phil.E]

@Anonymous

Hi and welcome to the Fusion 360 forum.

The image I posted above shows that currently these functions only support "ul" (which is unitless) units. Can you work your equations to find the ceil and floor values outside of mm/cm units, and then apply the units to the result using another parameter?

Glad to help if you have a question.

Regards,

[Anonymous]

Hi,

I think you miss understand what I am saying, so I will clarify: the floor function is returning to the next lowest cm. It is NOT returning the "next lowest whole number" (or more specifically round down to the nearest lower integer). So the floor function MUST be taking the units into account somewhere along the line in spite of how it is described. Please see screen shot attached.

My equation is floor(d5 * 1.5) where d5 is 9.02mm and the result is 10.0 (ie 10mm or 1 cm) where the expected result is 13 ( floor of 13.53).

Work around: floor(d5 * 15) / 10 which results in 13.

So something is wrong. Either the function is not returning a value as described, or the description of the function is incorrect, or possibly I simply don't understand the description (which is somewhat unlikely, I write code for a living, I am using Fusion for expanding on a hobby into maybe something more).

[Phil.E]

Hi,

In your parameter, you are applying floor to a value that has units. That is not allowed, as per the chart above. Floor works with ul "unitless" values. 

In order to use floor in an expression for a parameter that has units, you simply need to include a nested function that removes the mm units before using floor. See if this works for you:

Please let me know if you have more questions.

Regards,

[Anonymous]

Thank you for the explanation.

I suggest that the documentation is adjusted to explain this (because it doesn't to anyone who doesn't work at Autodesk), unitless tells me that that unit is irreverent and will get stripped because the documentation tells me it will return an integer. It doesn't tell me that it will round my argument to a unit of measurement that may or may not be the one I entered.

Then I also suggest that the bug that you are pretending doesn't exist (it rounds to a measurement unit when it is presented with an argument that is a measurement: that doesn't happen out of nowhere) in that function gets corrected. Both of those steps would help usability.

[Phil.E]

@Anonymous

Actually, I said it's a bug in the posts above. "It should reject any use of units, which is the bug." This was logged a while ago as a bug. (internal reference FUS-21937) Another possible solution would be to allow use of units, but that is a much larger project for us. Sorry for any confusion about that.

If you look at the chart it shows one column as "Expected Type" (which means "this expects you to feed it unitless values") and one column as "Return Type"(which means "this returns unitless values to you"). Is there a label that you would expect to make that more clear? I'm glad to log a suggestion to the web team.

Thanks again for your feedback and help.

Regards

[Anonymous]

... the bug I am pointing out is not the one you had acknowledged...

The software is great, but clearly the corporate culture for accountability is not so great. I will stick to the software and be done chasing my tail with you.

[Phil.E]

Sorry to make you feel that way. I'm trying to be responsive, open and transparent.

In the spirit of that, here is the key text from the bug report logged  a few months ago. Our plan from day one with this issue is to fix exactly what you are complaining about. My own (irrelevant) opinion was posted above, that the expression should show an error if it is in fact (currently) unacceptable syntax. I think both ideas are not exclusive or incorrect, but that is only my opinion.

One possible solution would be to fix it in two stages, first by properly blocking "bad" syntax, and next by the longer term project of making it work with units.

Again, sorry for any bad feelings.

(from the bug report)

"However, as we tested, they do accept values with either unitless or unit, which brings confusion. For example, if the following user parameter (test1, test2, etc) has mm as unit. We can see the evaluated results are kind of unexpected, especially for "floor (5.55mm) = 0 mm"

test1 = floor(5.55 mm) = 0 mm
test2 = floor(5.55 cm) = 50 mm
test3 = floor(5.55 dm) = 550 mm
test4= floor(5.55) = 5 mm

It seems the floor function is trying to convert other units to cm then rounding. (The underlying length unit in Fusion is cm.) The rounding is based on its corresponding cm value, i.e. floor (5.55mm) = floor (0.555cm) = 0 cm = 0 mm

Expected result:
If the functions accept value with unit, the rounding should be based on the unit of the user parameter, instead of cm."

[Phil.E]

@Anonymous FYI the fix for the bug was to allow units in expressions with ceil() and floor() and also (as you pointed out) correctly use those units. The fix has been tested and barring any unforeseen issues should be available in an upcoming update. Thanks for your help.

Regards,