HP Forums
[WP-34s] Conversion proposal - Printable Version

+- HP Forums (https://archived.hpcalc.org/museumforum)
+-- Forum: HP Museum Forums (https://archived.hpcalc.org/museumforum/forum-1.html)
+--- Forum: Old HP Forum Archives (https://archived.hpcalc.org/museumforum/forum-2.html)
+--- Thread: [WP-34s] Conversion proposal (/thread-224867.html)



[WP-34s] Conversion proposal - Alexander Oestert - 06-14-2012

When watching Mythbusters the other day I found myself converting temperatures and pressures from US to SI units on the WP-34s. I frequently wanted to do this in both directions. While with °F->°C its counterpart °C->°F is only one keystroke away, for most (all?) other conversions the direct opposite requires many keystrokes to reach.

Would it be possible to implement some kind of 'Fast Path Key' that allows the user, while in [Conv] catalog, to switch between one conversion and its counterpart?


Re: [WP-34s] Conversion proposal - fhub - 06-14-2012

Quote:
Would it be possible to implement some kind of 'Fast Path Key' that allows the user, while in [Conv] catalog, to switch between one conversion and its counterpart?

Indeed not a bad idea. :-)

But both methods I could imagine might not be so easy to implement:

1) storing the list of conversions not in strict alphabetically order, but in 'pairs', i.e. each conversion could be followed by its opposite conversion. With this method you could simply switch between both conversions by the [Up] and [Dn] arrow keys.

But this would probably give problems with the usual 'direct letter access' in menus, because now the list isn't in alphabetic order anymore.

2) using any free key (there aren't many, f/g/h would work) to switch between both conversions. But this method would require that the WP34s 'knows' which conversion is the opposite one, and thus it would be necessary to store this information (the list-number of the opposite conversion) for every entry in this conversion list.

I'm sure you can imagine the problem of this method: requires additional memory.

Franz


Re: [WP-34s] Conversion proposal - Jake Schwartz - 06-14-2012

Richard Nelson proposed a solution to a similar problem several years ago for the percent function: enter the two numbers into the stack and then return two results for x% of y and y% of x. For conversions, a similar scheme could be adopted whereby a number was entered and two results could be returned - with the result of each conversion. For instance, for degrees F <-> C, you would enter a number and it would return values in X and Y, assuming the input was F and C. Just a thought.

Jake


Re: [WP-34s] Conversion proposal - fhub - 06-14-2012

This would be possible of course, but it also requires what I described in my method 2) above (storing references between the 2 conversions), and the other problem is that it returns 2 values and thus 'destroys' the stack. And maybe you don't always want the conversion really be executed (i.e. returned to X), but only _see_ the converted value (which is currently done with ON or <- keys).

Franz


Edited: 14 June 2012, 11:33 a.m.


Re: [WP-34s] Conversion proposal - Didier Lachieze - 06-14-2012

Quote:
Would it be possible to implement some kind of 'Fast Path Key' that allows the user, while in [Conv] catalog, to switch between one conversion and its counterpart?

It seems that [f] [B] (1/X) is close to what you're looking for (See "Unit Conversions (CONV)" section in the manual).


Re: [WP-34s] Conversion proposal - Katie Wasserman - 06-14-2012

Some of the Compucorp calculators did this with several functions. For example the model 324 had a button that computed degrees-->radians and radians-->degrees, you switched between the results using the "2nd Func" button after it did both conversions. They did this for more then just conversions, they had buttons for Sin/Cos, Asin/Acos, Ln/Log and e^x/10^x but not for Tan, ATan, deg->d.ms, d.ms->deg.

Personally, I found this made the calculator difficult to use.


Re: [WP-34s] Conversion proposal - Walter B - 06-14-2012

I concur :-)


Re: [WP-34s] Conversion proposal - Alexander Oestert - 06-14-2012

Again being caught not having done my homework is embarrassing! How could I even have thought that the magnificent 3 did not think that thought before I did... ;-)


Re: [WP-34s] Conversion proposal - fhub - 06-14-2012

This was also new for me, but I've never used these conversions so far.

But now that I see it's already implemented, I would prefer that this [f][B] should rather switch/jump to the inverse conversion (in the list) only than immediately execute it. And maybe a simple [f] alone would also be enough - I Know, I'm very lazy ... ;-)


Re: [WP-34s] Conversion proposal - Dieter - 06-14-2012

Quote:
I would prefer that this [f][B] should rather switch/jump to the inverse conversion (in the list) only than immediately execute it

Hmmm... there is an obvious solution here: simply use the [X<>Y] key to switch from one conversion to its inverse and back. I think this is by far the most intuitive choice. And it's even one key less. What do you think?

Dieter


Re: [WP-34s] Conversion proposal - fhub - 06-14-2012

Quote:
Hmmm... there is an obvious solution here: simply use the [X<>Y] key to switch from one conversion to its inverse and back. I think this is by far the most intuitive choice. And it's even one key less. What do you think?

Yes, that was also my first idea. Unfortunately this [x<>y] doesn't work because the letter 'J' is assigned to this key, and pressing any letter key in a catalog immediately switches to this letter in the list.

So I would indeed say that one of the prefix keys f/g/h would be the best choice (maybe even [g] because this is usually also used for some other inverse functions (e.g. sin^-1), and [g] is located directly under the CONV key.

But I doubt that this feature would have any chance because the idea is coming from me. ;-)

