Using INT and FRAC functions with Inches Units

[WoodWorks]

Using INT and FRAC functions with Inches Units

I have long avoided the INT and FRAC functions because they do not seem to work properly outside of the metric system.

I have managed to get them to work in with Inch units by first converting them to the native Centimeters units, for operation by the function, and then back again to inches afterwards.

There is nothing in the manual about this problem.

For an example I defined a Parameter called TestValue with a value of 4.36, and the following equations work:

FRAC(TestValue/2.54)*2.54 yields .36, or the equivalent fraction

INT(TestValue/2.54)*2.54 yields 4

The conversion factor here is the 2.54 Centimeters per Inch. You could probably to the same thing with feet (30.48)

I only found one relevant post in the whole forum to this issue: http://www.alibre.com/forum/viewtopic.p ... hlight=int

Here is my formula for rounding the Parameter DrawerBoxHeight to the nearest fraction, where the fractional denominator is in a parameter called Drawer_BoxHeightRoundingDenominator:

INT(Drawer_BoxHeightMax/2.54)*2.54 + (INT(((FRAC(Drawer_BoxHeightMax/2.54)*2.54)*Drawer_BoxHeightRoundingDenominator)/2.54)*2.54)/Drawer_BoxHeightRoundingDenominator

Drawer_BoxHeightMax is the Maximum Height of the drawer box based on the Opening_Height, and the clearance values above and below.

 

[WoodWorks]

The FRAC command is supposed to return the portion of the number after the decimal point. It works for Metric values, but not for Inch values, even of Decimal format.

The INT command is supposed to return the portion of the number before the decimal point. Again, it works for Metric values, but not for Inch values, even of Decimal format.

For those of us old FORTRAN programmers, the Functions listed on Page 96 of the Alibre Users Guide are old friends, and their description of operation quite familiar.

If the conversion of the values is made to the Metric system (and back again) the Functions work as described, and expected from a programming point of view.

What is amazing, is that this conversion process will even work properly when using the Fraction format for the Inch system.

I think the lack of posts in the forum, indicates that very few people are using these functions outside of the Metric system (unfortunate for us in the States). Probably very few people are currently using these functions, or may have given up trying as I had earlier.

What I also find lacking in the Alibre documentation is a discussion of Operation Order used for evaluation Equations. Again, my FORTRAN experince came to the rescue, and I was able to confirm that Alibre did follow standard Mathematical conventions for evaluation equations.

1. Operations within Parentheses
2. Exponents
3. Multiplication and Division (From Left to Right)
4. Addition and Subtraction (From Left to Right)

For Example: 3 + 5 * 7 evaluates as 3 + 35 because the multiplication operation is performed first.

By knowing the order of Mathematical Operations, you can save yourself quite a few parentheses in Equations. The documentation should devote a short section to this under the Equation Editor, as this is something often overlooked in our age of pocket calculators.

What suprised me the most was a recent forum posting for another competing parametric software, and the lack of documentation and customer use of the Equation Editor type of functionality. Given that this is the greatest power of parametric software, the lack of use of equations to drive the parameters was astounding. I would like to say that Alibre's Equation Editor makes working with parameters and equations quite straight forward, and that I probably would not have developed such sophisticated models given the cumbersome functionality of some other competing software.

Since this is a "bug" in the operation of these functions, I hope it can be addressed as quickly as possible.

 

[aa18]

This behavior you are experiencing is not a bug in Alibre, it is the expected (albeit poorly documented) behavior. Alibre makes a distinction between the parameters entered in the equation editor and the user-selected display units. If you are calculating all your dimensions in metric units, there is no confusion between the two, since as you pointed out Alibre's native measuring system is metric.

However, when using Imperial units problems arise. As an example, let's say you have a distance parameter A = 2.2 inches, and parameter B = INT(A). B would give you the result of 2. However, the result of B will change if the display units change to centimeters, because the value of A is dimensionless. It is stored as a floating point number without units, so the software has no way to tell what measuring system that value is "really" in.

The way to work around this is to define additional parameters to force the values to be in inches. To use your example, let's say that you have a scale parameter TestValue which should be 4.36". You will need to define an additional distance parameter TestValue_d which is defined as (TestValue)in, which will store the value 4.36". In order to get the integer portion of TestValue_d, create another scale parameter TestValue_d_int defined as INT(TestValue_d). This will now give you consistent results in inches.

This may be a somewhat tedious workaround depending on the number of parameters you are using, but it is unavoidable based on both the current way that Alibre defines parameters, and the requirement that Alibre distinguish between parameters and display units. I hope this information helps.

 

[WoodWorks]

Where I have a problem is that INT(2.2) results in a value of 1.968504 rather than 2 when using Imperial units. In my case, 2.2 is not dimensionless as it is defined as a Distance type of variable, and the parameter with the equation is also defined as Distance.

When using Imperial units, and entering distance measurements in inches, all my other equations provide me with correct results in my chosen unit of measurement, and I do not have to concern myself with Alibre's native units. Even the rather akward angle functions that use radians rather than degrees, still perform calculations consistent with my chosen units.

Even when I mix units (both Imperial and Metric) in equations, the calculations are performed with due respect to the specified units. Use of both measurements system is common with cabinetry in the US, as most people have adapted the 32mm cabinet system, yet imported hardware is provided based on metric measurements. I find it easier to enter the metric measurements directly, rather than use the cumbersome conversions printed along side the manufactured dimensions. Alibre is fantastic in being able to handle this without a glitch.

I will be doing some more testing with the other functions offered, as I just found the SQRT function does not even work with parameter names, only hard coded numbers. What is the use of that?

Good news is that Alibre has forwarded my incident to development for review, and we might get a fix so that functions work with all units.