Numbers within units (50g)

[Claudio L.]

Is there any use for allowing numbers within units?

For example: the 50g accepts:

2_2 --> 4

I guess the unit 2 could be thought of like "pairs"? It's immediately converted to the number 4 upon compilation.
It could be a twisted way to input fractions, as you can input 3_1/2 to enter 3/2, except it gets immediately compiled to 1.5.

1_m/2 --> 0.5_m
The unit in this case is 'm/2' or 'half-meter', and is converted to 'm' upon compilation.

Is this intentional and documented somewhere? or is it just an artifact of the implementation? Is it like this also on the 48S and 48G?

It seems they are allowed to be typed and compiled, but they are not allowed to exist in the unit object, since the compiler eliminates them by multiplying them into the value.

Within symbolics it gets weird:

'3_m/2+2_ft' is actually compiled into '1.5_m+2_ft'
'3_(m)/2+2_ft' is also compiled to '1.5_m+2_ft'
'(3_m)/2+2_ft' is the only way to get the expression with the /2.

Is there any use for this? Seems to me there's no use, and numbers are better left out of the units for the symbolic expression to use. '3_m/2' in my head should be an expression where 3_m is divided by two, no?

[rprosperi]

(09-15-2015 09:53 PM)Claudio L. Wrote:  2_2 --> 4

I guess the unit 2 could be thought of like "pairs"? It's immediately converted to the number 4 upon compilation.
It could be a twisted way to input fractions, as you can input 3_1/2 to enter 3/2, except it gets immediately compiled to 1.5.

1_m/2 --> 0.5_m
The unit in this case is 'm/2' or 'half-meter', and is converted to 'm' upon compilation.

Is this intentional and documented somewhere? or is it just an artifact of the implementation? Is it like this also on the 48S and 48G?

On a 48GX, both of the above return the same results. Unexpected indeed. Should be interesting to follow discussion of this topic; thanks for posting this Claudio.

[Bruno]

Same results returned for all the examples on a HP48SX

[Claudio L.]

Thank you both for checking this behavior on the 48's.

I guess number expressions could make sense for things like this:
3_m^(2+2) --> 3_m^4

but then, this is handled on the compiler, the unit object can't hold the 2+2 and therefore this is only useful if the user actually types (2+2) instead of 4.

1_m^s
gives a syntax error, as a unit cannot be used as an exponent. So far so good.

but in a symbolic:

'1_m^s'

it shows as '_(1,m^s)' in pretty print (back to '1_m^s' when decompiled for edit)
when you would expect the constant 1_m raised to the identifier 's'.

in sysRPL this decompiles as:
SYMBOL
Z1_
SYMBOL
ID m
ID s
x^
;
xFORMUNIT
;

Very strange and unexpected. Trying to EVAL this gives you an "inconsistent units" error.

I couldn't find any reference to this in years of discussions here and in comp.sys.hp48. My question about the usefulness is to see if this is a behavior worth replicating in newRPL. My guess is not.

[Csaba Tizedes]

(09-15-2015 09:53 PM)Claudio L. Wrote:  Is there any use for this? Seems to me there's no use, and numbers are better left out of the units for the symbolic expression to use. '3_m/2' in my head should be an expression where 3_m is divided by two, no?

This is a very good catch - and very interesting. Thanks for this post!
BTW: You tried everything except the 3_(m/2) version (this is the real "halfmeter") - the result is same.

I played a short time with decibel, because this is the only one unit which has no dimension (defined on the HP48xx as "1") - but after evaluating the result is alvays value_dB.

My opinion about the original question: this is a normal evaluation these type of objects: an unit object - for example in my engineering work - it has a value and it has a dimension. If the dimension has a value different from 1 as a multiplier, the unit's value must to multiply with this value and the multiplier of the dimension is remain 1 - in this rule based all the dimension conversion method:

25.4_mm = 25.4_((1/25.4)_in) = 1_in what is the problem with it?

Csaba

[rprosperi]

(09-16-2015 04:43 PM)Claudio L. Wrote:  I couldn't find any reference to this in years of discussions here and in comp.sys.hp48. My question about the usefulness is to see if this is a behavior worth replicating in newRPL. My guess is not.

Given that it has never been discussed before (!) it's quite likely it is not too useful in itself, it would seem to be a side-effect of how the parser and logic work. That said, I'd guess it will be quite difficult to get the rest of the Unit System correct (i.e. compatible) without also having the same side-effects, which is fine. In other words, I would not expend effort to prevent it from being included.

