1 Pages (9 items)
Unit Temperatures possible improvement - Messages
#1 Posted: 5/6/2010 3:28:22 PM
Only today I noticed that SMath handles also non linear unit conversion like temperatures.
Well done :-), it took more than 10 years to have the same in Mathcad...
Just I would like to discuss with the gurus and the Developer on some tricky situation that may lead to confusion for unskilled users.
(by the way, I cannot insert units in live mode, is a keyboard problem? the ' key does not work)
If we define
t1=20°C
and
t2=30°C
How much is t1+t2?
t1+t2=596.3K or 323.15°C and not 50°C
What SMath does is to convert internally t1 and t2 in Kelvin adding 273.15, and then revert it back to °C subtracting again 273.15
I do not consider it a bug, but a consequence of the fact that non linear unit scaling is evil, but this may lead to unexpected results for novice users.
What Mathcad does in this case is to add a further unit "Delta °C", "Delta °F".
DeltaC=1 K
DeltaF=5/9 K
So one has to define t1 as 20°C, t2 as 20°DeltaC, so the sum returns t2+t1=323.15K=50°C as one would expect.
I'm not sure this would be the smartest approach, however, and it can be easily achieved by adding the custom units in SMath.
What do you think about?
Well done :-), it took more than 10 years to have the same in Mathcad...
Just I would like to discuss with the gurus and the Developer on some tricky situation that may lead to confusion for unskilled users.
(by the way, I cannot insert units in live mode, is a keyboard problem? the ' key does not work)
If we define
t1=20°C
and
t2=30°C
How much is t1+t2?
t1+t2=596.3K or 323.15°C and not 50°C
What SMath does is to convert internally t1 and t2 in Kelvin adding 273.15, and then revert it back to °C subtracting again 273.15
I do not consider it a bug, but a consequence of the fact that non linear unit scaling is evil, but this may lead to unexpected results for novice users.
What Mathcad does in this case is to add a further unit "Delta °C", "Delta °F".
DeltaC=1 K
DeltaF=5/9 K
So one has to define t1 as 20°C, t2 as 20°DeltaC, so the sum returns t2+t1=323.15K=50°C as one would expect.
I'm not sure this would be the smartest approach, however, and it can be easily achieved by adding the custom units in SMath.
What do you think about?
#2 Posted: 5/6/2010 4:34:09 PM
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.
Variable assignment bug
However, I think this topic may be worthy of more discussion.
Will Massie
Mechanical Engineer
Oregon, USA
#3 Posted: 5/6/2010 4:35:32 PM
Hello callmeishmael,
Look at these posts please http://en.smath.info/forum/default.aspx?g=posts&t=400. This is about the temperature units and temperature differences you are talking about. The temperature differences can be added as new defined units. However, I agree with you and think it might be well enough to add the temperature differences ("Delta °C", "Delta °F" ) into the tempreture units list of SMath.
Regards,
Radovan
EDIT: Will pointed out on the same thread. Just to note, one must take extra care when using the negative relative temperatures (°C,°F).
Look at these posts please http://en.smath.info/forum/default.aspx?g=posts&t=400. This is about the temperature units and temperature differences you are talking about. The temperature differences can be added as new defined units. However, I agree with you and think it might be well enough to add the temperature differences ("Delta °C", "Delta °F" ) into the tempreture units list of SMath.
Regards,
Radovan
EDIT: Will pointed out on the same thread. Just to note, one must take extra care when using the negative relative temperatures (°C,°F).
When Sisyphus climbed to the top of a hill, they said: "Wrong boulder!"
#4 Posted: 9/24/2010 8:39:15 AM
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.
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 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.
#5 Posted: 9/24/2010 10:00:01 AM
Hello Dave,
I think you can not make new units that way. SMath uses absolute pressure units (psi=psia=psiA). The psig can not be defined, it could be just introduced as a unit in SMath. If you want to calculate both with absolute and gauge pressure, the workaround is to just make some functions:
[MATH=eng]psig(Pabs)←Pabs-14.7*psi[/MATH]
Giveing Pabs in absolute pressure and obtaining results in gauge pressure
[MATH=eng]psia(Pgauge)←Pgauge+14.7*psi[/MATH]
Giveing Pgauge in gauge pressure and obtaining results in absolute pressure
Arguments to the functions must have pressure units or "Units do not match" error will be issued.
You can even put the apostrophe in front of function names and arguments like this
(type it as you see it below)
and the look will be italized and blue - like the default units color and look.
[LIVE width=392 height=204]http://smath.info/live/?file=1598[/LIVE]
Regards,
Radovan
I think you can not make new units that way. SMath uses absolute pressure units (psi=psia=psiA). The psig can not be defined, it could be just introduced as a unit in SMath. If you want to calculate both with absolute and gauge pressure, the workaround is to just make some functions:
[MATH=eng]psig(Pabs)←Pabs-14.7*psi[/MATH]
Giveing Pabs in absolute pressure and obtaining results in gauge pressure
[MATH=eng]psia(Pgauge)←Pgauge+14.7*psi[/MATH]
Giveing Pgauge in gauge pressure and obtaining results in absolute pressure
Arguments to the functions must have pressure units or "Units do not match" error will be issued.
You can even put the apostrophe in front of function names and arguments like this
(type it as you see it below)
'psig('Pabs):'Pabs-14.7*'psi
'psia('Pgauge):'Pgauge+14.7*'psi
[LIVE width=392 height=204]http://smath.info/live/?file=1598[/LIVE]
Regards,
Radovan
When Sisyphus climbed to the top of a hill, they said: "Wrong boulder!"
#6 Posted: 9/24/2010 12:34:00 PM
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 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...
#7 Posted: 9/24/2010 1:20:25 PM
Here is a worksheet I did recently that shows how to work with differences in relative temperatures. I think it is a good example of how to deal with the issue being discussed here. I know that this solution was presented by Radovan in previous threads (Variable assignment bug), but I think that seeing a practical example is very helpful.
Engine Heat Rejection Calcs.pdf
Engine Heat Rejection Calcs.zip
Engine Heat Rejection Calcs.pdf
Engine Heat Rejection Calcs.zip
Will Massie
Mechanical Engineer
Oregon, USA
1 users liked this post
Radovan Omorjan 9/24/2010 1:36:00 PM
#8 Posted: 9/26/2010 12:11:06 AM
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.
[MATH]cos(x^2)[/MATH]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/Orifice_plate#Incompressible_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.
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 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.
[MATH]cos(x^2)[/MATH]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/Orifice_plate#Incompressible_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...


#9 Posted: 9/26/2010 2:15:47 AM
You are welcome Dave
,
Do not hesitate to ask about everything that confuses you. We might know the answer or might stay confused all together
. Anyway, I would suggest you to read some Tutorials, Examples and other stuff on the Wiki. Regarding to your interests (hydraulics), I would suggest you to pay attention on the Tutorials and Examples made by Prof. Gilberto Urroz.
Regards,
Radovan

WroteI 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...
Do not hesitate to ask about everything that confuses you. We might know the answer or might stay confused all together

Regards,
Radovan
When Sisyphus climbed to the top of a hill, they said: "Wrong boulder!"
1 Pages (9 items)
-
New Posts
-
No New Posts