The Museum of HP Calculators

HP Forum Archive 20

[ Return to Index | Top of Index ]

34s bug reports
Message #1 Posted by gene wright on 11 Apr 2011, 1:44 p.m.

Suggest numbering bug reports sequentially. These were on the actual unit itself. Here are the first few:

1) Permutations and combinations seem to turn off the display when given 69 ENTER 2 as the arguments.

2) Inverse normal distribution blanks the screen too. Argument used was 0.8413.

3) Where is the = symbol in alpha? :-)

Edited: 11 Apr 2011, 4:40 p.m. after one or more responses were posted

      
Re: 34s bug reports
Message #2 Posted by Walter B on 11 Apr 2011, 3:39 p.m.,
in response to message #1 by gene wright

Gene, did you crosscheck on the emulator? Both bugs work fine on the most recent build of the emulator FWIW. I'll get my flashed 20b but don't have it yet ...

      
Re: 34s bug reports
Message #3 Posted by Paul Dale on 11 Apr 2011, 7:47 p.m.,
in response to message #1 by gene wright

Quote:
3) Where is the = symbol in alpha? :-)

In the alpha comparisons catalogue. h-shift TEST in alpha mode.

- Pauli

      
Re: 34s bug reports
Message #4 Posted by svisvanatha on 11 Apr 2011, 9:53 p.m.,
in response to message #1 by gene wright

I can confirm that Bug #1 does exist on the 34s firmware on the 30B.

Awaiting a newer binary from Marcus before listing bugs I have observed.

            
Re: 34s bug reports
Message #5 Posted by Paul Dale on 12 Apr 2011, 6:53 a.m.,
in response to message #4 by svisvanatha

Quote:
Awaiting a newer binary from Marcus before listing bugs I have observed.

If the bug is in the emulator and the real hardware, I suspect it is going to be my problem, so you might as well let me know.

Tried programming a 20b and 30b tonight without success :-( Seems Linux doesn't like the serial programming cable. Hopefully, the erase process hasn't bricked them.

On a positive note, I've freed up some more flash space. Slight speed penalty but we'll not know exactly how much for a while.

- Pauli

                  
Re: 34s bug reports
Message #6 Posted by svisvanatha on 12 Apr 2011, 8:37 a.m.,
in response to message #5 by Paul Dale

FWIW - I cannot get my serial flashing cable to work under Ubuntu. Under WinXP. it is fine.

Bugs appearing in (linux) emulator and 30B/WP34S:

4. When menu items such as h-shift TEST are active, you cannot then select another menu item directly such as h-shift MODE without hitting 'EXIT' first. This is not consistent with the manner in which the 42S treats menus. 4a. Although I did notice that if you select h-shift STAT, and then h-shift PROB, it is equivalent to entering h-shift STAT and then the up arrow

5. Set the BASE to 2 by pressing f-shift 2 (the base 2 on the CHS key). Switch back to base 10. The '2c 64' and 'd' annunciators still persist. There is no way I could find to clear those annunciators. In addition, selections of FIX, SCi, ENG do not work after setting the base back to 10. Battery pull clears this condition on the hardware, but no obvious way to clear in the emulator. 5a. h-shift CONST does not work after setting the base in this manner. Other menus appear to work after setting BASE.

6. Calculator seems to start in HP48 'std' display mode, but after swithcing to FIX 2 for instance, there is no obvious way to switch back to STD.

Bugs appearing the 30B/34S, but working on the (linux) emulator

7. set to 'RAD' mode. h-shift PI - displays value of PI in X. f-shift COS freezes calc. Cannot be turned off, or other entry possible. Battery pull clears this condition.

8. with any numbers on the stack press f-shift R<- (f and then the 2nd key from the right on the top row to convert to rectangular) - should convert to rectangular coords - but all it does is turn off calculator, and calc cannot be turned on again, without battery pull. Similar function f->P (to polar coords) works fine.

9. Dot matrix area (upper left of LCD) has persistent lightly lit vertical bands that shift around randomly after X register changes.

Edited: 12 Apr 2011, 9:03 a.m.

                        
Re: 34s bug reports response
Message #7 Posted by Walter B on 12 Apr 2011, 9:13 a.m.,
in response to message #6 by svisvanatha

Quote:
4. When menu items such as h-shift TEST are active, you cannot then select another menu item directly such as h-shift MODE without hitting 'EXIT' first. This is not consistent with the manner in which the 42S treats menus.
This is not a bug, this is a feature so far as described in the manual. I see no urgent need changing it, but maybe ...
Quote:
4a. Also I did notice that if you select h-shift STAT, and then h-shift PROB, it is equivalent to entering h-shift STAT and then the up arrow
Funny. We'll correct that. Thanks :-)
Quote:
5. Set the BASE to 2 by pressing f-shift 2 (the base 2 on the CHS key). Switch back to base 10. The '2c 64' and 'd' annunciators still persist. There is no way I could find to clear those annunciators. Battery pull clears this condition.
Base 10 is different to decimal. Base 10 is integer! If you want to set decimal, press f .d instead (f-shifted RCL). Please see the manual.
Quote:
5a. h-shift CONST does not work after setting the base in this manner. Other menus appear to work after setting BASE.
Almost all constants are real numbers. Calling them in integer mode doesn't make sense. Please see the manual.
Quote:
6. Calculator seems to start in HP48 'std' display mode, but after swithcing to FIX 2 for instance, there is no obvious way to switch back to STD.
This is called ALL mode in RPN. Press h ALL (top left key) to get it back. Please see ...

Summary: Thanks for your reports.

Walter

Edited: 12 Apr 2011, 9:32 a.m.

                              
Re: 34s bug reports response
Message #8 Posted by svisvanatha on 12 Apr 2011, 10:27 a.m.,
in response to message #7 by Walter B

Thank you Walter for your time. A combination of not paying attention and lack of sleep led me to the erroneous reports on the bases! I apologize!

I think I must be using a different version without 'ALL' as an h-shift function. Mine is Sigma- in the top left (version 1.17). I Will check into that.

I promise to be more diligent in the future ;)

                                    
Re: 34s bug reports response
Message #9 Posted by Walter B on 12 Apr 2011, 1:23 p.m.,
in response to message #8 by svisvanatha