[Claudio L.]

(09-17-2015 12:38 AM)rprosperi Wrote:  That said, I'd guess it will be quite difficult to get the rest of the Unit System correct (i.e. compatible) without also having the same side-effects, which is fine. In other words, I would not expend effort to prevent it from being included.

As a matter of fact, I'm working on the units module of newRPL right now and I find the behavior difficult to replicate, that's why I was asking to see if I should put effort in trying to replicate it or just keep what I have now. My way of parsing the expression is perhaps much simpler than the 50g way.

[Tugdual]

Interesting discussion. I believe that the original 50g logic is correct.
Conceptually, a UOM is not a variable attribute but a simple multiplication.
50_m is equivalent to 50*m and then UOM can be handled as symbols.

This is powerful and aligned with what we do in physics and totally explains side effect.

[Csaba Tizedes]

(09-17-2015 06:22 AM)Tugdual Wrote:  This is powerful and aligned with what we do in physics and totally explains side effect.

Totally agreed!
Typically the problems generated when new guys picks up little parts of a well designed system (they thinks they can do it better) and they are puts a "time-bomb" inside the code.
My simple rule: never touch HP's after 48xx - and no problem.
(Just look at that f#&@&# R->P / P->R conversion on HP35s, I will never recover from that shock...)

Csaba

[Claudio L.]

(09-17-2015 06:22 AM)Tugdual Wrote:  Interesting discussion. I believe that the original 50g logic is correct.
Conceptually, a UOM is not a variable attribute but a simple multiplication.
50_m is equivalent to 50*m and then UOM can be handled as symbols.

This is powerful and aligned with what we do in physics and totally explains side effect.

The logic is indeed correct. My question was if it has any use, or in other words, if a compiler *needs* to specifically deal with units like 'm/2' or 'm^(2+3)'.
I can see one case where it needs to be: fractional exponents like m^(2/3)
The 50g would transform this exponent to a real 0.6666666667. I'll see if I can keep it as a fraction, that would be a nice improvement over the current system.

[Brad Barton]

What about conversions that don't lend themselves to a single conversion factor? In vibration when converting from say displacement readings to velocity readings, it is necessary to multiply by (2*pi*f) where f is the frequency expressed in Hz. Using what you've discovered, could we introduce a conversion that uses the entry in the Y register (or some other memory location) as part of the conversion?

displacement*(2*pi*f) = velocity
velocity*(2*pi*f) = acceleration
displacement*(2*pi*f)^2 = acceleration
and of course their inverses.


I know that this is a very simple program, but it would be nice if the conversion utility handled it natively; and possibly an interesting exercise.

Any other realms where this would be useful?

[Claudio L.]

(09-18-2015 02:56 AM)Brad Barton Wrote:  What about conversions that don't lend themselves to a single conversion factor? In vibration when converting from say displacement readings to velocity readings, it is necessary to multiply by (2*pi*f) where f is the frequency expressed in Hz. Using what you've discovered, could we introduce a conversion that uses the entry in the Y register (or some other memory location) as part of the conversion?

displacement*(2*pi*f) = velocity
velocity*(2*pi*f) = acceleration
displacement*(2*pi*f)^2 = acceleration
and of course their inverses.


I know that this is a very simple program, but it would be nice if the conversion utility handled it natively; and possibly an interesting exercise.

Any other realms where this would be useful?

Perhaps I'm not understanding your question correctly?
I think we are talking about different calculators. This discussion is for RPL calcs (48/49/50). In these calcs there's no Y register, and as long as you put proper units to your variables, everything should work:
displacement[mm]*(2*pi*f[Hz]) = mm*Hz=mm*(1/s)=mm/s
So your units of velocity would be correct. Similar thing for the other cases.

[Brad Barton]

(09-18-2015 01:01 PM)Claudio L. Wrote:  Perhaps I'm not understanding your question correctly?
I think we are talking about different calculators. This discussion is for RPL calcs (48/49/50). In these calcs there's no Y register, and as long as you put proper units to your variables, everything should work:
displacement[mm]*(2*pi*f[Hz]) = mm*Hz=mm*(1/s)=mm/s
So your units of velocity would be correct. Similar thing for the other cases.

"Y register", "Level 2 on the stack". I've used these terms interchangeably.

I was wondering if we could create a conversion factor that would automatically use a flexible numerical value taken from another memory location to convert between displacement and acceleration. I guess I'm asking: "Since you can put a number in the conversion factor (as you've demonstrated above), is it possible to "call" or "peek" a value from somewhere else and apply it as part of the conversion?"

