WP 34S and 31S bugs and fixes

01172015, 04:35 PM
(This post was last modified: 01172015 05:05 PM by Bit.)
Post: #121




RE: WP 34S and 31S bugs and fixes
(01172015 10:43 AM)walter b Wrote: While DEG and GRAD may make some sense, RAD and H.MS don't. And conversions don't either. So, for sake of coherence, DEG, RAD, GRAD, H.MS, and the menu CONV should be disabled in integer mode. I've committed a change to disable DEG, RAD and GRAD in integer mode. The rest appear to be disabled already. Edit: The conversion and statistics catalogs used to be accessible with [h] held down, but my previous patch fixed that. 

01172015, 04:50 PM
Post: #122




RE: WP 34S and 31S bugs and fixes
(01082015 07:09 AM)walter b Wrote:(01082015 05:28 AM)Bit Wrote:... Walter, I've been thinking about this, and I'd like to point out a real life scenario in which it matters: It happened several times that the calculator was in fraction mode because of previous calculations and when I tried to enter a number with an exponent, I was surprised that I couldn't. I was forced to take steps that were unnecessary in my workflow as it made no difference to me at that point whether or not numbers were displayed as fractions. I had to exit fraction mode and either retype the number or multiply it by the exponent. If the calculator simply allowed EEX while in fraction mode, the user would have the freedom to switch back to decimal mode at any point during calculations (e.g. after a result is displayed), not only at the beginning. On the other hand, I cannot think of an example when forbidding EEX would help the user avoid some confusing situation that they unintentionally got themselves into. I'm not sure how the limited range of fractions is relevant here since very large numbers are already allowed: you can enter 1e11 as 100000000000. Fractions mode in the WP 34S doesn't affect how calculations are carried out or which operations are allowed, it's just a display mode: another way to look at the content of the registers. As far as I can tell, disallowing EEX is the only exception. Could you please consider the above? 

01172015, 09:53 PM
Post: #123




RE: WP 34S and 31S bugs and fixes
(01172015 04:50 PM)Bit Wrote: If the calculator simply allowed EEX while in fraction mode, the user would have the freedom to switch back to decimal mode at any point during calculations (e.g. after a result is displayed), not only at the beginning. Hmmh. Fraction mode is designed for calculating with fractions (surprise!). Very big (>1e5) as well as very small (<1e4) numbers are out of scope. Cf. e.g. p. 54 of 149 of the WP 31S manual. Now, why do you want to enter an exponent while calculating with fractions?? If you want to enter a number >1e5 I assume you know this immediately before putting it in*  so you can press [H.d] before. What's wrong with that? d:? * If you don't know that may be another problem though that can't be solved by a calc. 

01182015, 03:11 AM
Post: #124




RE: WP 34S and 31S bugs and fixes
Pauli discovered a bug caused by my "Fewer screen updates on data entry" commit that affected the console build. I've just applied a fix that disables the WasDataEntry variable only in console builds.


01182015, 03:42 AM
Post: #125




RE: WP 34S and 31S bugs and fixes
(01172015 09:53 PM)walter b Wrote: Hmmh. Fraction mode is designed for calculating with fractions (surprise!). Very big (>1e5) as well as very small (<1e4) numbers are out of scope. Cf. e.g. p. 54 of 149 of the WP 31S manual. Now, why do you want to enter an exponent while calculating with fractions?? If you want to enter a number >1e5 I assume you know this immediately before putting it in*  so you can press [H.d] before. What's wrong with that? There are two kinds of problems:
There's another small cost, although it's minor compared to the above: 3. A few extra bytes in the firmware for the check that disables [EEX]. Ultimately, not allowing [EEX] hinders some workflows and users but benefits absolutely nobody. 

01182015, 08:00 AM
Post: #126




RE: WP 34S and 31S bugs and fixes  
01182015, 02:50 PM
Post: #127




RE: WP 34S and 31S bugs and fixes
Sorry to interrupt, just to say that I have updated the emulators to incorporate the last bug fixes.
I'll update the iOS one later because I'm looking at a "user color change" possible improvement. 

01182015, 05:32 PM
(This post was last modified: 01182015 06:58 PM by Bit.)
Post: #128