Svisvanatha,

No problem with errors. All of us make them (sometimes). And they give us the opportunity to learn.

Quote:
I think I must be using a different version without 'ALL' as an h-shift function. Mine is Sigma- in the top left (version 1.17).
You're right. We changed that yesterday. That's the curse of open development: you're aiming at a moving target ;-) The version in the zipped package is the official one and is (relatively) stable - everything else you may find on SourceForge concerning our project may change several times a day - we don't care since it's our workshop. So use it at your own risk.

Walter

                                          
Re: 34s bug reports response
Message #10 Posted by Paul Dale on 12 Apr 2011, 6:07 p.m.,
in response to message #9 by Walter B

And to answer your question, the old way to get ALL was 'FIX .'

- Pauli

      
Re: 34s bug reports
Message #11 Posted by Marcus von Cube, Germany on 12 Apr 2011, 11:38 a.m.,
in response to message #1 by gene wright

Thanks for your testing. I've put up a new image on SourceFourge.

            
Link to current version
Message #12 Posted by Marcus von Cube, Germany on 12 Apr 2011, 1:55 p.m.,
in response to message #11 by Marcus von Cube, Germany

Gene has asked for this, but it will certainly help all of us:

http://wp34s.svn.sourceforge.net/viewvc/wp34s/trunk/realbuild/

                  
Binomial distribution
Message #13 Posted by Gene Wright on 12 Apr 2011, 4:15 p.m.,
in response to message #12 by Marcus von Cube, Germany

Another reason I think a more introductory manual would be a good thing.

The Binomial distribution requires three inputs: Number of observations, number of successes, and the probability of a success on an event.

So, 10 coin flips at 50% probability of a head on each flip...what is the probability of 5 heads?

10, 5, 0.5 are the three arguments.

The existing manual suggests on page 24 of 61 that the probability is to be in X. Back on page 10 of 61, there is the statement that registers J and K (110 and 111) may be taken for other probability distributions.

So, are the arguments keyed in the stack as 10 ENTER 5 ENTER 0.5 then shift PROB ?

Or, do you store two of the parameters in J and K and only key the 0.5 then shift PROB?

Inquiring minds want to know. :-)

                        
Re: Binomial distribution
Message #14 Posted by Paul Dale on 12 Apr 2011, 6:10 p.m.,
in response to message #13 by Gene Wright

Probability in J, total number in K. The number you're asking about in X.

So 0.5 in J, 10 in K and 5 in X.

We tried putting all three on the stack and it ended up painful to use so we put the distribution parameters in registers (originally 01 and 02 and later J and K).

- Pauli

                              
Re: Binomial distribution
Message #15 Posted by Gene Wright on 12 Apr 2011, 6:11 p.m.,
in response to message #14 by Paul Dale

Ah, thanks. That is the kind of info that has to be spelled out in the manual. :-)

                                    
Re: Binomial distribution
Message #16 Posted by Paul Dale on 12 Apr 2011, 6:17 p.m.,
in response to message #15 by Gene Wright

Quote:
Ah, thanks. That is the kind of info that has to be spelled out in the manual. :-)

Agreed. Better start writing :-)

- Pauli

                                    
Re: Binomial distribution
Message #17 Posted by Walter B on 12 Apr 2011, 7:08 p.m.,
in response to message #15 by Gene Wright

It is already. Who has eyes to read, please read! Just search for Binom and you'll find it.

                                          
Re: Binomial distribution
Message #18 Posted by Paul Dale on 12 Apr 2011, 7:15 p.m.,
in response to message #17 by Walter B

In the released manual on sourceforge, the parameters are mentioned as being in the J and K registers but the wrong way around. So the question would still have had to be asked even if the manual was fully read and understood :-(

The latest manual is available from subversion: doc/ENTER_20b_1_17.pdf There have been a number of small changes.

- Pauli

                                                
Re: Binomial distribution
Message #19 Posted by Walter B on 12 Apr 2011, 7:23 p.m.,
in response to message #18 by Paul Dale

This is due to the fact we agreed on the order of these arguments after the released manual was released. Such is life in an open environment :-)

Quote:
There have been a number of small changes.
Oh yes. But mathematically speaking, they are countable still ;-)

Walter

Edited: 12 Apr 2011, 7:25 p.m.

                                          
Re: Binomial distribution
Message #20 Posted by Gene Wright on 12 Apr 2011, 7:38 p.m.,
in response to message #17 by Walter B

Hey Walter.

I did search for "Bino" and found a couple of places, but no where did I see it say "Store this is J and this in K, and put this in X". The only place it really talks about it is on...

Page 24 of 61 says: "= BINOMDIST(x; j; k; 1) in MS Excel, with the sample size j and the gross error probability k. B1(p) returns the number of successes g for a given probability p in X."

That did not suggest to me to store 10 in J, 0.5 in K and 5 in X. The 0.5 is the probability of a success being observed, not a gross error probability. :-)

                                                
TVM function missing from manual
Message #21 Posted by Gene Wright on 12 Apr 2011, 7:49 p.m.,
in response to message #20 by Gene Wright