Again, this is simplicity itself programmatically, but you end up having to deal with input commands, which are clunky. I've often wanted a "single button press" A-V-D sequence as part of the conversion operations on the 48/50g. I thought there might be a way to do that with what you've discovered.

[brickviking]

(09-18-2015 09:28 PM)Brad Barton Wrote:  I've often wanted a "single button press" A-V-D sequence as part of the conversion operations on the 48/50g.

"A-V-D"? Sorry, I don't know this abbreviation.

(Post 27)

[Brad Barton]

(09-18-2015 10:04 PM)brickviking Wrote:  "A-V-D"? Sorry, I don't know this abbreviation.

Acceleration>Velocity>Displacement

[Claudio L.]

(09-18-2015 09:28 PM)Brad Barton Wrote:  "Y register", "Level 2 on the stack". I've used these terms interchangeably.

I was wondering if we could create a conversion factor that would automatically use a flexible numerical value taken from another memory location to convert between displacement and acceleration. I guess I'm asking: "Since you can put a number in the conversion factor (as you've demonstrated above), is it possible to "call" or "peek" a value from somewhere else and apply it as part of the conversion?"

I think I understand what you want. You are calling a "unit conversion" the determination of the amplitude in a harmonic equation, for acceleration, velocity and displacement.
Conceptually very misleading, took me a while to figure out what you meant. But I'm not going to lecture you and go straight to the point.

I'm not sure unit conversions would help, a unit system is not really designed to work with variable conversion factors.
I guess once you know your frequency, you could define custom units with a fixed conversion factor of 2*pi*f, which has to be computed at the time of the unit definition. But if you change f, you'd have to redefine the units. I think it'd be easier to write a program that multiplies by 2*pi*f than creating custom units all the time.
The fact that the 50g accepts numeric factors at compile time wouldn't help you, since it happens only at compile time, meaning if you change the frequency you'd have to "recompile" the unit, so we are back to the previous case.

[Brad Barton]

(09-19-2015 05:49 PM)Claudio L. Wrote:  I'm not sure unit conversions would help, a unit system is not really designed to work with variable conversion factors.
I guess once you know your frequency, you could define custom units with a fixed conversion factor of 2*pi*f, which has to be computed at the time of the unit definition. But if you change f, you'd have to redefine the units. I think it'd be easier to write a program that multiplies by 2*pi*f than creating custom units all the time.
The fact that the 50g accepts numeric factors at compile time wouldn't help you, since it happens only at compile time, meaning if you change the frequency you'd have to "recompile" the unit, so we are back to the previous case.

I see. Thank you for the explanation.

[Tugdual]

Also Having variables within UOM jeopardizes further derivatives. Not a good practice IMO let's leave this to finance people and exchange rates.

[Csaba Tizedes]

(09-18-2015 09:28 PM)Brad Barton Wrote:  ...if we could create a conversion factor ... to convert between displacement and acceleration. ... a value ... apply it as part of the conversion?

The only problem is that, what you want above that is not "unit conversion". You can not adds apples to oranges. In this case the result is "Inconsistent units".

That "a value" has dimension.

Csaba

[Claudio L.]

(09-18-2015 09:28 PM)Brad Barton Wrote:  I was wondering if we could create a conversion factor that would automatically use a flexible numerical value taken from another memory location to convert between displacement and acceleration. I guess I'm asking: "Since you can put a number in the conversion factor (as you've demonstrated above), is it possible to "call" or "peek" a value from somewhere else and apply it as part of the conversion?"

After a few days I found myself needing something similar, so your idea wasn't so crazy after all.
I'm not really looking at a variable conversion rate, but I need the conversion rate to have variable precision, therefore it's a different number depending on the system precision (practically, it's the same problem for a different purpose).
Think for instance the conversion from degrees to radians. The factor pi/180 would need to be recomputed at the current system precision to produce an accurate conversion, so I do need a way to recall a constant 'pi/180' from some external source, rather than have a number pre-computed as part of the unit definition.
I'm writing this because my own post made it seem like a not-so-good idea (at the time). Now it hit me, and I need to implement it somehow (still trying to figure out that part).