newRPL: Handling of units
|
05-09-2016, 05:42 PM
Post: #21
|
|||
|
|||
RE: newRPL: Handling of units
(05-08-2016 01:30 PM)JoJo1973 Wrote: I'm not sure I agree, when a unit is redefined we should use the latest definition, and perhaps keep the old one with a special name. I think galUK should be the modern galUK as people doing calculations now will be expecting the "new" galUK (I'm quoting "new" since it's been in place for >30 years!). I didn't check your dates, but if it's true the old galUK was in place for only 9 years, then how do we justify that definition taking the center stage? I think galUK should stay with the modern definition by default. However... Did you know that newRPL supports redefinition of system units? All you have to do is: 4.546092_l 'galUK' UDEFINE And your gallon UK now has the pre-1985 definition. Now if you don't think that's cool enough, read this: Every time galUK appears in a user or system definition, it will use the newly defined value. This means all units derived from the gallon UK will automatically use the new definition (_ptUK, _qtUK, etc, which I'll add per your post). |
|||
05-09-2016, 06:05 PM
Post: #22
|
|||
|
|||
RE: newRPL: Handling of units
You're right. I didn't take into account the fact that in the new implementation the redefinition of a parent unit cascades onto the derived units automatically... User RPL doesn't allow this!
From a user's point of view, the only thing that matters is a consistent naming of the units, so that dependencies are clearly identifiable by inspection. (05-09-2016 05:42 PM)Claudio L. Wrote:(05-08-2016 01:30 PM)JoJo1973 Wrote: |
|||
05-09-2016, 09:27 PM
Post: #23
|
|||
|
|||
RE: newRPL: Handling of units
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. |
|||
05-11-2016, 02:49 AM
Post: #24
|
|||
|
|||
RE: newRPL: Handling of units
(05-09-2016 09:27 PM)JoJo1973 Wrote: I think that there are two competing issues there: cancellation of redundant units, and simplification strategies.I made a small change today: now non-dimensional base units are consistent with plain numbers. This doesn't make the radians disappear from the units, but makes it completely transparent, as you can have 1_m*r/s, coming from V=r*w, for example, and you can add 1_m/s, they will be considered consistent. You can also convert to 1_kph and the units will be consistent. There's other side effects, like adding a plain number is equivalent to adding 1_r, or 1_dB. Another, perhaps less desirable side effect is that unrelated non-dimensional units are convertible among themselves: you can convert 1_r into 1_dB and it's not an error: the units are indeed consistent. Also, you can add r/s to Hz and it's OK, because both are 1/s in the end. 180_° 0.1 + --> 185.7..._° I added 1_tr = 2*pi_r, and redefined 1_rpm = 1_tr/min This means now rpm can be converted directly into other angular speeds like r/s, or 1/s. (05-09-2016 09:27 PM)JoJo1973 Wrote: 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). I looked at UTOOLS. The menu is cool, the partial factorization of units is helpful. USIMP simply does UFACT on each element of the list. It's a start, but not too elaborated. And the user always has to "manually" define a list of their preferred units, and then "manually" again apply USIMP. |
|||
05-11-2016, 02:27 PM
(This post was last modified: 05-11-2016 03:11 PM by Vtile.)
Post: #25
|
|||
|
|||
RE: newRPL: Handling of units
Imperial units are a total mess, it is really nice that we have SI unit system these days. Here is a picture of a conversion tables from a technical handbook from 1947. Just to get a picture how messy the imperial system have been still in 70 or so years ago in lenght units (Inch & feets) alone, not to mention all other units in use. I just wanted to share this as a engineering general education.
Edit. It seems I miss readed the metric feet (or is it foot) anyways.. is 1/3 meters not 1/8 meters as my quick translation according this old era of a book. http://i.imgur.com/jYEJadO.jpg Edit2. Would it be handy if there would be a command something like "unithelp" that would give the user the definition of the unit as it is used in calculator. Ie. 1_galUK unithelp would give a short description how UK gallon have changed in time and what is the one used in calc. (05-08-2016 01:30 PM)JoJo1973 Wrote: Hello Claudio, |
|||
05-11-2016, 05:01 PM
(This post was last modified: 05-11-2016 05:05 PM by Claudio L..)
Post: #26
|
|||
|
|||
RE: newRPL: Handling of units
For those wishing to test this, I updated the ROM image in the usual place (not going to advertise it since it's a minor update)
The changes are: * Added consistent named units for galUK, ptUK,qtUK, buUK and pkUK, as well as their Canadian counterparts. Didn't add tspUK and tbspUK. * Added various speed shortcuts * Added gmol and lbmol units (although gmol is just an alias, for naming consistency it needs to be there) * Added acceleration menu with various shortcuts * Added various shortcuts for power and electricity * Added the turn _tr but not the gon, it's easy to define the alias if somebody doesn't like _grad. * Added _spat, but not the square degrees and variants, as they would choke the parser. * Redefined rpm as 1_tr/min * Added shortcuts for viscosity * Fixed inH2O definition * Renamed Torricelli to _Torr and fixed its definition * Redefined calorie as cal=4.184_J. Created calIT=4.1868_J * Redefined Btu as 105505600_J (ISO variant). Created BtuIT with the IT definition. * therms are now based off of ISO Btu, therefore are thermEC which was intended from the beginning *Added dB as a non-dimensional unit None of those tonne equivalent or liter equivalent units were added. Unrelated to units, there were only 2 changes: * Auto-OFF time set to 2 minutes by default * Fixed glitch that left intermediate arguments in the undo stack. As usual, test, report and comment. Thanks for the help polishing this module, and feel free to bring up more issues. |
|||
05-12-2016, 11:18 AM
Post: #27
|
|||
|
|||
RE: newRPL: Handling of units
Therefore pure numbers are considered as radiants when combined with angular units?
Sounds reasonable: unfortunately the an adimensional quantity involves a number of compromises when dealing with unit-tagged numbers. The important thing for the end user is that the implementation is coherent and behaves in a predictable and "common sense" manner. (05-11-2016 02:49 AM)Claudio L. Wrote: I made a small change today: now non-dimensional base units are consistent with plain numbers. |
|||
05-12-2016, 01:07 PM
(This post was last modified: 05-12-2016 01:27 PM by Helix.)
Post: #28
|
|||
|
|||
RE: newRPL: Handling of units
(05-11-2016 05:01 PM)Claudio L. Wrote: As usual, test, report and comment. Thanks for the help polishing this module, and feel free to bring up more issues. This units module seems totally buggy for me. I get an "Exception : Data abort" very often, in an unpredictable way, even after a memory wipe. Am I alone in this case? Also, on an aesthetic note, the first row of black pixels is missing in front of the titles: "Accel" and "Angle". Jean-Charles |
|||
05-12-2016, 04:58 PM
Post: #29
|
|||
|
|||
RE: newRPL: Handling of units
(05-12-2016 01:07 PM)Helix Wrote:(05-11-2016 05:01 PM)Claudio L. Wrote: As usual, test, report and comment. Thanks for the help polishing this module, and feel free to bring up more issues. Maybe I broke something when doing the latest changes. Can you give me something reproducible to test? What about the data on the Data abort screen? Can I get the value of R15? |
|||
05-12-2016, 11:58 PM
Post: #30
|
|||
|
|||
RE: newRPL: Handling of units
Here are three examples, with the corresponding screens:
- Length 1 ft 1 ft - Length 1 m 1 m - Length NXT… NXT… NXT… NXT… Units Jean-Charles |
|||
05-13-2016, 01:43 AM
Post: #31
|
|||
|
|||
RE: newRPL: Handling of units
(05-12-2016 11:58 PM)Helix Wrote: Here are three examples, with the corresponding screens: I confirmed it with the simulator, thank you. Nothing to do with units, it seems I broke the undo feature. I'll work on it and post a new ROM in short. My apologies. |
|||
05-13-2016, 01:35 PM
Post: #32
|
|||
|
|||
RE: newRPL: Handling of units
(05-13-2016 01:43 AM)Claudio L. Wrote:(05-12-2016 11:58 PM)Helix Wrote: Here are three examples, with the corresponding screens: Fixed, please download the new ROM update. The bug was tricky, as the code was correct, but a macro definition was missing a set of parenthesis, and only for the 32-bit compiler, so my tests on the 64-bit simulator didn't fail, but when I built the ROM (32-bit) the bug showed up. |
|||
05-13-2016, 11:12 PM
Post: #33
|
|||
|
|||
RE: newRPL: Handling of units
Thank you! It works much better now
Don't forget my previous remark about the menus "Angle" and "Accel". It's just aesthetics, but you know I am picky about aesthetics . Jean-Charles |
|||
05-14-2016, 02:57 AM
Post: #34
|
|||
|
|||
RE: newRPL: Handling of units
(05-13-2016 11:12 PM)Helix Wrote: Thank you! It works much better now Fixed. But since it's merely cosmetic, it will come out in the next update. It was a rounding error in the text centering (half-pixel off, so in certain cases it would go all the way to the left as you pointed out correctly). |
|||
08-10-2017, 09:34 AM
Post: #35
|
|||
|
|||
RE: newRPL: Handling of units
I would just like to express my disappointment at tonnes of oil equivalent being called 1_toe.
In the same way that half a byte is humorously called a nibble, I would have like 1_toe to be 1/5 foot (or should that be 1/10 feet?). Exactly 2.4_inch - or less precisely, a couple of inches. Stephen Lewkowicz (G1CMZ) https://my.numworks.com/python/steveg1cmz |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 5 Guest(s)