WP 34S and 31S bugs and fixes

[emece67]

Oh, yes, indeed. In fact I have a whole virtual machine devoted solely to the wp34s, so changing compilers on it does not cause any collateral damage (and using mklink, moving from a gcc version to another one is a task of seconds, in fact I have 6 different ARM gcc compilers installed). A must, as I have found that the Atmel Studio 6.1 tool that I use at work is not compatible with the MS Visual Express 2010 used by the wp34s.

I have also read that yagarto 4.6 is THE wp34s compiler, but... just playing

p.s. the emulator also shows those funny symbols. Does the arm gcc compiler affect the emulator?

[BarryMead]

(05-06-2015 11:46 PM)emece67 Wrote:  p.s. the emulator also shows those funny symbols. Does the arm gcc compiler affect the emulator?

No it shouldn't affect the emulator. Perhaps there is some other source code change that was made recently that is affecting your display.

[Nigel (UK)]

(05-07-2015 12:31 AM)BarryMead Wrote:  

(05-06-2015 11:46 PM)emece67 Wrote:  p.s. the emulator also shows those funny symbols. Does the arm gcc compiler affect the emulator?

No it shouldn't affect the emulator. Perhaps there is some other source code change that was made recently that is affecting your display.

I can confirm that the funny symbols aren't present on my calculator running the latest complex lock software (compiled in the traditional way, of course).

Nigel (UK)

[Pascal]

Hi.

First let me thank and congratulate the whole team that has made the WP 34S and 31S possible!

Could one of the developers have a look at the Solve algorithm? If one tries to solve f.i. \(x^2-5x+6=0\) with initial estimates 0 and 1, the computed new estimates (shown with a PSE 10 just after the LBL) are weird values, and the algorithm stops with an "+Infinity error". The quadratic interpolation seems to be broken, when two consecutive estimates give function values with the same sign. I think, in the corresponding source code the 8th line of part "slv_quadratic" should read RCL XB and not RCL FXB, but I may be wrong. The developer of this algorithm surely knows where to look.

Best regards,
Pascal

[BarryMead]

(05-07-2015 07:47 AM)Pascal Wrote:  Hi.
First let me thank and congratulate the whole team that has made the WP 34S and 31S possible!

Pascal: I had a question for you. It isn't really a bug, more like a small improvement to the new complex
branch of the WP-34s svn repository. They way the complex Qt emulator is implemented the wp34s.dat memory file is incompatible with the wp34s.dat file used in the standard Qt eumlator. How does one go about changing the directory where the complex version saves its memory file. I would like it (in linux for example) to save the memory file in a separate directory something like $HOME/.config/WP-34C for instance so that running the Complex Qt emulator does not corrupt the memory file of the standard Qt emulator stored in the $HOME/.config/WP-34S directory. I scanned through the source and couldn't see anywhere in the source where these directories are defined. I think it has something to do with some magic automatic stuff in QSettings and the Makefile or something, but I couldn't figure it out.

Could you point me in the right direction?

Thanks, Barry

[Paul Dale]

(05-07-2015 07:47 AM)Pascal Wrote:  I think, in the corresponding source code the 8th line of part "slv_quadratic" should read RCL XB and not RCL FXB, but I may be wrong. The developer of this algorithm surely knows where to look.

Actually, I don't remember the solve source code all that well. It is complex and we've had a couple of goes at it.

You are correct, this is a bug and your solution is correct. It will be fixed with the next release.


Pauli

[Paul Dale]

(05-07-2015 08:08 AM)BarryMead Wrote:  Could you point me in the right direction?

storage.c: #define STATE_FILE "wp34s.dat"


- Pauli

[BarryMead]

(05-07-2015 08:17 AM)Paul Dale Wrote:  

(05-07-2015 08:08 AM)BarryMead Wrote:  Could you point me in the right direction?

storage.c: #define STATE_FILE "wp34s.dat"
- Pauli

Excellent. That pointed me in the right direction. The file storage.c works for the non Qt emulator and QtGui/QtEmulator.h has the STATE_FILE name definition for the Qt Emulator. I now have a complex Qt emulator that does not corrupt the memory files of my normal Qt emulator.