Franz

Edited: 14 June 2012, 5:09 p.m.


Re: [WP-34s] Conversion proposal - Paul Dale - 06-14-2012

We didn't see any real benefit in just moving to the reverse conversion. You want to execute the inverse operation so moving there is only half the effort. One or more key presses to move and one to execute vs the current two presses to execute the inverse -- no benefit and possible loss here. If we could have found a suitable top level unshifted key for the the switch operation, we'd have found one for the inverse -- we didn't.

Yes, moving position lets you see the result of the conversion before executing it -- hardly necessary if you've already thought enough about the problem to realise that that is the conversion you want -- or at least that the one you are viewing isn't the correct one. Even if you execute it, last X can save you.

Moving position also lets you navigate to other functions faster via the arrow keys. That we allow alpha jumps means this isn't worthwhile either.

So yes, we did consider this and couldn't see sufficient benefits over what is implemented.


- Pauli




Re: [WP-34s] Conversion proposal - fhub - 06-14-2012

Quote:
So yes, we did consider this and couldn't see sufficient benefits over what is implemented.

Well, no sufficient benefits for you, but maybe sufficient for some others (like me for example).

Can't you really imagine that someone would just like to see any conversion factor (and the inverse), but not needing it in a calculation (like looking at tables in a book)?

Or what about this: if I don't know the exact name of any strange US units (and there are many of them), but I know the name of the SI unit - in this case I could just jump to the known SI name, and then switch to the inverse with a single key (e.g. [g]).

But I know, my ideas are all bad ... ;-)

Franz


Re: [WP-34s] Conversion proposal - Walter B - 06-14-2012

Franz,

Quote:
But I know, my ideas are all bad ...

I wouldn't have expressed it as harshly, but if you yourself say so ... ;-)

Seriously, f-shifted B is the best keystroke we could find - as Pauli explained already. IMHO it's a better solution than anything else I've seen so far. Though it's not perfect.

Using a single prefix key alone for a function won't fit the UI. The only prefix possibly qualifying for this job might have been the f^-1 of the HP-65, some 40 years ago. I know news spreading slowly in mountainous areas, but as slowly? ;-)


Edited to correct a grammar error in a foreign language.


Edited: 15 June 2012, 5:44 a.m. after one or more responses were posted


Re: [WP-34s] Conversion proposal - fhub - 06-15-2012

Ok Pauli, my last trial: ;-)

Couldn't [f] or [g] (whatever you prefer) in the conversion mode simply switch between the current conversion and its inverse? Then you could still decide which of both you want to apply.

With this method executing the inverse would now be [f][ENTER], and this are also only 2 keystrokes like the current [f][B]. So it's definitely no disadvantage compared with the current method.

Franz

Edited: 15 June 2012, 3:28 a.m.


Re: [WP-34s] Conversion proposal - Paul Dale - 06-15-2012

We could do this I guess, however reread Walter's earlier comment:

Quote:
Using a single prefix key alone for a function won't fit the UI.

The level of consistency we've achieved in the UI has been one of the most difficult parts of the project and arguably one of the most important features of the 34S, albeit seldom mentioned. This is the reason we didn't assign the inverse conversion to one of the shift keys -- this too was suggested and discussed BTW.

The only top level key clear when navigating the conversions catalogue is the zero key. I don't see how we can justify that as a jump to the inverse conversion -- there is no sense to it.

We could use a shifted form of x<>y to jump to the inverse function. h-shift makes most sense here but it is still a bit tenuous. Then we come back to the question: "is jumping to the inverse better than executing the inverse directly?" We didn't believe so when we discussed exactly this.


- Pauli


Re: [WP-34s] Conversion proposal - fhub - 06-15-2012

Quote:
The only top level key clear when navigating the conversions catalogue is the zero key. I don't see how we can justify that as a jump to the inverse conversion -- there is no sense to it.

When I was looking for a 'clear' toplevel key for conversions I only found XEQ (because the zero key jumps directly to °C->°F, so it seems to already have a function).

Now XEQ could indeed be used for _my_ purpose (spelling it Xchange instead of eXecute ;-)).

But I'm sure you'll also find reasons against this XEQ key, so I stop my feature wish now ...

Franz


Re: [WP-34s] Conversion proposal - Walter B - 06-15-2012

Thank you


Re: [WP-34s] Conversion proposal - Paul Dale - 06-15-2012

Why the strong interest in jumping to the inverse rather than just executing it? By your own admission, you never use these functions:

Quote:
I've never used these conversions so far.

Just curious about your interest here since you admit to a complete lack of practical experience with these?


Realistically, the only people who will use the majority of these conversions are those from the remaining non-metric countries (Liberia and the USA -- Burma uses their own system of units we don't support) and countries that converted to metric in recent or at least living history.

- Pauli


Re: [WP-34s] Conversion proposal - fhub - 06-15-2012

Quote:
Why the strong interest in jumping to the inverse rather than just executing it? By your own admission, you never use these functions:

Well, just because this switching would be a nice feature for the WP34s.

And BTW, I didn't say that I never use this function - I said I've never used it so far.

And about your other problem:

Quote:
Then we come back to the question: "is jumping to the inverse better than executing the inverse directly?"

Again, I never said it would be better or it should be replaced by my method - I suggested that this should be an additional feature.

But it doesn't matter anymore, it's history.

Franz