RE: WP 34S and 31S bugs and fixes
(01182015 08:00 AM)walter b Wrote:(01182015 03:42 AM)Bit Wrote: It's inefficient for some workflows.(Emphasis added.) Unfortunately I didn't keep notes but the last time I ran into this, I think it was simply because some externally provided input data was given as fractions. I'd type the fractions, the calculator would automatically switch to fraction mode, and then I had to switch back to decimal mode in order to be able to enter an exponent a little later. Next time I entered a fraction, I had to switch back again. I don't remember precisely but it could've been measurements like 1/64 inch mixed with metric data that I normally convert everything into. I also specifically remember that I had run into point 2 multiple times: I had to backtrack because I forgot to press [H.d] in advance. I don't think the specific examples are important. The point I'm trying to make is in the last sentence of my previous post. I doubt anyone can come up with an example where disabling [EEX] is actually helpful. No one is going to say "I hate that I'm able to press [EEX] in fraction mode, it impedes my calculations, I wish the calculator prevented me from doing it". :) Restricting [EEX] aids nobody, but in some cases it's an inconvenience. (Edit: Fixed typo.) 

01182015, 06:13 PM
Post: #129




RE: WP 34S and 31S bugs and fixes
(01182015 05:32 PM)Bit Wrote: Restricting [EEX] aids nobody, but in some cases it's inconvenience. I'd go a step farther. If entering a fraction automatically switches to fraction mode than it would be consistent behavior if EEX switched back to decimal mode. Marcus von Cube Wehrheim, Germany http://www.mvcsys.de http://wp34s.sf.net http://mvcsys.de/doc/basiccompare.html 

01182015, 06:47 PM
(This post was last modified: 01182015 06:53 PM by Bit.)
Post: #130




RE: WP 34S and 31S bugs and fixes
(01182015 06:13 PM)Marcus von Cube Wrote:(01182015 05:32 PM)Bit Wrote: Restricting [EEX] aids nobody, but in some cases it's inconvenience. That'd be extremely easy to implement (and as far as I can see, it wouldn't contradict the existing documentation). Wouldn't it make sense if numbers with one decimal mark (e.g. 1.25) also switched back to decimal mode? (I'm just asking a question as I don't currently have a strong opinion on the topic of switching back to decimal mode. It's not something that repeatedly frustrated me like the blocked EEX key.) 

01182015, 07:08 PM
Post: #131




RE: WP 34S and 31S bugs and fixes
(01182015 06:47 PM)Bit Wrote:(01182015 06:13 PM)Marcus von Cube Wrote: I'd go a step farther. If entering a fraction automatically switches to fraction mode than it would be consistent behavior if EEX switched back to decimal mode. From my perspective, if I'm mixing fractions and decimals (e.g., when finding the volume of a sphere) I want the decimals to win. This calculation is a situation in which having entered 4..3 (or .4.3 if you prefer!) I have to change out of fraction mode before entering the radius if it is in standard form (which it often is, for stars or atoms). Others may feel differently about decimals causing a mode change but I can't see any objection to EEX triggering the change. A great idea! Nigel (UK) 

01182015, 08:40 PM
Post: #132




RE: WP 34S and 31S bugs and fixes
(01182015 06:47 PM)Bit Wrote:(01182015 06:13 PM)Marcus von Cube Wrote: I'd go a step farther. If entering a fraction automatically switches to fraction mode than it would be consistent behavior if EEX switched back to decimal mode. Not really true. Cf. p. 201 of 374 of the manual. d:/ 

01182015, 08:54 PM
Post: #133




RE: WP 34S and 31S bugs and fixes
(01182015 08:40 PM)walter b Wrote:(01182015 06:47 PM)Bit Wrote: That'd be extremely easy to implement (and as far as I can see, it wouldn't contradict the existing documentation). I suppose you mean the EEX [d & 

01182015, 08:57 PM
Post: #134




RE: WP 34S and 31S bugs and fixes
(01182015 05:32 PM)Bit Wrote: ... I think it was simply because some externally provided input data was given as fractions. I'd type the fractions, the calculator would automatically switch to fraction mode, and then I had to switch back to decimal mode in order to be able to enter an exponent a little later. Next time I entered a fraction, I had to switch back again. I don't remember precisely but it could've been measurements like 1/64 inch mixed with metric data that I normally convert everything into. OK, that's solved easily: Assume you have some calculation like 4 1/64 * 5e3 + 1 2/3. Then I'd recommend to solve it this way: 64 1/x 4 + 5 EEX 3 +/ * 1 + 2 ENTER 3 / + No need for fraction mode, no switching between modes (that's a quick and easy solution  in the long range, get rid of measures requiring such fractional values ). As I wrote before, fraction mode is designed to deal with fractions  i.e. to help students (pupils?) who have to calculate using them. That's one reason IMHO why fractions appeared on HP calculators not earlier than the HP32SII  they aren't really needed in professional life. d:) 