In the X.FCN menu. Not in the manual. :-)

                                                      
Re: TVM function missing from manual
Message #22 Posted by svisvanatha on 12 Apr 2011, 7:59 p.m.,
in response to message #21 by Gene Wright

Looks like a newer addition

http://wp34s.svn.sourceforge.net/viewvc/wp34s/doc/ENTER_20b_1_17.pdf?revision=588

                                                            
Re: TVM function missing from manual
Message #23 Posted by Paul Dale on 12 Apr 2011, 8:04 p.m.,
in response to message #22 by svisvanatha

Yes, this was a late addition. TVM is a user code program in flash that evaluates the TVM equation taking parameters from registers 80-84 and flag 80 from memory.

- Pauli

                                                
Re: Binomial distribution
Message #24 Posted by Walter B on 13 Apr 2011, 2:03 a.m.,
in response to message #20 by Gene Wright

Quote:
Page 24 of 61 says: "= BINOMDIST(x; j; k; 1) in MS Excel, with the sample size j and the gross error probability k. B1(p) returns the number of successes g for a given probability p in X."

That did not suggest to me to store 10 in J, 0.5 in K and 5 in X. The 0.5 is the probability of a success being observed, not a gross error probability. :-)


Thanks for the last point. I know why this happened ;-) and I'll correct that.

For the remainder: Please note there are Print Conventions framed at the bottom of page 3. And the memory layout is explained on page 10, explicitely telling the purpose of registers J and K. So when you read the explanation of the binomial distribution you know what j and k represent, don't you? Else please return to page 3.

That said, the manual you refer to is of 28.3. describing v1.16, the last state zipped AFAIK. As soon as v1.17 is in the zipped package, this package will include the respective manual. For the time being, please find a (changing!!) manual representing (almost!) the current state of the SW here: http://wp34s.svn.sourceforge.net/viewvc/wp34s/doc/ENTER_20b_1_17.pdf?view=log

WARNING: Also the manual is work in progress. Since it is written on the other side of the Atlantic it may require some inevitable extra thinking sometimes. Similar requirements are posed by authors from the US of A on global readers every day. Please accept it - we do it as well. Think (sometimes)!

DISCLAIMER: Please apologize I cannot frame the last paragraph.

HTH

Walter

Edit: Bug 10 seems being fixed. The manual is corrected. Continue searching ;-)

Edited: 13 Apr 2011, 2:41 a.m.

      
Re: 34s bug reports - #10
Message #25 Posted by Gene Wright on 12 Apr 2011, 6:14 p.m.,
in response to message #1 by gene wright

Binomial locks up the 34s. :-)

So 0.5 in J, 10 in K and 5 in X.

Shift Prob ENTER locks the machine. Battery removal required.

            
Re: 34s bug reports - #10
Message #26 Posted by Walter B on 12 Apr 2011, 7:12 p.m.,
in response to message #25 by Gene Wright

This setup causes a +infinity error in the emulator. May help in debugging.

                  
Re: 34s bug reports - #10
Message #27 Posted by Paul Dale on 13 Apr 2011, 2:15 a.m.,
in response to message #26 by Walter B

Actually it is an uninitialised return value. Probably from the mucking around and space saving I've done with the distributions recently.

Fix out soon.

- Pauli

      
Re: 34s bug reports #11
Message #28 Posted by svisvanatha on 12 Apr 2011, 7:40 p.m.,
in response to message #1 by gene wright

11. Trig functions do not always return correct values.

e.g. GRAD 200 COS should be -1 WP34S/30B - result is -1 Wp34S emulator - result is -1

But, GRAD -200 COS should also be -1 WP34S/30B - result is 0 Wp34S emulator - result is 0

similarly:

DEG -90 SIN should be -1 WP34S/30B - result is 1 Wp34S emulator - result is 1

I assume that negative arguments should be allowed similar to HP-35S, and HP-48SX. I did not see anything in the manual which stated that positive arguments only are allowed.

Edited: 12 Apr 2011, 7:41 p.m.

            
Re: 34s bug reports #11
Message #29 Posted by Paul Dale on 12 Apr 2011, 8:02 p.m.,
in response to message #28 by svisvanatha

Nice find.

The code that returns exact answers for multiples of 90 degrees/100 gradians isn't handling negatives properly. A fix in in the pipeline.

The underlying trig routines are working properly. Witness SIN(-PI/2). I don't even remember why I put this special case in :-(

- Pauli

                  
Re: 34s bug reports #11
Message #30 Posted by svisvanatha on 12 Apr 2011, 8:08 p.m.,
in response to message #29 by Paul Dale

Well, since you point out this specific example ;) :

RAD PI 2 / CHS SIN should be -1

WP34S/30B - result is: calculator blanks out, and returns -6.36619772368E-1!

Wp34S emulator - result is -1

                        
Re: 34s bug reports #11
Message #31 Posted by svisvanatha on 12 Apr 2011, 8:12 p.m.,
in response to message #30 by svisvanatha

See also Bug #7 above for similar with Cos of PI in RAD mode - that makes the calculator freeze!

What factors would contribute to two different outcomes for hardware vs emulator? Memory on hardware not being addressed correctly? I am nowhere near a hardware guy...

Edited: 12 Apr 2011, 8:14 p.m.

                              
Re: 34s bug reports #11
Message #32 Posted by Paul Dale on 12 Apr 2011, 8:25 p.m.,
in response to message #31 by svisvanatha

We're probably trashing memory/running out of our 4kb stack :-(

Trig operations in radians require a reduction modulo 2 PI and this has to be done in very high precision to avoid loss of accuracy. For degrees and gradians I do the modulo reduction before converting to radians so this step is fast and accurate.

