HP Forums

Full Version: [WP 34S] Ideas for improving unit conversions
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2

1. U.S. survey foot & co.

Two units based on the U.S. survey foot are called 'feetUS' and 'acreUS' in the WP 34S conversion menu. These names are potentially misleading because they seem to suggest that it's the survey foot based units that are typically used in the United States. However, as explained in http://physics.nist.gov/Pubs/SP811/appenB.html#B.6 and http://en.wikipedia.org/wiki/Foot_%28len...urvey_foot survey foot based units are only used to represent geodetic data (and not even all geodetic data). The U.S. uses the international foot, and units derived from that, in most cases.

Therefore I suggest that 'feetUS' be renamed to 'srv.ft', 'acreUS' to 'srv.ac', and 'acreUK' to plain 'acres'. I've attached a small patch that accomplishes this.

Fathoms should receive the same treatment, i.e. international fathoms should be distinguished from U.S. survey fathoms. The NIST document only mentions fathoms based on the U.S. survey foot (by contrast it explicitly lists the two types of feet and miles), however, there are references to international fathoms elsewhere. The only fathom conversion currently available in the WP 34S is based on the U.S. survey foot, so my patch renames 'fathom' to 'sv.ftm' and adds 'fathom' as a new conversion for international fathoms. Fathoms are rarely used nowadays AFAIK and they are very easy to convert as a fathom of either type is precisely two yards of the same type, so I'm not sure it makes sense to include fathom conversions at all.

2. Cubic foot

Cubic feet are called 'cft' in the WP 34S but to the best of my knowledge this abbreviation is rarely used and in my opinion it may not be immediately obvious what it stands for. I suggest the much more commonly seen 'cu ft' instead.

3. Square foot and miles per gallon

The relatively benign square foot and the truly horrendous miles/gallon appear quite often in the lives of those of us who have to deal with non-metric units. I've attached a patch that adds the (international) square foot and both the U.K. and U.S. miles/gallon conversions (as well as the 'cu ft' name change). They can be enabled or disabled at compile time so they take up no space in the firmware for those who don't want them. The miles/gallon conversions only appear once each in the imperial<->metric form (using double arrows, see the picture) because the same calculation is performed in both directions and the conversion catalog is less cluttered this way. Also the metric part (l/100 km) has to be abbreviated a little too much so in my opinion it looks better if it only shows up on the right side. (This could be easily changed.)

[attachment=224]

4. Order of conversions in the catalog

Currently arrows come after letters in the alphabetical order when sorting catalogs. This results in e.g. 'mmHg->Pa' preceeding 'm->feet' in the conversion menu. I found it rather confusing because it's the opposite of how things are typically sorted. Arrows would usually be considered separators and shorter words (the part before the arrow) would come before longer ones. I've attached a patch that changes this as a compile time option. It has no effect on firmware size and catalog navigation works as before.


Any feedback is welcome.

Edit: Updated patches and compiled binaries are available in Bit's WP 34S and 31S patches and custom binaries.
Please see the footnote on p. 155 (of 244) of the manual.

d:-I
(02-02-2014 01:06 AM)walter b Wrote: [ -> ]Please see the footnote on p. 155 (of 244) of the manual.
I don't have a printed manual yet, the only thing I could find was footnote 66 on page 139 (of 211) of the PDF manual that begins with "The SI system of units". If that's what you're referring to, I don't understand your point. Can you please elaborate?
Things I did not know. The foot changed from 1200/3937 meter to 1200/3948 meter.
(02-02-2014 01:39 AM)Bit Wrote: [ -> ]
(02-02-2014 01:06 AM)walter b Wrote: [ -> ]Please see the footnote on p. 155 (of 244) of the manual.
I don't have a printed manual yet, the only thing I could find was footnote 66 on page 139 (of 211) of the PDF manual that begins with "The SI system of units". If that's what you're referring to, I don't understand your point. Can you please elaborate?

Said chapter begins with
CONV mainly provides the means to convert local to common units.
and then points to the footnote which reads:
The SI system of units is agreed on internationally. Meanwhile, it is adopted by all countries on this planet except three. Thus for the overwhelming majority of readers, most of the units appearing in CONV may look obsolete at least. They die hard, however, in some corners of this world (English is spoken in all of them). For symmetry reasons, we think about adding some traditional Indian and Chinese units to CONV.
This table may also give you a slight idea of the mess we had in the world of measures before going metric.


