Numbers within units (50g)

[Brad Barton]

(09-22-2015 07:37 AM)Csaba Tizedes Wrote:  

(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

In this case the "value" wouldn't be dimensionless. It would have units of Hz or CPM.

Brad

[Brad Barton]

(09-22-2015 05:43 PM)Claudio L. Wrote:  After a few days I found myself needing something similar, so your idea wasn't so crazy after all.

Well I feel a little better then.

(09-22-2015 05:43 PM)Claudio L. Wrote:  Now it hit me, and I need to implement it somehow (still trying to figure out that part).

Looking forward to your solution. Perhaps I'll be able to use if for my purposes. Please keep us posted.

Brad

[Claudio L.]

(09-23-2015 04:53 AM)Brad Barton Wrote:  Looking forward to your solution. Perhaps I'll be able to use if for my purposes. Please keep us posted.

Brad

Here's what I did to solve my problem. It's basically what we discussed above, defining custom units, and it's actually quite simple and it works well also on the existing 50g.

For example, the surveyor's ft(US) is defined different from the standard ft (defined to be exactly 0.3048_m).

The 50g defines it with 12 digits, and that's fine. However, the exact definition is:

ftUS = 1200/3937 m

To obtain the constant 1200/3937 at various precisions what I do is define a hidden unit:

MyConst = 3937

Then, the definition of ftUS is:

1_ftUS = 1200_m/MyConst

This way, when you do UBASE or you use CONVERT, the unit is expanded to 1200/3937 and the operation is performed at run time, rather than having a predetermined constant.
Since MyConst is expanded automatically, the user will never get to see it.

This solution only works partially for me, because I still have some conversion constants that are irrational, like pi/180. In that case I will define a hidden unit that the system will replace at runtime, because storing PI at maximum system precision would be bad for speed.
So far only PI will have that problem, all other constants involved in unit definitions seem to be rational.

In your case, I guess you could define 3 units:
dAm= 1_mm
vAm= 6.28...._freq*dA (here 6.28... is 2*PI with 12 digits precision)
aAm= 6.28...._freq*vA

And then store the frequency in 'freq' with units of Hz (here dAm, vAm and aAm are auxiliary units of displacement amplitude, velocity amplitude, and acceleration amplitude). I used 'Am' to avoid conflict with 'A' for Ampere, as dA is a valid unit with an SI prefix.
Not sure how this is better than just multiplying by 2*pi*f, but it's one possible approach.