I'm still without working hardware so have to test everything in the emulator :-(

- Pauli

                                    
Re: 34s bug reports #11
Message #33 Posted by svisvanatha on 12 Apr 2011, 8:29 p.m.,
in response to message #32 by Paul Dale

Thanks - at least you know where the issue is.

Do you/Walter/Marcus think a better bug tracker is required now that the *.bin is being made publicly available? There is one on sourceforge I believe as part of the project page. It would require users to sign up there though. I am happy to keep reporting in this forum if you all wish!

                                          
Re: 34s bug reports #11
Message #34 Posted by Paul Dale on 12 Apr 2011, 8:33 p.m.,
in response to message #33 by svisvanatha

I've thought about this a bit but haven't talked to the others yet. Proper tracking will be essential but at the moment it is probably too heavy weight ... this is well pre-alpha stage software.

- Pauli

                                    
Re: 34s bug reports #11
Message #35 Posted by svisvanatha on 12 Apr 2011, 9:39 p.m.,
in response to message #32 by Paul Dale

 Bug 7 and the specific example you gave *appear* to have been fixed with newer BIN image dated Rev 569 that Marcus uploaded to SF.

With that image, and the latest Windows emulator, try:

RAD PI SIN, which should be 0 WP34S/30B - result is 2.38462643383E-16 Wp34S emulator - result is 2.38462643383E-16

Now, SIN-1 of that result returns the argument exactly.

RAD PI COS returns -1 for both emulator and 34S/30B

But the SIN behaviour is similar to the 48SX...

Edited: 12 Apr 2011, 9:45 p.m.

                                          
Re: 34s bug reports #11
Message #36 Posted by Paul Dale on 12 Apr 2011, 11:02 p.m.,
in response to message #35 by svisvanatha

In this case the 34s is correct. This is not a bug.

PI isn't exactly pi, rather it is pi rounded to 16 significant digits. Thus SIN(PI) has to return the best result for its argument.

From wolfram alpha:

SIN(3.141592653589793) = 2.384626433832795028841971693993728458138352436257608...  10^-16

We match exactly with the precision available.

The reason cosine is returning minus one is again due to accuracy. Again from alpha:

COS(3.141592653589793) = -0.999999999999999999999999999999971567783855329432161056631...

Round this to sixteen significant digits and you get -1.

- Pauli

Edited: 13 Apr 2011, 2:16 a.m.

      
Re: 34s bug reports
Message #37 Posted by svisvanatha on 13 Apr 2011, 6:22 a.m.,
in response to message #1 by gene wright

Regarding Bug #1 - Py,x and Cy,x:

Gene: This appears to have been fixed with newer BIN image dated Rev 569 that Marcus uploaded to SF.

However, the WP34S/30B is *quite* slow at returning the result compared to even the HP-35S. I would say the result is returned some 4 seconds after executing P(69,2). In that time, the LCD contains the the following: dot matrix part - the shift key pressed; numeric part - X

The wait is so long, that if this is indeed expected, there should be a wait annunciator displayed to indicate the calculator is thinking. I know that program execution causes the RCL annunciator to flash.

The speed of the Windows emulator is fine.

Edited: 13 Apr 2011, 6:24 a.m.

            
Re: 34s bug reports
Message #38 Posted by Paul Dale on 13 Apr 2011, 6:38 a.m.,
in response to message #37 by svisvanatha

That is very very slow. Cy,x does three log gamma evaluations and some extra work but it doesn't do that much extra. There is a trig evaluation once the reflection comes into play (which it shouldn't) but otherwise it is a basic fixed length series evaluation.

I wonder if the clock rate fails to kick up sometimes or somesuch.

- Pauli

                  
Re: 34s bug reports
Message #39 Posted by Marcus von Cube, Germany on 13 Apr 2011, 3:06 p.m.,
in response to message #38 by Paul Dale

I've played around with the factorial which is implemented with LNGAMMA as well. It's slow. So I tried next with LN alone. It takes a noticable time to compute, more then the trig functions. I assume "hier ist der Hund begraben" as we say in Germany.

            
Re: 34s bug reports - speed
Message #40 Posted by gene wright on 13 Apr 2011, 12:05 p.m.,
in response to message #37 by svisvanatha

Running the addition benchmark under various circumstances.

1) In "10" mode, which is base 10 integer, I think.

LBL A INC X GTO A

with a starting 0 in X, results in a value of about 73000 in a minute.

2) Same "10" mode, but this code:

LBL A + GTO A

with the stack loaded with 1, 1, 1, 0, results in a value of about 71,800.

3) In DECM mode, the code:

LBL A + GTO A

results in a value of about 78,700.

So, this is SLOWER than I got the other day, when I got a value of about 135,000. Thoughts?

                  
Re: 34s bug reports - speed
Message #41 Posted by Paul Dale on 13 Apr 2011, 6:19 p.m.,
in response to message #40 by gene wright

Quote:
So, this is SLOWER than I got the other day, when I got a value of about 135,000. Thoughts?

Space saving measures. If we end up not needing them, they will be reverted. That is a lot slower so I might revert them regardless.

- Pauli

      
Re: 34s bug reports - #12
Message #42 Posted by gene wright on 13 Apr 2011, 12:07 p.m.,
in response to message #1 by gene wright

Had the 34s in "10" mode to do some base 10 integer calculations.

Then tried to find the DECM command, which was difficult. It appears that the 1.17 manual suggests Yellow H.d on page 28 of 68.

So, I had a value of about 70,000 in X and pressed yellow H.d.

Display shows "infinity".

That seems like a bug.

Also, is there another place the DECM command lives?

            
Re: 34s bug reports - #12
Message #43 Posted by Marcus von Cube, Germany on 13 Apr 2011, 1:44 p.m.,
in response to message #42 by gene wright

