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