WP 34S project is closed now. We'll repair bugs when somebody detects - we won't add any new content anymore. I read your post and didn't find anything pointing to a bug (maybe I missed something? Then please help me and point me to it.).

OTOH, the whole Imperial stuff takes already too much space in CONV (despite its name, there isn't anything like an 'international foot' in real life). Let those folks crash Mars probes and cry for 7/64 tools as long as they want, I don't care.

d:-/
(02-02-2014 01:30 PM)walter b Wrote: [ -> ]Said chapter begins with
...


I would be the last person on Earth to advocate the use of non-metric units, but unfortunately it's not within my power to phase them out. Given that the calculator provides those conversions already, making them better wouldn't be a statement in favor of obsolete units, it'd only make the WP 34S a better tool.

Since you asked, I think it's arguable that the first point about the U.S. survey units not being presented clearly (are they commonly used in the U.S.? no) or consistently (why isn't the fathom called ftmUS if there's feetUS?) could be considered a bug.

Most of what I've seen about the WP 34S suggested that it is (was?) a very ambitious project with a lot of attention given to detail. Granted, my suggestions are trivial and about a topic that isn't of primary importance, but I believe they are an improvement (certainly points 1, 2 and 4) and as such I thought they'd be a welcome contribution (unless someone points out a mistake I made). I was hoping for feedback on their objective merits rather than a discussion about our likes and dislikes for things we cannot change.

It's funny you mentioned the Mars probe, I bring it up very often in real life discussions but alas people around me don't listen. Smile
(02-02-2014 02:13 PM)Bit Wrote: [ -> ]Since you asked, I think it's arguable that the first point about the U.S. survey units not being presented clearly (are they commonly used in the U.S.? no) or consistently (why isn't the fathom called ftmUS if there's feetUS?) could be considered a bug.

Like a few other things, also CONV saw some uncontrolled expansion during the project. My fault. I didn't care enough about those items since I don't need them anyway. Looking from today, the fathom may be dropped. So I agree on your suggestion there.

About the different feet (of various kings and common men Wink ): Please see p. 156 (of 244) for their explanations. What's wrong or unclear there?

Some topics from your OP:
  • cft vs. cu ft: AFAIK blanks are no legal characters in a unit name on the WP 34S. There is no official abbreviation established (mess!) but cu.ft or ft³ or cbft would be possible, the latter matching sqft well (consistency is no criterium there, I know, but nevertheless). Could be changed. In fact, the cubic foot was only included for its conversion to liters which OTOH may be calculated easily taking the linear foot. So cft may be dropped as well.
  • acres: I don't see any acreUK on my WP 34S. Which build do you run?
  • sqft: Please see cft above. I vote against introducing sqft in CONV.
  • mi/gal: In fact, that's inverse proportional to l/100 km. We did (and do) not intend to include any combined units in CONV for sake of keeping Pandora's box closed.
  • arrows: We've got some arrows being part of command names. Thus the sorting order.

Hope this explains some of your observations.

d:-I
Bit,

build your own device! Wink

I can imagine very well that preferences for daily use of a tool are not directly linked to a clean design. Some quirks (in the eyes of the designer) might be just goodies in the eyes of a user. So feel free to implement your ideas and publish them at will. They will not become part of the official branch but why bother?
(02-02-2014 04:44 PM)walter b Wrote: [ -> ]About the different feet (of various kings and common men Wink ): Please see p. 156 (of 244) for their explanations. What's wrong or unclear there?
As I wrote above, currently I only have access to the PDF manual (version 3.1, generated on Nov 30, 2012). I cannot figure out where page 156 is supposed to be in a different version of that document. Could you please give page references based on what's available online? Or did I miss something and is the 244 page version available somewhere in electronic form?
I'd prefer that to some thick block of dead trees anyway. Wink

(02-02-2014 04:44 PM)walter b Wrote: [ -> ]cft vs. cu ft: AFAIK blanks are no legal characters in a unit name on the WP 34S. There is no official abbreviation established (mess!) but cu.ft or ft³ or cbft would be possible, the latter matching sqft well (consistency is no criterium there, I know, but nevertheless). Could be changed. In fact, the cubic foot was only included for its conversion to liters which OTOH may be calculated easily taking the linear foot. So cft may be dropped as well.
I used two narrow spaces and modified dump_opcodes() in pretty.c to create aliases with the narrow spaces removed. It seems to work just fine. That said, 'cu.ft' may be a better idea.

(02-02-2014 04:44 PM)walter b Wrote: [ -> ]acres: I don't see any acreUK on my WP 34S. Which build do you run?
I run a build I checked out from svn a few days ago (revision 3470). You're right, 'acreUK' doesn't show up on the WP 34S screen, but it's present in compile_cats.c.

(02-02-2014 04:44 PM)walter b Wrote: [ -> ]
  • sqft: Please see cft above. I vote against introducing sqft in CONV.
  • mi/gal: In fact, that's inverse proportional to l/100 km. We did (and do) not intend to include any combined units in CONV for sake of keeping Pandora's box closed.
Fair enough, that's why I made both compile time options to begin with.

(02-02-2014 04:44 PM)walter b Wrote: [ -> ]arrows: We've got some arrows being part of command names. Thus the sorting order.
I'm aware of that, but would changing the order of commands this way make it less logical than the current one? I thought it wouldn't but I might be missing something.
(02-02-2014 05:07 PM)Marcus von Cube Wrote: [ -> ]Bit,

build your own device! Wink

I can imagine very well that preferences for daily use of a tool are not directly linked to a clean design. Some quirks (in the eyes of the designer) might be just goodies in the eyes of a user. So feel free to implement your ideas and publish them at will. They will not become part of the official branch but why bother?

I'm already building my 'own' device in the sense that I'm working on relatively small modifications I intend to use myself. I just thought I'd share them so others could also benefit.

There can be valid arguments in favor of periods vs. spaces, or over whether the inclusion of combined units is justified etc. but frankly I find it perplexing that a proposal to clarify references to U.S. survey foot based units is met with a flat-out rejection rather than either pointing out a mistake I made or welcoming the correction.

I'll take your advice, there's not much else I can do. Smile
(02-02-2014 06:45 PM)Bit Wrote: [ -> ]
(02-02-2014 04:44 PM)walter b Wrote: [ -> ]About the different feet (of various kings and common men Wink ): Please see p. 156 (of 244) for their explanations. What's wrong or unclear there?
As I wrote above, currently I only have access to the PDF manual (version 3.1, generated on Nov 30, 2012). I cannot figure out where page 156 is supposed to be in a different version of that document. Could you please give page references based on what's available online?

You find that on p. 140 (of 211) of the manual v3.1.

d:-)