Switching between integer and float is implemented similar to the 16C. It does some computations which I have never understood.

                  
Re: 34s bug reports - #12
Message #44 Posted by Walter B on 13 Apr 2011, 2:23 p.m.,
in response to message #43 by Marcus von Cube, Germany

I concur :-) IIRC, it performs the transition from integer to decimal and vice versa exactly like the 16C, FWIW.

Gene, you are right with respect to DECM. There's a table showing the mode transitions on page 17 of the manual v1.17.

Walter

            
Re: 34s bug reports - #12
Message #45 Posted by Paul Dale on 14 Apr 2011, 2:30 a.m.,
in response to message #42 by gene wright

As Walter said, it isn't a bug just not entirely obvious.

We do as the 16c does.

We had a discussion about what else could be done but nothing substantial came of it.

Pauli

      
Re: 34s bug reports #13 - Exit in Catalogs within Program Mode
Message #46 Posted by svisvanatha on 13 Apr 2011, 9:29 p.m.,
in response to message #1 by gene wright

Scenario: You are within program mode, and want to browse a catalog for a function to use. You enter a catalog, and realize that 1) it is not the correct one (note 1), or 2) the function is accessible from the keyboard. So you EXIT the catalog to return to the program step you are in.

Try this on the WP34S (emulator or WP34S/30B)

1. Enter program mode
2. f-Shift MODE
3. EXIT

This returns you to the stack instead of the program step that you were on.

Coming from a user of 42S, and 35S, this seems odd. Is this designed behaviour or an oversight?

From the manual pg 52 of v1.17: "...while EXIT leaves the catalog without executing anything, returning to the mode as set before." From this, I assume that my expectation of returning to program mode is correct.

(note 1): Bug #4 I filed previously was shown to be designed behaviour, but having used the WP34S over the past few days, I find it odd. You can switch Shift modes by simply cycling F-G-H, but not for catalogs? I realize enhancements are probably not high on the list at this point, and will leave it at that!

Thanks!

Edited - changed wording

Edited: 13 Apr 2011, 9:40 p.m.

            
Re: 34s bug reports #13 - Exit in Catalogs within Program Mode
Message #47 Posted by Paul Dale on 13 Apr 2011, 9:51 p.m.,
in response to message #46 by svisvanatha

Quote:
Is this designed behaviour or an oversight?

This is as designed. Someone wanted ON to exit program mode and this is a follow on to that. Will be looked into in due course.

Quote:
You can switch Shift modes by simply cycling F-G-H, but not for catalogs?

The problem here is the catalogue entry keystrokes are often also associated with characters that are used for navigation. You can't have both.

- Pauli

                  
Re: 34s bug reports #13 - Exit in Catalogs within Program Mode
Message #48 Posted by svisvanatha on 13 Apr 2011, 10:45 p.m.,
in response to message #47 by Paul Dale

Quote:
This is as designed. Someone wanted ON to exit program mode and this is a follow on to that. Will be looked into in due course.

Thanks.

Quote:
The problem here is the catalogue entry keystrokes are often also associated with characters that are used for navigation. You can't have both.
Forgive my naivety - how does being able to switch between different catalogs (without first pressing EXIT) interfere with other calculator functions? e.g. h-SHIFT MODE followed by h-SHIFT CONV. I am simply trying to understand your viewpoint.
                        
Re: 34s bug reports #13 - Exit in Catalogs within Program Mode
Message #49 Posted by Paul Dale on 13 Apr 2011, 11:40 p.m.,
in response to message #48 by svisvanatha

Quote:
Forgive my naivety - how does being able to switch between different catalogs (without first pressing EXIT) interfere with other calculator functions? e.g. h-SHIFT MODE followed by h-SHIFT CONV. I am simply trying to understand your viewpoint.

There are some alpha characters defined on the h-shift plane. These characters can be used to quickly navigate catalogues just like any alpha input can when a catalogue is showing.

Thus, they cannot be used to switch between catalgoues. Sure, not all keys have h-shift alpha definitions and these could switch catalogues I guess but then we'd have an inconsistency in that some catalogues could be accessed and others couldn't.

- Pauli

                              
Re: 34s bug reports #13 - Exit in Catalogs within Program Mode
Message #50 Posted by Marcus von Cube, Germany on 14 Apr 2011, 2:18 a.m.,
in response to message #49 by Paul Dale

Since the shifted alpha characters are not labeled on the keyboard, we could simply ignore the shift keys in navigation mode except for the keys with green catalog labels and treat them separately. Or we could leave the temporary alpha mode with each shift key and simply execute the selected function, be it a catalog or whatever. Even more intuitive: Just exit a catalog upon any of the shift keys. I prefer the latter: easy to implement and visually consistent.

                                    
Re: 34s bug reports #13 - Exit in Catalogs within Program Mode
Message #51 Posted by Paul Dale on 14 Apr 2011, 2:29 a.m.,
in response to message #50 by Marcus von Cube, Germany

It isn't quite that simple. We need g-shifted navigation to access the Greek alphabet.

- Pauli

                                    
Re: 34s bug reports #13 - Exit in Catalogs within Program Mode
Message #52 Posted by Walter B on 14 Apr 2011, 4:49 a.m.,
in response to message #50 by Marcus von Cube, Germany

... and we need h-shift for % and f-shift e.g. for (, +, -. Such is life ;-)

Walter

                              
Re: 34s bug reports #13 - Exit in Catalogs within Program Mode
Message #53 Posted by svisvanatha on 14 Apr 2011, 7:31 a.m.,
in response to message #49 by Paul Dale