Thanks Pauli, Barry

[fhub]

(05-07-2015 08:41 AM)BarryMead Wrote:  Excellent. That pointed me in the right direction. The file storage.c works for the non Qt emulator and QtGui/QtEmulator.h has the STATE_FILE name definition for the Qt Emulator. I now have a complex Qt emulator that does not corrupt the memory files of my normal Qt emulator.

There are in fact 4 files which are not compatible between the 'standard' and the 'complex' versions of the WP34s:
wp34s.dat, wp34s-lib.dat, wp34s-backup.dat and wp34s.op (if someone want to build his own library).

I've done this myself since we have the 'complex' version by patching the first 3 filenames in the wp34sgui.exe with a hexeditor (replacing wp34s*.dat by wp34c*.dat), and also renaming all 4 files to wp34c*.*
(I've even a 3rd version with x for Bit's 'extended' version).

Of course it would be better if the 'complex' version would automatically use this wp34c instead of wp34s, i.e. changing it in the sources instead of having to modify the program with a hexeditor.

Franz

[Nigel (UK)]

(05-07-2015 11:56 AM)fhub Wrote:  Of course it would be better if the 'complex' version would automatically use this wp34c instead of wp34s, i.e. changing it in the sources instead of having to modify the program with a hexeditor.

Franz

This is easy for me to do in the complex branch - i.e., change the three filenames in storage.c and the name of wp34s.op in compile_xrom.cmd, and add the four new files to the repository. Is this likely to cause any problems?

Nigel (UK)

[fhub]

(05-07-2015 01:25 PM)Nigel (UK) Wrote:  This is easy for me to do in the complex branch - i.e., change the three filenames in storage.c and the name of wp34s.op in compile_xrom.cmd, and add the four new files to the repository. Is this likely to cause any problems?

I doubt that it would make any problems, unless these files are referenced anywhere else in the source code.

Only if people are compiling their own wp34c-lib.dat, they would have to change their command to use the wp34c.op (instead of the wp34s.op).

Franz

[fhub]

(05-07-2015 02:05 PM)fhub Wrote:  I doubt that it would make any problems, unless these files are referenced anywhere else in the source code.

Only if people are compiling their own wp34c-lib.dat, they would have to change their command to use the wp34c.op (instead of the wp34s.op).

I forgot one possible problem:
The makelib.cmd on Sourceforge uses wp34s_lib.pl to create the wp34s-lib.dat, but wp34s_lib.pl has no option for the *.op file which should be used, so it always defaults to wp34s.op.

I am using directly the assembler (a compiled version) instead of the library tool, so I can also enter a different *.op file - here's my own command to build the wp34c-lib.dat:
..\tools\wp34s_asm.exe -op ..\tools\wp34c.op -pp matrix.wp34s matrixedit.wp34s vectors.wp34s digamma.wp34s invgamma.wp34s coordinates.wp34s modified-AGM.wp34s elliptic.wp34s TVM.wp34s TRIGON.wp34s PF.wp34s -o wp34c-lib.dat -lib

Of course the path to the assembler and to the wp34c.op file have to be adjusted to the Sourceforge location.

Franz

[emece67]

(05-07-2015 12:31 AM)BarryMead Wrote:  No it shouldn't affect the emulator. Perhaps there is some other source code change that was made recently that is affecting your display.

In fact I was in error "detecting" the error in the emulator, it wasn't there (I confused the label A symbol with a funny one).

(05-07-2015 07:22 AM)Nigel (UK) Wrote:  I can confirm that the funny symbols aren't present on my calculator running the latest complex lock software (compiled in the traditional way, of course).

