newRPL: Handling of units

[Claudio L.]

(05-08-2016 01:30 PM)JoJo1973 Wrote:  

• _galUK: Imperial gallon = exactly 4.546092_l
• _galC: New Imperial gallon used in Canada = exactly 4.54609_l (note the missing last digit!)
• _gal: Winchester gallon = exactly 231_in^3
  

The trick is that _galUK has been in use from 1976 to 1985, when UK switched to _galC. I think it would be more sensible to retain the difference between the two definitions as HP did, and add a new definition for the Canadian (and later UK ounce): 1_galC = 160_ozC.

The HP Prime team has also created alternative definitions for the pint and the bushel to take into account the different gallons, even if the effort has not taken to the full consequences. The HP50's _pt and _bu have been renamed to _liqpt (why?!?) and _buUS, a new _ptUK has been created and a new _bu unit has been defined using the Canadian gallon.

Very confusing, IMHO.

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

[JoJo1973]

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:  

• _galUK: Imperial gallon = exactly 4.546092_l
• _galC: New Imperial gallon used in Canada = exactly 4.54609_l (note the missing last digit!)
• _gal: Winchester gallon = exactly 231_in^3
  

The trick is that _galUK has been in use from 1976 to 1985, when UK switched to _galC. I think it would be more sensible to retain the difference between the two definitions as HP did, and add a new definition for the Canadian (and later UK ounce): 1_galC = 160_ozC.

The HP Prime team has also created alternative definitions for the pint and the bushel to take into account the different gallons, even if the effort has not taken to the full consequences. The HP50's _pt and _bu have been renamed to _liqpt (why?!?) and _buUS, a new _ptUK has been created and a new _bu unit has been defined using the Canadian gallon.

Very confusing, IMHO.

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

[JoJo1973]

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.

I thought about a USIMPLIFY too, but I found myself in trouble trying to decide what the user would want. It's not trivial for example:

1_km/m^2 = ???

What should be the simplification answer? 1000_m^-1 or should we convert to km then simplify? in such case it would be 1000000_km^-1

A more complex case:
1_N/m

Since 1_N=1_kg*m/s^2, should we simplify to 1_kg/s^2?

One more, F=m*a:

1_kg*3_m/s^2, how does the system know that this is actually 3_N, or why not 3_J/m? It depends on whether you prefer to see this as a force, or as work per meter.
I could not find a systematic (as in programmable) way to make that decision. Sometimes it's best to expand units into their components and simplify, some others to collect the components into more complex units.

I thought the best approach would be to have somehow (not quite sure how to implement this) a desired unit for variables. Let's say you have global variable A. Somehow you tell the system you want A to be in 1_N/m, then every time you STO something in A, the system will try to convert to the desired units, and error if the units can't be converted (means you made a mistake somewhere).
The idea would be to have each problem in a directory, where the variables have preassigned units (and therefore their associated physical magnitudes).

Another property, besides unit, could be for example a formula to auto-compute this variable.
For example, let's do F=m*a, where the user inputs m and a, and F is a variable that has:
a) A preferred unit of 1_N as a "property"
b) A formula 'm*a' as a property
c) A result (this is the content of the variable, not a property)

When the user stores something in 'm' or 'a', automatically triggers a re-evaluation of the formula in 'F', and the result of that evaluation is stored in F as a result, converted to the preferred units.

Now let's add another variable, let's say M=F*d, with d a distance.
M.unit=1_N*m
M.auto='F*d'

And whenever the user stores a new value in 'd' or in 'F', it triggers auto-recalculation of M.
So you can setup a problem in a directory this way, and when you change your input variables, everything else is automatically recalculated, just like a spreadsheet would, but there's no cells (more like a MathCAD worksheet I would say).

I have had this (without the units part) working written in sysRPL for many years, it's what I use almost exclusively to get quick results for concrete design, etc at work. I just change the input variables, and then look at the output variables. The autocompute property doesn't have to be a formula, could be a program too.
You can even try intermediate values, as there's no harm in for example manually plugging a value for 'F' in the example above. It would trigger a recalculation of 'M' with the given F, although F will no longer meet the 'm*a' condition.

Since it's been useful to me, I wonder if this should be a standard feature in newRPL.

[Claudio L.]

(05-09-2016 09:27 PM)JoJo1973 Wrote:  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.

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

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.

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.

[Vtile]

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,

I've discovered your NewRPL project and I must say it's really exciting to follow your efforts in reimagining the old faithful User RPL, at the same time ironing out some of the limitations that today are perceived as such, but at the time were more than acceptable... "Life is short, and ROM is full", as they say!

What has attracted me most is your treatment of units and angles as native objects: having units attached to vectors and symbolics allows for powerful calculations in a very straightforward manner.

