Threaded Mode | Linear Mode

JoJo1973 · 05-09-2016, 09:27 PM

I think that there are two competing issues there: cancellation of redundant units, and simplification strategies.

There is another problem that could take advantage of UNORMALIZE: let's suppose you want to compute the tangential velocity of a point orbiting along a circular path of radius 10_cm at 45_°/s. Of course vt = r*w = 450_cm*°/s.

Then you know that its mass is 200_g, therefore its momentum will be 20250000_g*cm^2*°^2/s^2. The application of 1_J UFACT yields 6.16...*10^-4_J*r^2.

Now I'm glad that the degree units have remained during the whole calculation, because this has allowed UFACT to perform the correct conversion.

It's just that now the radiant units are not needed anymore and the only way to discard them is by editing them out or by further unit manipulation.

Since the calc can't know when an adimensional unit is to be discarded, that's when UNORMALIZE comes to aid: the command is intended to work only with planar angles, solid angles and temperature ratios, and its task is simply to cancel these units from the object.

Nothing needs to be changed in the UBASE logic, because it's perfectly ok as it is now: it's only the user that can judge whether a unit object should be normalized or not.

For what it concerns the simplification strategies, there exists a library that's better than a thousand words: let me introduce you to UTool by Carsten Dominik: his library performs everything you might desire about units, and even more (look esp. at USIMP, UUBASE UUFACT, UUDIM and ULCVT).

Probably in NewRPL similar commands would belong to an external library rather than main core, but to me they are the implementation of the best and more versatile strategies to simplify units.

(05-09-2016 01:46 PM)Claudio L. Wrote:
(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.