Testing carefully, those symbols only appear when compiling with compilers other than yagarto 4.6 (I've tested yagarto 4.7 and Atmel 4.6 through 4.9) AND in the _full versions of the resulting .bin file when I have also compiled my own library.

So, it is definitely a problem with compilers other that the one.

[pascal_meheut]

(05-07-2015 08:08 AM)BarryMead Wrote:  

(05-07-2015 07:47 AM)Pascal Wrote:  Hi.
First let me thank and congratulate the whole team that has made the WP 34S and 31S possible!

Pascal: I had a question for you. It isn't really a bug, more like a small improvement to the new complex
branch of the WP-34s svn repository. They way the complex Qt emulator is implemented the wp34s.dat memory file is incompatible with the wp34s.dat file used in the standard Qt eumlator. How does one go about changing the directory where the complex version saves its memory file. I would like it (in linux for example) to save the memory file in a separate directory something like $HOME/.config/WP-34C for instance so that running the Complex Qt emulator does not corrupt the memory file of the standard Qt emulator stored in the $HOME/.config/WP-34S directory. I scanned through the source and couldn't see anywhere in the source where these directories are defined. I think it has something to do with some magic automatic stuff in QSettings and the Makefile or something, but I couldn't figure it out.

Could you point me in the right direction?

Thanks, Barry

Sorry I did not answer but the "Pascal" you asked the question is not me.

[Nigel (UK)]

(05-07-2015 11:56 AM)fhub Wrote:  There are in fact 4 files which are not compatible between the 'standard' and the 'complex' versions of the WP34s:
wp34s.dat, wp34s-lib.dat, wp34s-backup.dat and wp34s.op (if someone want to build his own library).

I've done this myself since we have the 'complex' version by patching the first 3 filenames in the wp34sgui.exe with a hexeditor (replacing wp34s*.dat by wp34c*.dat), and also renaming all 4 files to wp34c*.*
(I've even a 3rd version with x for Bit's 'extended' version).

Of course it would be better if the 'complex' version would automatically use this wp34c instead of wp34s, i.e. changing it in the sources instead of having to modify the program with a hexeditor.

Franz

I have committed changes based upon renaming the four files you idenfity. I've changed references to these in storage.c, compile_xrom.cmd, build_cats.cmd, Makefile, makelib.cmd, wp34s_asm.pl, and as a header file for the xrom project. The windows emulator and the calculator firmware still compile for me - let me know if there are any problems with what I have done.

Pauli's update to solve.wp34s is also included.

Nigel (UK)

[fhub]

(05-09-2015 04:11 PM)Nigel (UK) Wrote:  I have committed changes based upon renaming the four files you idenfity.
...
The windows emulator and the calculator firmware still compile for me - let me know if there are any problems with what I have done.

Yep, everything seems to work fine, thanks!

Only one question: did you intentionally set the version number (VERS) to 0 (instead of 3787)?

Franz

[emece67]

I've found that test M.SQR? skips if true, whereas the documentation (v3.3) says all tests, except for KEY?, skip if false.

This way:

10.0203
M.SQR?
ERR 21

reports "Matrix mismatch", but

10.0202
M.SQR?
ERR 21

does not report anything. Although this code is "clean" and seems to work OK, the expected behavior is the inverse.

Perhaps a correction in the documentation is all that is needed here, but it is a kind of oddity that some test perform in one way and others in the other. Perhaps this "reverse working" tests can have a distinctive name (say M.nSQR? or nKEY?).

Regards.


Edited: if this is definitely a bug, changing "fin_tst(r != c);" to "fin_tst(r == c);" on line 123 of matrix.c solves it.

[emece67]

Hi all.

Apparently I've found a bug, in this case with the [cmplx]DROP command.

According to the v3.3 doc, with this stack

4
3
2
1

cDROP must return:

4
3
4
3

but it returns instead:

4
4
4
3

Happens in the 3791 version. and also in SSIZE8.

Regards.

p.s. Not any comment on my previous M.SQR? post?


Edited: changing from:

Code:

  lower();
  if (op == OP_DROPXY) {
    lower();
    set_was_complex();
  };

to

Code:

  // lower();
  if (op == OP_DROPXY) {
    lower2();
    set_was_complex();
  } else lower();

in function drop() in xeq.c seems to solve it.

[Paul Dale]

I've applied you fix for complex DROP. Definitely a bug.

I've not done anything with M.SQR? yet. I'll check with Walter what the expected behaviour is here? I tend to agree that it is wrong but it might be more useful this way.


- Pauli

[Marcio]

If you haven't already, please consider also taking at look at this strange behaviour in the solver.

Thanks.

Marcio