OK - thank you. I was not using the 'search' function within catalogs. I can see the merits of allowing search, especially for long catalogs.

I'll leave this one alone - it is just not natural (for me) coming from using previous implementatations of catalogs. Thanks!

                                    
Re: 34s bug reports #13 - Exit in Catalogs within Program Mode
Message #54 Posted by Paul Dale on 14 Apr 2011, 7:46 a.m.,
in response to message #53 by svisvanatha

Quote:
OK - thank you. I was not using the 'search' function within catalogs. I can see the merits of allowing search, especially for long catalogs.

Several of the catalogues are quite painful to navigate one step at a time. I highly recommend the searching as a time and keyboard saver.

Also remember you can keep typing letters to refine the search (although after a short pause or one of the navigation arrows this is reset). You'll appreciate this most if you start accessing the statistical accumulations in the STATS catalogue :-) Although there are other places where there are long sequences of commands that start with the same letter.

- Pauli

                                          
Re: 34s bug reports #13 - Exit in Catalogs within Program Mode
Message #55 Posted by Marcus von Cube, Germany on 14 Apr 2011, 7:49 a.m.,
in response to message #54 by Paul Dale

You can also hold down the arrow keys. They repeat. :-))

                  
Re: 34s bug reports #13 - Exit in Catalogs within Program Mode
Message #56 Posted by Marcus von Cube, Germany on 14 Apr 2011, 2:20 a.m.,
in response to message #47 by Paul Dale

Quote:
Someone wanted ON to exit program mode and this is a follow on to that.
EXIT should only clear the status flags which are relevant in the current mode. It must be made context sensitive.
                        
Re: 34s bug reports #13 - Exit in Catalogs within Program Mode
Message #57 Posted by svisvanatha on 14 Apr 2011, 7:31 a.m.,
in response to message #56 by Marcus von Cube, Germany

Yup - agreed.

            
Re: 34s bug reports #13 - Exit in Catalogs within Program Mode
Message #58 Posted by svisvanatha on 14 Apr 2011, 7:57 p.m.,
in response to message #46 by svisvanatha

BIN v611 from SF appears to have the EXIT key enhancement in it! Behaviour is now as follows: when browsing a catalog in Program mode, EXIT returns you to the program step you were on before entering the catalog.

Thanks!

Edited: 14 Apr 2011, 7:57 p.m.

      
Re: 34s bug reports #14 - CPX CLx appears to not work
Message #59 Posted by svisvanatha on 13 Apr 2011, 10:52 p.m.,
in response to message #1 by gene wright

From manual v1.17 pg. 27, I understand that:

CPX h-SHIFT CLx should clear both X and Y registers (Re and Im parts)

However, both emulator and WP34s/30B appear to leave stack unchanged after execution.

Edited: 13 Apr 2011, 10:53 p.m.

            
Re: 34s bug reports #14 - CPX CLx appears to not work
Message #60 Posted by Paul Dale on 13 Apr 2011, 11:44 p.m.,
in response to message #59 by svisvanatha

Quote:
From manual v1.17 pg. 27, I understand that:

CPX h-SHIFT CLx should clear both X and Y registers (Re and Im parts)

However, both emulator and WP34s/30B appear to leave stack unchanged after execution.


Nothing is done for this key sequence currently. I'm not sure complex CLx makes sense. Will see -- either the documentation changes, the code changes or both.

- Pauli

                  
Re: 34s bug reports #14 - CPX CLx appears to not work
Message #61 Posted by Marcus von Cube, Germany on 14 Apr 2011, 2:22 a.m.,
in response to message #60 by Paul Dale

CPLX CLX doesn't make much sense without dropping the stack one level and disabling stack lift so you can enter a new number.

                        
Re: 34s bug reports #14 - CPX CLx appears to not work
Message #62 Posted by Paul Dale on 14 Apr 2011, 2:37 a.m.,
in response to message #61 by Marcus von Cube, Germany

Exactly. I did write that it didn't make much sense.

- Pauli

                              
Re: 34s bug reports #14 - CPX CLx appears to not work
Message #63 Posted by Walter B on 14 Apr 2011, 4:42 a.m.,
in response to message #62 by Paul Dale

:-) So we all agree. I removed CPX CLx from the manual.

Walter

      
Re: 34s bug reports - new image
Message #64 Posted by Marcus von Cube, Germany on 14 Apr 2011, 11:37 a.m.,
in response to message #1 by gene wright

The moving target has moved again:

http://wp34s.svn.sourceforge.net/viewvc/wp34s/trunk/realbuild/

            
Re: 34s bug reports - new image
Message #65 Posted by gene wright on 14 Apr 2011, 11:40 a.m.,
in response to message #64 by Marcus von Cube, Germany

Ok, will reload the rifle and follow that moving target. ;-)

                  
Re: 34s bug reports - new image
Message #66 Posted by Marcus von Cube, Germany on 14 Apr 2011, 11:54 a.m.,
in response to message #65 by gene wright

You will lose all RAM with the update, I'm afraid.

                        
Re: 34s bug reports - new image
Message #67 Posted by gene wright on 14 Apr 2011, 1:13 p.m.,
in response to message #66 by Marcus von Cube, Germany

The Perils of Beta testing (and I call it beta...this is too full featured and behaving well to be an Alpha release).

No problem. I'm not keeping much in ram at the moment.

                              
Bug 15
Message #68 Posted by gene wright on 14 Apr 2011, 1:15 p.m.,
in response to message #67 by gene wright

Heh, no sooner posted than...

Store 0.5 in J, 10 in K. Key 5 then Green PROB ENTER.

Warm start. Erased message shown.

