newRPL: Handling of units

[Claudio L.]

I'm well advanced into implementing units in newRPL (the 4 basic operations work, as well as UVAL, UBASE and CONVERT).
While all this works fine, I reached now a difficult subject: Temperatures!
Here's a quote from hpcalc.org FAQ's:

Quote:...the G/GX will only add or subtract temperatures if the units are the same; it is now an error if they are not.

If the units attached to the number consists only of a temperature and nothing else, operations are done using an absolute temperature scale (relative to absolute zero). If the units consists of a temperature and something else, such as degrees/minute, the operation will not be done using an absolute temperature scale.

For the most part it does make sense, until you try to calculate entropy. s=Q/T, I'm trying to think if there's a way to implement a proper operation, if you divide for example 3_J / 30_°C, the operation should convert to Kelvin before proceeding. However, this would mess up equations where the temperature is a difference in temperatures. Perhaps there should be a different unit for temperature change (Δ°C maybe), which has the relative conversion factors for all formulas where the temperature change is involved.

Thinking out loud, it should work more or less like this:
* All operations involving an argument with a pure temperature, will convert that argument to its respective absolute scale (Kelvin or Rankine) before doing the operation.
* Subtraction of pure temperatures: As all other operations, the system would convert first to an absolute scale, then do the difference. The resulting unit should keep the unit of the first argument, but the absolute units would be converted to a Delta unit, so 30_°C - 10_°C = 20_Δ°C.
* Addition of temperatures: physically has no meaning, but it might be a byproduct of an algebraic manipulation, A+(-B), where -B is perhaps -10_°C. The system would have to process it as a difference of temperatures, by changing the sign of the second argument. 30_°C + 10_°C = 30_°C - (-10_°C) = 40_Δ°C (note the same change from absolute to delta degrees).