Having read previous posts on the argument, I remember you (or someone else) have expressed interest in a including the units supported by the HP Prime amongst the ones already present in the code, but also that a complete list was not available.

With the help of the emulator I've compiled such a list and took the chance to test the accuracy of the conversion factors. An invaluable help in such a task is the Numericana blog (http://www.numericana.com/) which in the past has scrutinized the implementation of the units package in the HP50G and the HP Prime. See for example http://www.numericana.com/answer/hp-prime.htm#units

I'll report below my findings, citing references where necessary. At the moment I've used the Alpha 5 Demo to perform my test, but I count on doing on the real hardware as soon as possible!

1. Length and Area
   Nothing to report here: NewRPL already supports the unit presents on HP50G and HP Prime.
2. Volume
   Here things get messy and complicated: the culprit is the definition of gallon, which has changed in time and space! Fundamentally, the situation on the HP50G (which I take as reference since it inherits the definitions of the HP48SX/GX) define three different gallons (see http://www.numericana.com/answer/units.htm#floz and http://www.numericana.com/answer/units.htm#gallon for a lenghtier discussion).
   
   • _galUK: Imperial gallon = exactly 4.546092_l
   • _galC: New Imperial gallon used in Canada = exactly 4.54609_l (note the missing last digit!)
   • _gal: Winchester gallon = exactly 231_in^3
     
   
   The trick is that _galUK has been in use from 1976 to 1985, when UK switched to _galC. I think it would be more sensible to retain the difference between the two definitions as HP did, and add a new definition for the Canadian (and later UK ounce): 1_galC = 160_ozC.
   
   The HP Prime team has also created alternative definitions for the pint and the bushel to take into account the different gallons, even if the effort has not taken to the full consequences. The HP50's _pt and _bu have been renamed to _liqpt (why?!?) and _buUS, a new _ptUK has been created and a new _bu unit has been defined using the Canadian gallon.
   
   Very confusing, IMHO.
   
   Since all the units have the same relative weight, differing only in the definition of the base unit (with the exception of the _ozfl) I have this proposal for NewRPL:
   
   • a set of US units: _gal, _ozfl (= 1/128_gal), _pt, _qt, _bu, _pk, _tsp, _tbsp
   • a set of Old Imperial units: _galUK, _ozUK (= 1/160_galUK), _ptUK, _qtUK, _buUK, _pkUK, _tspUK, _tbspUK
   • a set of New Imperial units: _galC, _ozC (= 1/160_galC), _ptC, _qtC, _buC, _pkC, _tspC, _tbspC
     
   
   A bit overkill, but coherent!
3. Speed
   HP Prime team has conveniently added definitions for _rad/s, _tr/min (= 2*pi_rad/min) and _tr/s (= 2*pi_rad/s). Very useful to have a dedicated definition so you don't have to navigate Angle and Time menus.
   
   *** WARNING: There is a bug in NewRPL! 1_rpm shouldn't be 60_1/s, but rather 1_1/min ***
4. Mass
   Here HP Prime team has only renamed the _ton to _tonUS: If my proposal for volume units is accepted, I'd suggest to leave the name unchanged, coherently with the convention of not tagging US customary units with "US".
   
   BTW, could you add the _gmol (= 1_mol) and the _lbmol (= 453.59237_gmol, exactly) to the catalogue? These units were present in the HP50G, under an Equation Library submenu.
5. Acceleration
   This is a new menu specific of the HP Prime: I find it very convenient, since these units often don't have a dedicated name such as Newton or Ampere and require a lot of keystrokes to be entered. Here we have:
   
   • _m/s^2
   • _ft/s^2
   • _grav, which is just _ga with a fancy name
   • _Gal (= 1_cm/s^2)
   • _rad/s^2
     
6. Power
   Hp Prime added convenient shortcuts for _MW and _ft*lbf/s.
   May I suggest the addition of the metric horsepower (1_ch = 75_m*kgf/s) and the _Btu/h?
7. Electricity
   HP Prime team added a shortcut for the _A*h.
8. Angle
   Added the _gon (= 1_grad, it's an alias used in some countries) and the _tr (= 2*pi_rad).
   Since you've turned the _sr into a fully recognized unit would you consider adding _spat (= 4*pi_sr), _°^2 (= (pi/180)^2_sr), _arcmin^2 (= 1/3600_°^2) and _arcs^2 (= 1/3600_arcmin^2)? They're currently used in many astronomy textbooks.
9. Viscosity
   HP Prime team added a shortcut for the _m^2/s. Maybe an alias for the _kg/(m*s) would be useful too? in my textbooks I've never seen Poises or Stokes, but only their cumbersome SI counterparts.
10. Light
    Nothing to report here, but kudos for having made explicit the presence of steradians in the definitions of some units!
11. Radiation
    Nothing to report here too.
12. Pressure
    The _inH2O has a precise and exact definition, based on a conventional value of water density: therefore 1_inH2O is exactly defined as 1_in*1_ga*999.972_kg/m^3 (see: http://www.numericana.com/answer/constants.htm#h2o).
    
    1_torr is not equal to 1_mmHg (and besides, it's _Torr). The explanation is that, as you correctly implemented in NewRPL, 1_mmHg = 1_mm*1_ga*13595.1_kg/m^3 (exactly); on the contrary, the _Torr is defined as (101325/760)_Pa (exactly). The two values are very close, but are not the same... (see: http://www.numericana.com/answer/casio.htm#mmhg).
13. Energy
    This is complicated: first of all, http://www.numericana.com/answer/casio.htm#ist eloquently asserts that since 1935 all the results published in calories refer to the thermodynamical calorie: 1_cal = 4.184_J. All other definitions of calorie are either unaccurate or bogus or obsolete.
    
    But let's go on: HP Prime team defines two shortcuts for _Wh and _kWh: so far, so good.
    
    Now, here come the _therm...
    
    HP Prime gives three different definitions of _therm, and none of them match the definition of the HP50G or the definition in NewRPL, because they depend on the definition of the _Btu, and they are legion.
    
    To get the things straight:
    
    • The _therm is always defined as 10^5_Btu, whatever a _Btu is.
    • NewRPL's _Btu is the so-called Btu_IT: it's definition is precise, accepted and widespread, but unfortunately none of the _therm's is actually defined upon it.
    • _thermEC is defined as 10^5_Btu_ISO and it's exactly 105505600_J
    • _therm is defined as 10^5_Btu_59°F and it's exactly 105480400_J
    • _thermUK is defined as 10^5_some_unknown_Btu_noelsewhere_defined: it's value is exactly 105505585.257348_J. I have no primary source to justify this value, but since all secondary sources bother to list 6 decimals, I assume that the conversion factor is exact.
      
    
    Next, follows some technical units used in the industry, but not used in scientific papers:
    
    • _toe (Tonne of Oil Equivalent) = exactly 41.868_GJ. Source: https://www.iea.org/publications/freepub...manual.pdf
    • _boe (Barrel of Oil Equivalent) = exactly 5.8*10^6_BTU_59°F = 6117863200_J. Source: http://www.irs.gov/pub/irs-drop/n-99-18.pdf
    • _tec (Tonne of Coal Equivalent) = 27.84_GJ (as reported by the HP Prime). This one is unconfirmed: none of the definitions I've found on the web match the value reported by the HP Prime.
    • _lep (Liter of ??? Equivalent) = 35788320_J (as reported by the HP Prime). I haven't been able to find any info about this unit. Comparing it with the next unit, it's evident that the 'l' stands for 'liters'.
    • _bblep (Barrel of ??? Equivalent) = 5689888186.82_J (as reported by the HP Prime). Absolutely no info found about this one, except for the fact that it expresses a _lep in barrels (_bbl) units: multiplying 35788320_J*1_bbl/l you get the value provided by the HP Prime.
    • _cf (???) = 1080000_J (as reported by the HP Prime). This one too remains a mystery to me. At least, the conversion factor seems exact.
      
14. Other
    The decibel (1_dB = 1) is the last of the units present in the Equation Library and actually is not supported by NewRPL. It should be added for compatibility's sake. Maybe it could be put in the Electricity catalogue, but could also become the first unit of a new Adimensional catalogue.
    

I hope I haven't been too nitpicky, but I'm really interested in NewRPL, and I wish it sports the most up-to-date set of conversion units!

Regards,
Stefano

[Claudio L.]

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.

[JoJo1973]

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

[Helix]

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

[Claudio L.]

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

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

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?

[Helix]

Here are three examples, with the corresponding screens:
- Length 1 ft 1 ft
- Length 1 m 1 m
- Length NXT… NXT… NXT… NXT… Units

[Claudio L.]

(05-12-2016 11:58 PM)Helix Wrote:  Here are three examples, with the corresponding screens:
- Length 1 ft 1 ft
- Length 1 m 1 m
- Length NXT… NXT… NXT… NXT… Units

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.

[Claudio L.]

(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:
- Length 1 ft 1 ft
- Length 1 m 1 m
- Length NXT… NXT… NXT… NXT… Units

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.

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.

[Helix]

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 .

[Claudio L.]

(05-13-2016 11:12 PM)Helix Wrote:  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 .

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

[StephenG1CMZ]

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.