Was just playing around with binomial distribution. Changing J and K values results in invalid parameter, FYI.

                                    
Bug 16
Message #69 Posted by gene wright on 14 Apr 2011, 2:18 p.m.,
in response to message #68 by gene wright

69 ENTER 2 yellow C x,y to do combinations.

Shows the result and then pushes an integer over the result in the X register.

Doing another 69 ENTER 2 blue shift P x,y will show the result and then overwrites the answer with the previous integer plus one.

                                          
Re: Bug 16
Message #70 Posted by Walter B on 14 Apr 2011, 3:27 p.m.,
in response to message #69 by gene wright

Both examples work here and return the correct results. Maybe you should reset your calculator?

Walter

                                          
Re: Bug 16
Message #71 Posted by svisvanatha on 14 Apr 2011, 7:52 p.m.,
in response to message #69 by gene wright

I did a fresh flash to latest bin (611 on SF), and the Cy,x behaviour is erratic. Sometimes gives correct result, sometimes turns calculator off, and sometimes does exactly what Gene has described. Py,x appears fine. Both are faster than I reported before, but not quick.

Edited: 14 Apr 2011, 7:58 p.m.

                                    
Re: Bug 15
Message #72 Posted by Walter B on 14 Apr 2011, 3:23 p.m.,
in response to message #68 by gene wright

Your example returns reasonable results for various X here on my emulator. What exactly is the bug you are claiming?

Swapping J and K must lead to an invalid parameter error for obvious reasons.

Walter

                                          
Re: Bug 15
Message #73 Posted by gene wright on 14 Apr 2011, 3:49 p.m.,
in response to message #72 by Walter B

The warmstart referenced is the bug I am reporting for the parameters listed.

                                                
Re: Bug 15
Message #74 Posted by Walter B on 14 Apr 2011, 3:59 p.m.,
in response to message #73 by gene wright

Not observed here :-/

                                                      
Re: Bug 15
Message #75 Posted by gene wright on 14 Apr 2011, 4:21 p.m.,
in response to message #74 by Walter B

We have to get you a physical unit to run your child on. :-)

Do you have one yet or are you still on the emulator only?

                                                            
Re: Bug 15
Message #76 Posted by Marcus von Cube, Germany on 14 Apr 2011, 4:24 p.m.,
in response to message #75 by gene wright

I do have a physical one. ;) But I'm busy with other things. I hope Pauli will chime in. It's probably a memory overrun problem which does not exist in the emulator.

                                                                  
Re: Bug 15
Message #77 Posted by svisvanatha on 14 Apr 2011, 4:42 p.m.,
in response to message #76 by Marcus von Cube, Germany

Both P and C are working for me, but I have not updated since last night :)

Will update my SVN tonite with latest, reflash and report back.

                                                                  
Re: Bug 15
Message #78 Posted by Paul Dale on 14 Apr 2011, 7:05 p.m.,
in response to message #76 by Marcus von Cube, Germany

Nothing comes to mind here.

Marcus, did you do a clean rebuild? Our dependencies into the decNumber library aren't quite correct and I reverted the slow down.

- Pauli

                                                                        
Re: Bug 15
Message #79 Posted by Marcus von Cube, Germany on 15 Apr 2011, 2:50 a.m.,
in response to message #78 by Paul Dale

I think I did cleanup before I rebuild. We probably need some stack checking code.

                                                                              
Re: Bug 15
Message #80 Posted by Paul Dale on 15 Apr 2011, 2:59 a.m.,
in response to message #79 by Marcus von Cube, Germany

Stack checking is a good idea but there really is no recovery if we run out :-(

I've reduced the size of the worst of the functions (trig in radians which also appears in lots of other functions e.g. the gamma reflection formula).

- Pauli

                                                                                    
Re: Bug 15
Message #81 Posted by Marcus von Cube, Germany on 15 Apr 2011, 3:29 p.m.,
in response to message #80 by Paul Dale

It looks like we have about 1K of stack free when calculating a factorial. I did some memory corruption tests with Walter today.

                                    
Re: Bug 15
Message #82 Posted by svisvanatha on 14 Apr 2011, 8:02 p.m.,
in response to message #68 by gene wright

I just tried Gene's example, and experienced the exact behaviour he described with warmstart. (v611 of bin from SF)

                                    
Re: Bug 15
Message #83 Posted by Marcus von Cube, Germany on 15 Apr 2011, 6:16 a.m.,
in response to message #68 by gene wright

Quote:
Store 0.5 in J, 10 in K. Key 5 then Green PROB ENTER. Warm start. Erased message shown.

The bug is still present in 621. :-(

Let's see what I can find out about this.

                                          
Re: Bug 15
Message #84 Posted by Walter B on 15 Apr 2011, 3:24 p.m.,
in response to message #83 by Marcus von Cube, Germany

We got rid of that bug in build 630 :-)

Walter

                              
Re: 34s bug reports - new image
Message #85 Posted by Paul Dale on 14 Apr 2011, 7:07 p.m.,
in response to message #67 by gene wright

Quote:
The Perils of Beta testing (and I call it beta...this is too full featured and behaving well to be an Alpha release).

I don't consider this good enough for beta. We've got too much going wrong still :-)

- Pauli

                                    
Re: 34s bug reports - new image
Message #86 Posted by Jake Schwartz on 15 Apr 2011, 9:40 a.m.,
in response to message #85 by Paul Dale

Quote:
I don't consider this good enough for beta. We've got too much going wrong still :-)

Whatever you call it, it has been simply amazing and I continue to be in awe of this achievement. Now of course, when all settles down, somebody will inevitably ask "when do we get the iPhone or Android app for wp34s?" <grin>

Keep up the great work!