BTW, I removed cubic feet and fathoms from CONV for the 43S.
(02-02-2014 07:46 PM)walter b Wrote: [ -> ]
(02-02-2014 06:45 PM)Bit Wrote: [ -> ]
(02-02-2014 04:44 PM)walter b Wrote: [ -> ]About the different feet (of various kings and common men Wink ): Please see p. 156 (of 244) for their explanations. What's wrong or unclear there?
As I wrote above, currently I only have access to the PDF manual (version 3.1, generated on Nov 30, 2012). I cannot figure out where page 156 is supposed to be in a different version of that document. Could you please give page references based on what's available online?

You find that on p. 140 (of 211) of the manual v3.1.

One thing is obviously wrong: The calculation given in the documentation for fathom is *1.8288 (which is the multiplier for the international fathom), whereas the WP 34S uses 1.828804 (which is the U.S. survey foot based fathom).

What I consider not only unclear but misleading is the inconsistency in how the 'US' notation is employed. With gallons and fluid ounces it designates the units that are commonly used in the United States but with feet and acres it refers to the rather obscure concept of survey units. The documentation does little to avoid the misunderstanding because I bet most people never heard of U.S. survey units and would (logically) assume that it simply means U.S. units. That's why I suggested abandoning the 'US' postfix for U.S. survey units.
Bit,

If you keep the survey units on your build, I suggest changing the menu representation and order of the various survey items to put the 'srv' second, eg:

ft.srv->m

instead of 'srv.ft->m'. And change the menu order so that it appears near 'feet->m'. That way users are at least aware that there are two types of feet in play.

-Jonathan
(02-03-2014 12:47 AM)Jonathan Cameron Wrote: [ -> ]Bit,

If you keep the survey units on your build, I suggest changing the menu representation and order of the various survey items to put the 'srv' second, eg:

ft.srv->m

instead of 'srv.ft->m'. And change the menu order so that it appears near 'feet->m'. That way users are at least aware that there are two types of feet in play.

-Jonathan

That would probably make sense. A counterargument might be that anyone who doesn't already know about survey units would almost certainly not need them, but I'm just thinking out loud.

