newRPL: Handling of units

[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.