Jake

                                          
Re: 34s bug reports - new image
Message #87 Posted by svisvanatha on 15 Apr 2011, 12:53 p.m.,
in response to message #86 by Jake Schwartz

I agree with this sentiment. I am showing it off at the office all week, and many HP users here are excited by it.

                                          
Re: 34s bug reports - new image
Message #88 Posted by Paul Dale on 15 Apr 2011, 5:38 p.m.,
in response to message #86 by Jake Schwartz

Quote:
Now of course, when all settles down, somebody will inevitably ask "when do we get the iPhone or Android app for wp34s?"

We don't :-) Those devices don't have proper keyboards.

Of course the source is available...

- Pauli

                                          
Re: 34s bug reports - new image
Message #89 Posted by Paul Dale on 15 Apr 2011, 5:40 p.m.,
in response to message #86 by Jake Schwartz

Quote:
Whatever you call it, it has been simply amazing and I continue to be in awe of this achievement.

Thanks for the vote of confidence. I'll clarify my not beta comment.

We're still fiddling around with the functionality and so forth. e.g. AGM got added last night -- it is used in the new logarithm code.

We're still finding major bugs :-(

Beta software doesn't have the former and shouldn't have the latter.

- Pauli

            
Re: 34s bug reports - Guide to flashing for new comers?
Message #90 Posted by Henry Chan on 16 Apr 2011, 2:10 a.m.,
in response to message #64 by Marcus von Cube, Germany

want to try but the thread is getting big and board. Sorry if I were asking newbie questions, how do you prepare the cable for flashing

from tim's guide one would need the amtel software and 20b_flash_kit but i am looking for the URL?

Thirdly, all the sources were on sourceforge, but how is the .bin file under real build related to the rom in windows emulator? which was generated from which?

thanks in advance Henry 4/16

reference

Moving Image Target

Yes, any 30b / 20b could be repurposed into a 34s #68 Flashing the 20b is perfectly described in Tim's document here. No taking apart necessary. :) In fact that wouldn't even help because the flash ROM is inside the main chip and is only accessible through either special hardware or, even easier, through the built in SAM-BA boot loader software.

The creators of WP-34s :) #14

Edited: 16 Apr 2011, 2:15 a.m.

                  
Re: 34s bug reports - Guide to flashing for new comers?
Message #91 Posted by Paul Dale on 16 Apr 2011, 2:28 a.m.,
in response to message #90 by Henry Chan

Quote:
The creators of WP-34s :) #14

Not all of them. My face isn't there :-)

- Pauli

                        
Re: 34s bug reports - Guide to flashing for new comers?
Message #92 Posted by Henry Chan on 16 Apr 2011, 2:37 a.m.,
in response to message #91 by Paul Dale

Sorry about that, I should have meant some of the creators :)

                              
Re: 34s bug reports - Guide to flashing for new comers?
Message #93 Posted by Walter B on 16 Apr 2011, 5:12 a.m.,
in response to message #92 by Henry Chan

Henry, no need for excuses, we've got the qualified majority for changing the constitution ;-)

                        
Re: 34s bug reports - Guide to flashing for new comers?
Message #94 Posted by Marcus von Cube, Germany on 16 Apr 2011, 4:46 a.m.,
in response to message #91 by Paul Dale

Quote:
Not all of them. My face isn't there :-)
It's a DIY project, so add a picture yourself! :)
                              
Re: 34s bug reports - Guide to flashing for new comers?
Message #95 Posted by Paul Dale on 16 Apr 2011, 4:51 a.m.,
in response to message #94 by Marcus von Cube, Germany

Quote:
It's a DIY project, so add a picture yourself! :)

I don't want to put you and Walter to shame....

:-)

- Pauli

                                    
Re: 34s bug reports - Guide to flashing for new comers?
Message #96 Posted by Marcus von Cube, Germany on 16 Apr 2011, 4:54 a.m.,
in response to message #95 by Paul Dale

Come on!

                  
Re: 34s bug reports - Guide to flashing for new comers?
Message #97 Posted by Marcus von Cube, Germany on 16 Apr 2011, 4:54 a.m.,
in response to message #90 by Henry Chan

Quote:
Thirdly, all the sources were on sourceforge, but how is the .bin file under real build related to the rom in windows emulator? which was generated from which?

Hi Henry,

there is no such thing like a "ROM" in the windows emulator. wp34sgui.exe is directly compiled from the C sources as a Windows executable which behaves similar to a real machine but not necessarily identical. For the developers it's a test bed to make sure the functionality is there. If some function works in Windows but not on the hardware, the bug must be in the hardware drivers or some such.

In fact, the first flash image was created way after the emulator was finished. I started porting to the hardware after porting Pauli's Unix/Linux code to Windows.

Have fun with the project! It's worth it. :)

                        
Re: 34s bug reports - Guide to flashing for new comers?
Message #98 Posted by Dieter on 16 Apr 2011, 12:29 p.m.,
in response to message #97 by Marcus von Cube, Germany

Quote:
there is no such thing like a "ROM" in the windows emulator. wp34sgui.exe is directly compiled from the C sources as a Windows executable ...
Mayby this is a very dumb question, but recently I read a lot about new software versions for "real hardware" while on the other hand the last emulator version I can find is 1.16 which is more than two weeks old now. It doesn't even have an "A"-key. ;-) Am I missing something here?

Dieter

                              
Re: 34s bug reports - Guide to flashing for new comers?
Message #99 Posted by Marcus von Cube, Germany on 16 Apr 2011, 12:46 p.m.,
in response to message #98 by Dieter

Dieter, the new release 1.17, including a flash image, will be out soon. We've started a new thread (see above).


[ Return to Index | Top of Index ]

Go back to the main exhibit hall