For the user, the visible changes would be:
* Automatic conversions of temperature during subtraction (currently it's an error)
* The user would have to distinguish between a temperature value and a temperature change, and provide proper units (for example, if a formula Q=m*C*Δt, then Δt should have delta units (Δ°C instead of just °C). This is true also for the units of the coefficients (C in this case).
* Perhaps the most confusing (though correct), is that °C would be replaced by K and °F by °R in formulas automatically without the user consent (except for addition/subtraction, which would keep the original unit converted to delta).

I think this covers all cases quite well:
Normal heat equations:
Q=m*C*(t2-t1) --> the system would change t2 and t1 into a delta unit after the difference.
Q=m*C*Δt --> The user needs to put Δ units into Δt.

Stefan–Boltzmann: When the system finds a T^4, the power operation would convert the temperature to absolute, so it works.

Entropy: Q/T --> The system would convert to absolute before doing the division.

Temperature conversions: Using absolute or relative scales depending on the units. Delta units are considered inconsistent with pure temperature ones.

Any other cases that I could be missing?

Any thoughts / objections before I implement this?

[Han]

How would the system handle mixed units involving temperature? For example, what if the equation Q=m*C*(t2-t1) were instead written as Q=m*C*t2-m*C*t1?

[Claudio L.]

(09-27-2015 02:29 PM)Han Wrote:  How would the system handle mixed units involving temperature? For example, what if the equation Q=m*C*(t2-t1) were instead written as Q=m*C*t2-m*C*t1?

Good point.
When there's mixed units involved, the system cannot convert from raw temperature to delta temperature automatically, so the user needs to be more careful with the units.
In your example, the constant C would be defined in terms of Δt, so its unit would be ΔK (or compatible scale).
If you provide just temperature (let's say in Celsius), when you evaluate each term, m*C*t2 would convert t2 to Kelvin automatically, then the second term would convert t1 to Kelvin. Each term would contain now an absolute temperature. Subtraction of mixed units would work, but the system would not be able to detect and convert to ΔK, so the final unit would remain with K, not ΔK, and it wouldn't cancel out with the unit in C.
The result would be numerically correct, but the units would have the K/ΔK artifact, since the system cannot do that conversion for you.

Now physically, m*C*t2 has no meaning unless t2 is seen as (t2-0), then you'd be subtracting the energy to heat that mass from 0 to t1 from the energy to heat up from zero to t2. This is what the 50g currently assumes: all temperatures are deltas when there's mixed units involved. Therefore, if you plan to use that type of expression, you really need to provide t1 and t2 already in Δ units, which would cancel out with the ΔK in the C constant to give you proper energy units.

Why bother with all this Δ unit business?
If the expression is properly formed to isolate the temperatures, (t2-t1) can be done in any temperatures, and the system would be able to convert automatically, something that the current system can't do.
Try:
<< 1_°C 273.15_K - >>
and you'll be surprised with an inconsistent units error.

Also, when you use Celsius or Fahrenheit in an equation, the new system automatically converts to an absolute scale (Kelvin or Rankine respectively), to produce correct results in all cases, with the only "glitch" of the K/ΔK or °R/Δ°R if your constants were defined in terms of deltas.

In short:
With the old system:
Q=m*C*(t2-t1) --> If you use different scale = Inconsistent units
Q=m*C*t2-m*C*t1 --> If you use different scale --> Incorrect result, units OK
E=σT⁴ --> Using any scale other than K or °R --> Incorrect result
ΔE=σ(T2⁴-T1⁴) --> Using any scale other than K or °R --> Incorrect result

With the proposed system:
Q=m*C*(t2-t1) --> If you use different scale = Correct results, units OK
Q=m*C*t2-m*C*t1 --> If you use different scale --> Correct result, K/ΔK glitch. Using delta units for t2 and t1 --> Correct result and units.
E=σT⁴ --> Using any scale other than K or °R --> Correct result and units
ΔE=σ(T2⁴-T1⁴) --> Using any scale other than K or °R --> Correct result and units

In other words, the new system will never return an incorrect result, but can give you that K/ΔK glitch if you are not careful with your units. Otherwise you can mix and match temperature scales. I think that's an improvement, isn't it?

[David Hayden]

Even addition is hard. What is 10_C + 5_F? Is it 10_C + 5_ΔF? Or 5_F + 10_ΔC? Or 10_ΔC + 5_ΔF? All of these will produce different answers.

[Claudio L.]

(09-30-2015 04:15 PM)David Hayden Wrote:  Even addition is hard. What is 10_C + 5_F? Is it 10_C + 5_ΔF? Or 5_F + 10_ΔC? Or 10_ΔC + 5_ΔF? All of these will produce different answers.

All those things are not the same.
Because the scales have a non-null zero, 10_C is actually:
ZeroC + 10_ΔC (where ZeroC is a vector to the origin of the scale, and ΔC is a unit vector in the direction of the scale, and the _ operator is just a multiplication).
5_F = ZeroF + 5_ΔF
Therefore:
10_C+5_F = ZeroC+ZeroF+10_ΔC+5_ΔF
Adding ZeroC+ZeroF has no physical meaning (it would be just another origin of an unknown useless scale), so I like better:
10_C+5_F = 10_C- (-5_F)
ZeroC+10_ΔC - (ZeroF-5_ΔF)
(ZeroC-ZeroF) + 10_ΔC + 5_ΔF
where ZeroC-ZeroF is an actual Δ unit, so the result will be in ΔC direction.

The second case you propose is:
10_C+5_ΔF
ZeroC + 10_ΔC + 5_ΔF
ZeroC + 12.77777..._ΔC = 12.7777..._C

And this is an actual temperature, not a Δ.

Right now this latter case is not supported but will be in short. Everything else is already implemented and working like a charm.

PS: Everything else is finished, I'm just debugging/polishing the units module and I'll update the firmware image for testing in a few days.

[JoJo1973]

Hello Claudio,

I've discovered your NewRPL project and I must say it's really exciting to follow your efforts in reimagining the old faithful User RPL, at the same time ironing out some of the limitations that today are perceived as such, but at the time were more than acceptable... "Life is short, and ROM is full", as they say!

What has attracted me most is your treatment of units and angles as native objects: having units attached to vectors and symbolics allows for powerful calculations in a very straightforward manner.

Having read previous posts on the argument, I remember you (or someone else) have expressed interest in a including the units supported by the HP Prime amongst the ones already present in the code, but also that a complete list was not available.

With the help of the emulator I've compiled such a list and took the chance to test the accuracy of the conversion factors. An invaluable help in such a task is the Numericana blog (http://www.numericana.com/) which in the past has scrutinized the implementation of the units package in the HP50G and the HP Prime. See for example http://www.numericana.com/answer/hp-prime.htm#units

I'll report below my findings, citing references where necessary. At the moment I've used the Alpha 5 Demo to perform my test, but I count on doing on the real hardware as soon as possible!

1. Length and Area
   Nothing to report here: NewRPL already supports the unit presents on HP50G and HP Prime.
2. Volume
   Here things get messy and complicated: the culprit is the definition of gallon, which has changed in time and space! Fundamentally, the situation on the HP50G (which I take as reference since it inherits the definitions of the HP48SX/GX) define three different gallons (see http://www.numericana.com/answer/units.htm#floz and http://www.numericana.com/answer/units.htm#gallon for a lenghtier discussion).
   
   • _galUK: Imperial gallon = exactly 4.546092_l
   • _galC: New Imperial gallon used in Canada = exactly 4.54609_l (note the missing last digit!)
   • _gal: Winchester gallon = exactly 231_in^3
     
   
   The trick is that _galUK has been in use from 1976 to 1985, when UK switched to _galC. I think it would be more sensible to retain the difference between the two definitions as HP did, and add a new definition for the Canadian (and later UK ounce): 1_galC = 160_ozC.
   
   The HP Prime team has also created alternative definitions for the pint and the bushel to take into account the different gallons, even if the effort has not taken to the full consequences. The HP50's _pt and _bu have been renamed to _liqpt (why?!?) and _buUS, a new _ptUK has been created and a new _bu unit has been defined using the Canadian gallon.
   
   Very confusing, IMHO.
   
   Since all the units have the same relative weight, differing only in the definition of the base unit (with the exception of the _ozfl) I have this proposal for NewRPL:
   
   • a set of US units: _gal, _ozfl (= 1/128_gal), _pt, _qt, _bu, _pk, _tsp, _tbsp
   • a set of Old Imperial units: _galUK, _ozUK (= 1/160_galUK), _ptUK, _qtUK, _buUK, _pkUK, _tspUK, _tbspUK
   • a set of New Imperial units: _galC, _ozC (= 1/160_galC), _ptC, _qtC, _buC, _pkC, _tspC, _tbspC
     
   
   A bit overkill, but coherent!
3. Speed
   HP Prime team has conveniently added definitions for _rad/s, _tr/min (= 2*pi_rad/min) and _tr/s (= 2*pi_rad/s). Very useful to have a dedicated definition so you don't have to navigate Angle and Time menus.
   
   *** WARNING: There is a bug in NewRPL! 1_rpm shouldn't be 60_1/s, but rather 1_1/min ***
4. Mass
   Here HP Prime team has only renamed the _ton to _tonUS: If my proposal for volume units is accepted, I'd suggest to leave the name unchanged, coherently with the convention of not tagging US customary units with "US".
   
   BTW, could you add the _gmol (= 1_mol) and the _lbmol (= 453.59237_gmol, exactly) to the catalogue? These units were present in the HP50G, under an Equation Library submenu.
5. Acceleration
   This is a new menu specific of the HP Prime: I find it very convenient, since these units often don't have a dedicated name such as Newton or Ampere and require a lot of keystrokes to be entered. Here we have:
   
   • _m/s^2
   • _ft/s^2
   • _grav, which is just _ga with a fancy name
   • _Gal (= 1_cm/s^2)
   • _rad/s^2
     
6. Power
   Hp Prime added convenient shortcuts for _MW and _ft*lbf/s.
   May I suggest the addition of the metric horsepower (1_ch = 75_m*kgf/s) and the _Btu/h?
7. Electricity
   HP Prime team added a shortcut for the _A*h.
8. Angle
   Added the _gon (= 1_grad, it's an alias used in some countries) and the _tr (= 2*pi_rad).
   Since you've turned the _sr into a fully recognized unit would you consider adding _spat (= 4*pi_sr), _°^2 (= (pi/180)^2_sr), _arcmin^2 (= 1/3600_°^2) and _arcs^2 (= 1/3600_arcmin^2)? They're currently used in many astronomy textbooks.
9. Viscosity
   HP Prime team added a shortcut for the _m^2/s. Maybe an alias for the _kg/(m*s) would be useful too? in my textbooks I've never seen Poises or Stokes, but only their cumbersome SI counterparts.
10. Light
    Nothing to report here, but kudos for having made explicit the presence of steradians in the definitions of some units!
11. Radiation
    Nothing to report here too.
12. Pressure
    The _inH2O has a precise and exact definition, based on a conventional value of water density: therefore 1_inH2O is exactly defined as 1_in*1_ga*999.972_kg/m^3 (see: http://www.numericana.com/answer/constants.htm#h2o).
    
    1_torr is not equal to 1_mmHg (and besides, it's _Torr). The explanation is that, as you correctly implemented in NewRPL, 1_mmHg = 1_mm*1_ga*13595.1_kg/m^3 (exactly); on the contrary, the _Torr is defined as (101325/760)_Pa (exactly). The two values are very close, but are not the same... (see: http://www.numericana.com/answer/casio.htm#mmhg).
13. Energy
    This is complicated: first of all, http://www.numericana.com/answer/casio.htm#ist eloquently asserts that since 1935 all the results published in calories refer to the thermodynamical calorie: 1_cal = 4.184_J. All other definitions of calorie are either unaccurate or bogus or obsolete.
    
    But let's go on: HP Prime team defines two shortcuts for _Wh and _kWh: so far, so good.
    
    Now, here come the _therm...
    
    HP Prime gives three different definitions of _therm, and none of them match the definition of the HP50G or the definition in NewRPL, because they depend on the definition of the _Btu, and they are legion.
    
    To get the things straight:
    
    • The _therm is always defined as 10^5_Btu, whatever a _Btu is.
    • NewRPL's _Btu is the so-called Btu_IT: it's definition is precise, accepted and widespread, but unfortunately none of the _therm's is actually defined upon it.
    • _thermEC is defined as 10^5_Btu_ISO and it's exactly 105505600_J
    • _therm is defined as 10^5_Btu_59°F and it's exactly 105480400_J
    • _thermUK is defined as 10^5_some_unknown_Btu_noelsewhere_defined: it's value is exactly 105505585.257348_J. I have no primary source to justify this value, but since all secondary sources bother to list 6 decimals, I assume that the conversion factor is exact.
      
    
    Next, follows some technical units used in the industry, but not used in scientific papers:
    
    • _toe (Tonne of Oil Equivalent) = exactly 41.868_GJ. Source: https://www.iea.org/publications/freepub...manual.pdf
    • _boe (Barrel of Oil Equivalent) = exactly 5.8*10^6_BTU_59°F = 6117863200_J. Source: http://www.irs.gov/pub/irs-drop/n-99-18.pdf
    • _tec (Tonne of Coal Equivalent) = 27.84_GJ (as reported by the HP Prime). This one is unconfirmed: none of the definitions I've found on the web match the value reported by the HP Prime.
    • _lep (Liter of ??? Equivalent) = 35788320_J (as reported by the HP Prime). I haven't been able to find any info about this unit. Comparing it with the next unit, it's evident that the 'l' stands for 'liters'.
    • _bblep (Barrel of ??? Equivalent) = 5689888186.82_J (as reported by the HP Prime). Absolutely no info found about this one, except for the fact that it expresses a _lep in barrels (_bbl) units: multiplying 35788320_J*1_bbl/l you get the value provided by the HP Prime.
    • _cf (???) = 1080000_J (as reported by the HP Prime). This one too remains a mystery to me. At least, the conversion factor seems exact.
      
14. Other
    The decibel (1_dB = 1) is the last of the units present in the Equation Library and actually is not supported by NewRPL. It should be added for compatibility's sake. Maybe it could be put in the Electricity catalogue, but could also become the first unit of a new Adimensional catalogue.
    

I hope I haven't been too nitpicky, but I'm really interested in NewRPL, and I wish it sports the most up-to-date set of conversion units!

Regards,
Stefano

[Terje Vallestad]

From the Prime in calculator help

(05-08-2016 01:30 PM)JoJo1973 Wrote:  [*]_lep (Liter of ??? Equivalent) = 35788320_J (as reported by the HP Prime). I haven't been able to find any info about this unit. Comparing it with the next unit, it's evident that the 'l' stands for 'liters'.

lep : liter of oil equivalent (35,788,320 J)

Can't help with the others

Cheers, Terje

[JoJo1973]

Nice, I didn't know that units had help pages. Anyway this confirms that _tec is 'Tonne of Coal Equivalent'. It's value remains a mystery, probably bogus: all the sources concord on defining it as 0.7_toe which makes 29.3076_GJ.

Probably I've found a meaning of _cf: as defined on the HP Prime, it's exactly 0.3_kWh. Online conversion tools report that 1 Cubic Foot of Natural Gas is approximately 0.29_kWh.

Since these units are not part of a coherent system and must take into account the variation of due to the quality of the gas/oil extracted, they are usually rounded to a simpler value: this seems to be the case... I just wish I could find a reference!

(05-08-2016 03:48 PM)Terje Vallestad Wrote:  From the Prime in calculator help

(05-08-2016 01:30 PM)JoJo1973 Wrote:  [*]_lep (Liter of ??? Equivalent) = 35788320_J (as reported by the HP Prime). I haven't been able to find any info about this unit. Comparing it with the next unit, it's evident that the 'l' stands for 'liters'.

lep : liter of oil equivalent (35,788,320 J)

Can't help with the others

Cheers, Terje

[Claudio L.]

Fantastic review of units. Thank you for that, as it was hard for me to find updated information on some units.
I'll go over each and every one of your points and make sure they are taking care of. Bugs first, suggestions later.
Some units were outdated and I applied a more modern definition, but still I wasn't trying to depart too much from the 50g names because of compatibility with existing code.
But I'm up for a more modern set of units, so I'll do a thorough review based on your post.

[JoJo1973]

Nice to see you've appreciated it!

Doing an edit on the post to update a reference URL has put my original comment under moderation: I hope it resurfaces soon...

[Claudio L.]

(05-08-2016 06:21 PM)JoJo1973 Wrote:  Nice to see you've appreciated it!

Doing an edit on the post to update a reference URL has put my original comment under moderation: I hope it resurfaces soon...

Ahhh... that's why I couldn't find it. I already fixed the rpm, nice catch (I meant to do 1/60_1/s, but it's better to leave it as 1_1/min as you said).

I'll have to wait until it comes back. Thanks again.

[emece67]

Hi all,

In a case like: what's the final temperature of 2 kg of liquid water at 20ºC that is heated if the total amount of heat transferred to it is 25000 J?

From \(Q = mC\Delta T\) you will get \(\Delta T = {Q\over mC}\), with \(C=4182 {J\over kg \Delta K}\) being the specific heat of water at 20ºC. With this you get \[\Delta T = {25000 J\over 2kg · 4182 {J\over kg \Delta K}} = 2.989 \Delta K\]

Then the final temperature will be: \(T_0+\Delta T = 20 ºC + 2.989 \Delta K =\) Inconsistent units.

I don't see the point on \(T\) and \(\Delta T\) units being inconsistent in addition and subtraction.

EDIT: and for the \({T\over\Delta T}\) and \({\Delta T\over T}\) cases. Will: convert \(T\) to the absolute scale associated with \(\Delta T\); discard units; perform division, solve the \({K\over\Delta K}\) glitch? This way 10ºF / 1ΔK = 469.67ºR / 1ΔºC = -12.22ºC / 1ΔK = 260.928 K / 1ΔºC = 260.928.

[emece67]

And for Stefan-Boltzman: will T*T*T*T return the same as T^4?

[JoJo1973]

The post has come back. In the meanwhile I found a reference to the funny-looking Btu from nowhere: http://www.legislation.gov.uk/uksi/1995/...edule/made

Signed and delivered by HRM Queen Elizabeth II. Guess we can't ask for more, isn't it?

(05-08-2016 06:24 PM)Claudio L. Wrote:  

(05-08-2016 06:21 PM)JoJo1973 Wrote:  Nice to see you've appreciated it!

Doing an edit on the post to update a reference URL has put my original comment under moderation: I hope it resurfaces soon...

Ahhh... that's why I couldn't find it. I already fixed the rpm, nice catch (I meant to do 1/60_1/s, but it's better to leave it as 1_1/min as you said).

I'll have to wait until it comes back. Thanks again.

[Claudio L.]

(05-08-2016 09:06 PM)emece67 Wrote:  Then the final temperature will be: \(T_0+\Delta T = 20 ºC + 2.989 \Delta K =\) Inconsistent units.

I can't reproduce this. I put 20_ºC in the stack, 2.989_\(\Delta\)K and I get the expected 22.989_ºC

Am I missing something?

Update: Just to be sure, I did the whole calculation with the 25000 J, and the units are consistent. Are you sure you didn't use \(\Delta\)ºK or perhaps a small k instead of K? newRPL accepts user defined and undefined units as well. When a unit has no definition, it treats it as a stand-alone base unit, consistent with nothing else, but will otherwise operate on the unit normally.
In newRPL you can do:
1_apple 1_orange +
and you'll get an inconsistent unit error, until you do for example:
0.5_apple
'orange'
UDEFINE

Then try again the addition, to get 1.5_apple as expected.

This is powerful but has one small drawback: it will carry on *ANY* typo and accept it as a unit, only until you need consistency in addition, or cancellation in a formula you will realize what's happening.

In your example, if you had used 25000_j (small j), the formula would've produced units of: \(\Delta\)K*j/J

[Claudio L.]

(05-08-2016 10:01 PM)emece67 Wrote:  And for Stefan-Boltzman: will T*T*T*T return the same as T^4?

Yes, with the unit converted to an absolute scale, Kelvin or Reaumur (I hope I spelled it right).

EDIT: I meant Rankine, Reaumur is not absolute and not supported.

[emece67]

(05-09-2016 12:41 AM)Claudio L. Wrote:  ...
I can't reproduce this. I put 20_ºC in the stack, 2.989_\(\Delta\)K and I get the expected 22.989_ºC

Am I missing something?
...

Yes, you are missing that I am missing :-) that when you said:

(09-23-2015 03:38 PM)Claudio L. Wrote:  ...
Temperature conversions: Using absolute or relative scales depending on the units. Delta units are considered inconsistent with pure temperature ones.
...

you are referring to temperature conversions only, and that they are consistent in + & -. I have not tested the real thing, it is perhaps time to flash it. Sorry for the noise.

P.S. Have you thought about the \(T\over\Delta T\) workaround above?

[JoJo1973]

Sometimes is useful to keep ratios between temperatures and delta's, sometimes is not.

This means that there isn't an automated behaviour that can satisfy everyone in every situation.

I'd propose to leave the current behaviour unmodified, and introduce a command (UNORMALIZE?) to perform simplification at user's request.

(05-09-2016 05:55 AM)emece67 Wrote:  P.S. Have you thought about the \(T\over\Delta T\) workaround above?

[Claudio L.]

(05-09-2016 05:55 AM)emece67 Wrote:  you are referring to temperature conversions only, and that they are consistent in + & -. I have not tested the real thing, it is perhaps time to flash it. Sorry for the noise.

P.S. Have you thought about the \(T\over\Delta T\) workaround above?

The workaround you propose implies adding code to specially handle those ratios and cancel the units. This affects performance for all operations with all units, so I'd rather not include such things unless strictly necessary.
The glitch only happens if you define equations in terms of temperature change and then use absolute temperature values instead, and as jojo1973 said, I don't know if there are cases where it may be desirable to distinguish them. Since it doesn't cause much trouble I didn't think it needed special treatment.
After all J/K (entropy) is not the same as J/ \(\Delta\)K

[Claudio L.]

(05-09-2016 09:22 AM)JoJo1973 Wrote:  I'd propose to leave the current behaviour unmodified, and introduce a command (UNORMALIZE?) to perform simplification at user's request.

I thought about a USIMPLIFY too, but I found myself in trouble trying to decide what the user would want. It's not trivial for example:

1_km/m^2 = ???

What should be the simplification answer? 1000_m^-1 or should we convert to km then simplify? in such case it would be 1000000_km^-1

A more complex case:
1_N/m

Since 1_N=1_kg*m/s^2, should we simplify to 1_kg/s^2?

One more, F=m*a:

1_kg*3_m/s^2, how does the system know that this is actually 3_N, or why not 3_J/m? It depends on whether you prefer to see this as a force, or as work per meter.
I could not find a systematic (as in programmable) way to make that decision. Sometimes it's best to expand units into their components and simplify, some others to collect the components into more complex units.

I thought the best approach would be to have somehow (not quite sure how to implement this) a desired unit for variables. Let's say you have global variable A. Somehow you tell the system you want A to be in 1_N/m, then every time you STO something in A, the system will try to convert to the desired units, and error if the units can't be converted (means you made a mistake somewhere).
The idea would be to have each problem in a directory, where the variables have preassigned units (and therefore their associated physical magnitudes).

Another property, besides unit, could be for example a formula to auto-compute this variable.
For example, let's do F=m*a, where the user inputs m and a, and F is a variable that has:
a) A preferred unit of 1_N as a "property"
b) A formula 'm*a' as a property
c) A result (this is the content of the variable, not a property)

When the user stores something in 'm' or 'a', automatically triggers a re-evaluation of the formula in 'F', and the result of that evaluation is stored in F as a result, converted to the preferred units.

Now let's add another variable, let's say M=F*d, with d a distance.
M.unit=1_N*m
M.auto='F*d'

And whenever the user stores a new value in 'd' or in 'F', it triggers auto-recalculation of M.
So you can setup a problem in a directory this way, and when you change your input variables, everything else is automatically recalculated, just like a spreadsheet would, but there's no cells (more like a MathCAD worksheet I would say).

I have had this (without the units part) working written in sysRPL for many years, it's what I use almost exclusively to get quick results for concrete design, etc at work. I just change the input variables, and then look at the output variables. The autocompute property doesn't have to be a formula, could be a program too.
You can even try intermediate values, as there's no harm in for example manually plugging a value for 'F' in the example above. It would trigger a recalculation of 'M' with the given F, although F will no longer meet the 'm*a' condition.

Since it's been useful to me, I wonder if this should be a standard feature in newRPL.