Just for your reference, this topic was also touched on in this thread:

Variable assignment bug

However, I think this topic may be worthy of more discussion.

Edited by user 06 May 2010 23:37:00(UTC)  | Reason: Not specified

I don't know if what I have to say will add any value to the discussion about relative units, but here goes.

I work a LOT with relative and absolute units, due to hydraulic and pneumatic calculations.
psiA = Absolute pressure (referenced to vacuum = 0 psi)
psid = differential pressure (referenced to another pressure)
psig = gage pressure (referenced to ambient pressure (nominally 14.7 psiA)

The relative Temperatures scales are the same.
These are all a big pain to keep straight, or sometimes even to determine what units a given formula is written to use.
So of course when I started using sMath, and found out that it even does Units , I had to try making a few of my own. Of course, I started with the ones that are the most problematic, not knowing any better
I didn't succeed, but I noticed that some are referring to relative units as non-linear units, and that struck me as incorrect. The temperature scales are all linear, but their scale origins do not coincide.

That made me notice that all the built-in unit conversions are ratiometric (i.e. multiplication/division) only, and offset scales require addition/subtraction to convert. This is where the problem is, I think.

I tried to define psig = psi + 14.7, and got all sorts of odd results.
I'm sorry I have no concrete suggestions for how to handle this, but I though addressing the terminolgy might spur some useful ideas for implementation. I know it makes the conversion math horrible, and that's all I can add.

Thanks, Radovan

That was very helpful. I am starting to get the picture.
I didn't understand about the ' key for entering Units, so I had a big mess, with "function not defined" messages all over the place.
I created three additional units 'psiA:='psi, 'psig:='psi, and 'psid:='psi, and now my calculations are displayed unambiguously.

It seems like the automatic unit conversion is the problem with the temperature conversions people are complaining about.
Internal calculations are handled in the default units (K). The problem seems to me that sMath understands every conversion to be an absolute conversion. The results of some temperature calculations are relative. A Kelvin degree is literally the same as a Celsius degree, by definition.
If you measure 350K on one side of a barrier, and 1500K on the other side of the barrier, the differential temperature is 1150K, but if you override the units to °C, the result will be 876.85°C, which is definitely not a correct result, and if the input to your equation is supposed to be the temperature difference, you will have a disastrous miscalculation. The correct differential temperature in °C is also 1150°C. The principle is the same if the units are overridden to °F, and the result will be 1610.33°F, which will also be wrong. The differential temperature in °F is 2070°F.
The problem is mixing of the concept of conversion and scaling. I don't see how sMath could be programmed to correctly recognize which conversion is appropriate under all circumstances. Your suggested workaround of creating the conversion functions is a good one, and I will be applying that, and creating additional variables as necessary...
Dave

P.S. I would post a screenshot or sMath code, but I haven't figured out how to do that yet...

That's exactly it. Setting up a unit that accommodates the scaling factor, but without including the offset, and using (or not using, as appropriate) a function to deal with the correct choice of offset.
Great advice from both of you. I did read the other thread about the variable assignment bug, but I must admit I still don't know exactly what you guys are talking about... I have only been using the program for about three days, and I am still easily confused...
I love the way sMath Studio lets you set up a calculation sheet with equations that actually look (mostly) like the formula in the book! Interspersing explanatory notes (and pictures!) right in with the formulas and definitions is such a super cool feature that words fail me.
One of the biggest headaches with doing calcs in Excel or any programming language is checking that you are actually doing the calculation that the formula describes. And incorporating useful notes in Excel sheets is a pain.
cos(x^2)is much easier to interpret than COS((A$4$)^2) especially for something like the formula for calculating orifice flow.
http://en.wikipedia.org/wiki/Or..._flow_through_an_orifice
There's a reason those pipe flow calculation programs cost money
They know you'd pay someone else to set it up...
Of course there's always guys like us...

Kudos to Andrey for developing such a cool program, and thanks to you guys for helping a n00b out.

Dave

P.S. I tried to use the Thanks button, but it doesn't work for me... :'( Consider yourselves thanked.