01182015, 09:12 PM
Post: #135




RE: WP 34S and 31S bugs and fixes
(01182015 08:57 PM)walter b Wrote: OK, that's solved easily: ...Sure, you can work around everything, you could even solve the same problems on paper. I don't see how providing an inferior workaround is relevant in this discussion. The workaround is inferior because it requires extra mental effort to keep in mind that the calculation should be performed in some other way than what's obvious. Walter, you've been explaining why you don't think allowing EEX in fraction mode is necessary. Fair enough, you don't need it. But you haven't mentioned any reason at all for why it would be a bad idea. Can you give any such reason? 

01182015, 09:30 PM
Post: #136




RE: WP 34S and 31S bugs and fixes
(01182015 09:12 PM)Bit Wrote: The workaround is inferior because it requires extra mental effort to keep in mind that the calculation should be performed in some other way than what's obvious. Look, Bit, we should agree we disagree in that matter. For me, it's no extra mental effort to solve that example the way I suggested  it's the obvious way for me. In fact, I wouldn't even think of using fraction mode for such stuff. Fraction mode is nice to have for demonstration purposes. And to check the homework of students as mentioned earlier. YMMV (and obviously does). d:) 

01182015, 09:36 PM
Post: #137




RE: WP 34S and 31S bugs and fixes
(01182015 07:08 PM)Nigel (UK) Wrote: From my perspective, if I'm mixing fractions and decimals (e.g., when finding the volume of a sphere) I want the decimals to win. This calculation is a situation in which having entered 4..3 (or .4.3 if you prefer!) I have to change out of fraction mode before entering the radius if it is in standard form (which it often is, for stars or atoms). Good grief! Didn't they teach you in school that 4/3 equals 4 divided by 3 ?!? d:/ 

01182015, 09:37 PM
Post: #138




RE: WP 34S and 31S bugs and fixes
(01182015 09:30 PM)walter b Wrote:(01182015 09:12 PM)Bit Wrote: The workaround is inferior because it requires extra mental effort to keep in mind that the calculation should be performed in some other way than what's obvious. You're certainly right that fraction mode is probably not used very often. But I'm still curious if you have an answer to my last question. Why is it a bad idea rather than something that's at worst unnecessary but harmless? 

01182015, 09:56 PM
(This post was last modified: 01192015 03:55 PM by Bit.)
Post: #139




RE: WP 34S and 31S bugs and fixes
Walter, while checking what the manual says about fraction mode, I noticed that the output of the DECOMP command on the top of page 86 of 374 in the latest printed manual (3.3) is different from what the calculator shows. In the manual it's "x/y >", but in the real device it's "x/y Gt".
I suggest we change the calculator to agree with the manual. The Y register display already uses < and > instead of Lt and Gt because space is tight. This way DECOMP would be consistent with that as well. Please comment. 

01182015, 09:58 PM
Post: #140




RE: WP 34S and 31S bugs and fixes
(01182015 09:36 PM)walter b Wrote:(01182015 07:08 PM)Nigel (UK) Wrote: From my perspective, if I'm mixing fractions and decimals (e.g., when finding the volume of a sphere) I want the decimals to win. This calculation is a situation in which having entered 4..3 (or .4.3 if you prefer!) I have to change out of fraction mode before entering the radius if it is in standard form (which it often is, for stars or atoms). Yes, they did. But given that the WP34S supports fractions and that "4/3" in the formula for the volume of a sphere is a fraction, why should I not be able to enter it as such if I want to? I understand your point  you would never think of using fraction mode for this purpose. But not every user would think that way. Why not accommodate these fractionlovers? What would be lost by doing so? Nigel (UK) 

« Next Oldest  Next Newest »

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