Numbers within units (50g)

09232015, 04:46 AM
Post: #21




RE: Numbers within units (50g)
(09222015 07:37 AM)Csaba Tizedes Wrote:(09182015 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? In this case the "value" wouldn't be dimensionless. It would have units of Hz or CPM. Brad 

09232015, 04:53 AM
Post: #22




RE: Numbers within units (50g)
(09222015 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. (09222015 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 

09232015, 07:03 PM
Post: #23




RE: Numbers within units (50g)
(09232015 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. 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. 

« Next Oldest  Next Newest »

User(s) browsing this thread: 1 Guest(s)