I'm not sure what you meant by changing the menu order. An item named 'ft.srv' would be relatively close to 'feet' by virtue of both starting with the same letter, but 'floz' conversions would sit between them. It'd be possible to make the conversion catalog ordered almost but not quite alphabetically (e.g. by changing compare_cat() or unpack() in compile_cats.c) but that'd either break quick navigation (when you directly jump to an entry by typing letters) or extra code would need to be added (in process_catalogue() in keys.c) which would increase firmware size. I'm not sure it'd be worth it. Is this what you had in mind?
(02-03-2014 02:48 AM)Bit Wrote: [ -> ]I'm not sure what you meant by changing the menu order. ...

I had not realized that the menu order is set up automatically. I've just started played around with building on my Ubuntu system, so I now understand that you define the conversion and the code automatically sorts its menu order.

Looks like it is not possible to spell it out (feet.srv since this leads to labels that are longer than 9 characters, which seems to be the limit.

-Jonathan
For conversions, the names are one or two characters for the metric name and up to six for the imperial. The arrow is added automatically.

Most commands are limited to six characters and don't get the free arrow. Some of these are mixed in with the conversions catalogue.


- Pauli
(02-03-2014 12:27 AM)Bit Wrote: [ -> ]One thing is obviously wrong: The calculation given in the documentation for fathom is *1.8288 (which is the multiplier for the international fathom), whereas the WP 34S uses 1.828804 (which is the U.S. survey foot based fathom).

What I consider not only unclear but misleading is the inconsistency in how the 'US' notation is employed. With gallons and fluid ounces it designates the units that are commonly used in the United States but with feet and acres it refers to the rather obscure concept of survey units. The documentation does little to avoid the misunderstanding because I bet most people never heard of U.S. survey units and would (logically) assume that it simply means U.S. units. That's why I suggested abandoning the 'US' postfix for U.S. survey units.

Thanks for the report. We'll either correct that fathom value or abandon it.

With respect to the U.S. survey foot (as it's called in English Wikipedia): People who've never heard of something shouldn't use it IMHO. Wink And assuming something being logical in the Imperial bunch of units may be far off. Within CONV, OTOH, we have gal[UK] and gal[US], floz[UK] and floz[US], but only feet[US] and acres[US]. Hmmh, there must be a difference, isn't it? Wink Anyway, since nobody else came across that naming yet, we'll probably put it on the wait list.

With respect to cubic feet, we'll discuss their fate within the team.

d:-)
(02-03-2014 03:51 AM)Jonathan Cameron Wrote: [ -> ]Looks like it is not possible to spell it out (feet.srv since this leads to labels that are longer than 9 characters, which seems to be the limit.
Even if the 2 + 6 character limit that Pauli mentioned could be overcome, it just wouldn't fit on the screen.

Alternatively, 'feet' could be changed to 'ft' to maintain consistency. That's an abbreviation everyone would likely recognize, but changing 'acres' to 'ac' in a similar manner would be somewhat confusing. At the end of the day, I don't think it really matters what U.S. survey foot based units are called as barely anyone would ever need them, what's important is that those who do not need the survey units don't end up using them by accident.
(02-03-2014 09:29 AM)walter b Wrote: [ -> ]With respect to the U.S. survey foot (as it's called in English Wikipedia)
The NIST document that's listed as one of the sources in the WP 34S code also uses the phrase 'U.S. survey foot'.

(02-03-2014 09:29 AM)walter b Wrote: [ -> ]Within CONV, OTOH, we have gal[UK] and gal[US], floz[UK] and floz[US], but only feet[US] and acres[US]. Hmmh, there must be a difference, isn't it? Wink
If you'd like this to be a puzzle, then yes, there have been enough clues left that if someone happens to take interest in this boring little detail, they'll be able to figure it out. I did. Smile
Being puzzling is not exactly a synonym for user-friendly, though...
(02-03-2014 02:50 PM)Bit Wrote: [ -> ]
(02-03-2014 09:29 AM)walter b Wrote: [ -> ]Within CONV, OTOH, we have gal[UK] and gal[US], floz[UK] and floz[US], but only feet[US] and acres[US]. Hmmh, there must be a difference, isn't it? Wink
If you'd like this to be a puzzle, then yes, there have been enough clues left that if someone happens to take interest in this boring little detail, they'll be able to figure it out. I did. Smile
Being puzzling is not exactly a synonym for user-friendly, though...

You're right. Looking at the ... display of the 30b, however, we take pride in the amount of user friendliness we have achieved within 43x6 pixels nevertheless. Sometimes, however, there's hardly a way around RTFM. YMMV.

d:-)
Pages: 1 2
Reference URL's