I noticed that when I try to use a basic symbolic expression with certain units (particularly U.S. customary) that the symbolic result shows an absurd fraction instead of the whole number that it should be. See the attached image, especially the basic equations at the bottom. These units have factors with more than 8 or so digits. I assume that, when the value is stored, it is being converted to the base unit and truncated, which is then converted to a fraction when it is accessed in symbolic mode. The fractions seem to be less than [MATH]10^-13[/MATH] off per unit.


symbolic_unit.sm (13 KiB) downloaded 63 time(s).
* All of the results are in symbolic mode for demonstration purposes.

Is there a good solution to this that I haven't found? I know that if I was only using U.S. customary units, I could replace the Units.xml file, but I often switch between U.S. and metric units depending on the circumstances, so that is not a good option for me. Though I rarely have to convert between U.S. and metric, so I guess I could create my own Units.xml that is based on both U.S. customary and metric simultaneously... (though that solution would be less prone to user error if it was possible to create custom dimensions)

It would be nice if the absurd fractions that are generated would be automatically rounded slightly to account for this inaccuracy. Or maybe if there was an option to show numerical fractions as decimals in symbolic results. Though, in my opinion, it would be best if values were stored without being converted to the base unit, so the value wouldn't have to be converted at all, but that would be a fairly major change.

Wrote

It would be nice if the absurd fractions that are generated would be automatically rounded slightly to account for this inaccuracy. Or maybe if there was an option to show numerical fractions as decimals in symbolic results. Though, in my opinion, it would be best if values were stored without being converted to the base unit, so the value wouldn't have to be converted at all, but that would be a fairly major change.

Actually there are multiple options to control the result display, have a look at the context menu (right mouse button, when on the result).

Some of these settings have pre-sets, controlled by main menu> tools> options.

Wrote

Actually there are multiple options to control the result display, have a look at the context menu (right mouse button, when on the result).

Some of these settings have pre-sets, controlled by main menu> tools> options.

I did see that, but unless I'm doing something wrong they don't apply in symbolic mode. If I'm not using symbolics, I can be in numeric mode and set "Fractions" to anything but "Fraction" and it will show the value I want. However, this doesn't work in any mode other than numeric -- setting "Fractions" to "Decimal" still shows it as a fraction (and none of the other options seem to take effect either).

good post

Greetings!

Wrote

I assume that, when the value is stored, it is being converted to the base unit and truncated, which is then converted to a fraction when it is accessed in symbolic mode.

For the most part, I agree with your analysis.

I've explored your dilemma and you can influence the result to some degree: if you change your base unit, the base unit will display an appropriate fraction/value. See below, I modified both the ｢OutputUnitsSystem｣ variable of ｢%APPDATA%\SMath\settings.inf｣ and the data contained within the ｢C:\Program Files (x86)\SMath Studio\entries\Units.xml｣ file; you can see the extent of the influence:
    - 7000lbf didn't display correctly for Metric, but did for Imperial. However, kip (which has a simple relationship of 1kip = 1000lbf) was not affected.
    - By default 70psi will not simplify to 70psi because base units for Imperial is inHg. However, if you modify the Units.xml file, you can get 70psi = 70psi, but this will be at the cost of inHg no longer simplifying correctly.

     

If you are dedicated to (1) unit per unit type; editing the Units.xml file to force your units to be the base unit might be your best solution. However, Units.xml is an important file: I wouldn't modify it unless you are confident in what you are doing.


Rather then going down the rabbit hole of tweaking system files/settings, you might be better served by redefining the units themselves. For whatever reason, redefining kip to be 1000lbf within the worksheet itself resulted in a proper symbolic evaluation:

     



I hope this helps!
-Kenny Lemens, P.E.

Wrote

It would be nice if the absurd fractions that are generated would be automatically rounded slightly to account for this inaccuracy.

Exponential threshold is limited to 15.
You can freak the inaccuracy
... explain freak to a costumer or published project ! ?
In other type of works ε < 10^-15 is beneficial.

... in other words:
the bizarre symbolic is created by the sub unit D processing.
otherwise correct ... 11*'D=3.6692*10^{-29}*m*C
but should be C m