WP-34s Demostration



#2

It is my pleasure to announce that a proper demonstration version of the current WP-34s scientific firmware for the HP-20b & HP-30b calculators is now available.

The Source Forge page has the demo software in the files section.

Download wp34s.zip and run wp34sgui.exe after unpacking. Non-Windows users can run the demonstration using Wine or a virtual PC.


Enjoy & please give us some feedback.


- Pauli


#3

... and since our worldwide service team is awake 24/7, we can promise fast reaction times.

Enjoy!

Walter

#4

Very nice:-).

No fractions yet?

When will the production of re-programmed and re-labeled calculators start? ;-)


#5

Now that's an emulator! Good job. Much easier to use and try out.

I predict progress will increase a great deal!

Good job!

#6

Hallo Thomas,

Quote:
No fractions yet?

Please enter one of the two available fraction modes via f- or g-shifted top right key. Enjoy!
Quote:
When will the production of re-programmed and re-labeled calculators start?

As soon as we succeeded porting the code to the real thing. This will not be next week ... d;-)

#7

Quote:
Please enter one of the two available fraction modes via f- or g-shifted top right key. Enjoy!
Ah, thanks! What was the reason to not just invoke any of the modes by just entering a number with two radices?

Quote:
As soon as we succeeded porting the code to the real thing. This will not be next week ... d;-)
So there's a chance for the 28th of March 2011! :-D

#8

Thomas, read my answer to svisvanatha!

Automatic mode switching is not after everybody's taste. We're currently discussing this in more than one area. The emulator has already helped a lot in streamlining the user interface, more than the console emulator could ever provide.

Is anybody here who might want to take care of the hardware side of things? Creating a keyboard overlay end adhesive key labels in a small production run would be a tremendous help.

#9

Thomas wrote:

Quote:
What was the reason to not just invoke any of the modes by just entering a number with two radices?

We now support this :-)


- Pauli


#10

Great!

I should start looking for a cable to get the software on my 20b when it's finished :-).


#11

Quote:
Great!

I should start looking for a cable to get the software on my 20b when it's finished :-).


Thomas, I have a spare. Tim is sending them out in pairs. Are you far from the Rhein/Main area?

Don't hold your breath for the firmware. I'm off for a week, suspending development slightly.


#12

Quote:
Thomas, I have a spare. Tim is sending them out in pairs. Are you far from the Rhein/Main area?
Unfortunately yes. Being currently in Emsland, I'm far away from *everything* ;-).

Would you mind send it by mail? Of course, I'll refund p&p.

#13

Exciting! Much easier to use than the one I used a month ago from the Linux command line!

Can you give us an idea of the challenges you now face in porting to the hardware?

Many thanks!


#14

Some of the challenges:

Cyrille's SDK and the wp34s software are a very close mismatch. ;) I had a lot of fun mating the GUI emulator and Paul's sources to the version you can use now.

We plan to use Eclipse and the Yagarto gcc tool chain which is free, instead of the IAR compiler which would cost more than 1400 Euros. I've already spent more than 500 Euros for the professional edition of Visual Studio and another 80 Euros for a JTAG adapter for my 20b. I have no plans to stretch the budget further. The SDK is written for IAR. You can imagine the work ahead.

I've never written any code for an ARM core, so some getting used to has to be taken into account.

#15

Very nice!

Here is the WP-34s version for dartboard pi, without reading the manual for an optimization:

001 LBL B
002 STO 00
003 CLx
004 STO 01
005 STO 02
006 LBL 00
007 RAN#
008 x2
009 RAN#
010 x2
011 +
012 1
013 x>? Y
014 STO+ 02
015 STO+ 01
016 DSE 00
017 GTO 00
018 4
019 RCL* 02
020 RCL/ 01
021 RTN

1,000,000 XEQ B -> 3.141268

10,000,000 XEQ B -> 3.1412384 (2 min 27 s @ 1.86 GHz)

What is the expected running time for 1,000 loops on hardware?

Ceterum censeo WP-34s esse faciendum. Audis HP? :-)

Gerson.


#16

We will certainly have to optimize for code size, not for speed. The maximum useful operating frequency of the Atmel ARM chip is something around 40 MHz. So you can extrapolate. Remember, that little thingy works on two lithium cells, not a 300 Watts power supply. ;)

#17

Olá Gerson,

Quote:
 1,000,000 XEQ B  ->  3.141268

10,000,000 XEQ B -> 3.1412384 (2 min 27 s @ 1.86 GHz)


You may save keystrokes by simply pressing B instead of XEQ B.
Quote:
Ceterum censeo WP-34s esse faciendum. Audis HP? :-)

Tibi gratia!

Walter

Edited: 18 Mar 2011, 9:20 a.m.


#18

Ave Walter!

Quote:
You may save keystrokes by simply pressing B instead of XEQ B.

I should have known better. Looks like I've been using the 33s too much lately :-)

Gerson.

#19

Having trouble sleeping....

This is a slightly more optimised version:

	001 LBL B
002 STO 00
003 STO 01
004 CLx
005 STO 02
006 RAN#
007 x^2
008 RAN#
009 x^2
010 +
011 x<=1?
012 INC 02
013 DSE 00
014 BACK 08
015 4
016 RCL* 02
017 RCL/ 01
018 RTN

It highlights a few of the new features. Register increment (and decrement) without a skip; conditional tests again 1 (we've also conditional tests of X versus any register not just Y) and a fast backwards jump (which is well hidden :-)


The zip file contains the start of a software library for the device. Included are versions of the solve, integrate, summation and product builtins (which are implemented as keystroke programs). Additionally:

A generalised Fibonacci function value for any real input (integers generate the Fibonacci numbers.

The eight queens benchmark, slightly optimised.

And a prime number sieve that doesn't use any non-stack registers and leaves its results in the flags (a chance to use STATUS :-)


- Pauli

#20

Great! And it also shows that a black 30s looks much better than the existing silver one. ;-)

After all the positive feedback I hope you forgive me if I mention some problems I had with the emulator.

The first thing I tried was the normal distribution (sorely missed on most other calculators). It looks like the 34s cannot handle values in the far tails: For x < -10 the results first get less precise, then everything beyond x = -13.3 simply returns zero. There are similar issues with the inverse function: the problems start somewhere beyond 1E-30, and finally everything less than about 1E-45 returns the same result -12,41...

Then, complex logs do not work for negative numbers without imaginary part. For instance, 0 ENTER -1 CPX LN throws an error, while 1E-99 ENTER -1 CPX LN returns 0 + Pi i as expected. Bug or feature?

At the first look I thought LOGy would give wrong results as it returns the reciprocal of the correct answer. While 1024 LB works fine and returns 10 as expected, 2 ENTER 1024 LOGy returns 0.1. Then I realized: Hey! That's exactly the way I suggested some time ago! In other words, the function now evaluates LOGxY, the base-x log of Y! Great! However, the key label and the manual have to be adjusted: it's LOGxY now, and not LOGy as originally intended.

I also noticed that the clipboard copy functions do not work (copy number, copy screen). However, "paste number" works fine. Can someone confirm this?

Dieter


#21

Hallo Dieter,

Copy Screen works flawlessly here (Windows 7). Can you tell something more about it?

I'll check your other points soon.

Walter

Addendum 1: Your observation concerning LOGy is correct. Point 2 on the bug list :-)

Addendum 2: Regarding the Gaussian distribution, the 21S is my handy benchmark (it just calculates the error probability, while we integrate from minus infinity as we were taught in math): According to my quick check, the results of the 21S are well equal to those of the 34s within |z| < 12. Personally, I don't care too much about probabilities below 1E-30, but YMMV.

Addendum 3: Concerning complex logs, you're right. This looks like point 3 on the bug list, and I have to pass it to Pauli - it's too long ago I was fond in this.


Edited: 18 Mar 2011, 12:06 p.m.


#22

Hallo, Walter -

Quote:
Addendum 1: Your observation concerning LOGy is correct. Point 2 on the bug list :-)

I assume you refer to the key label and the manual that have to be corrected. :-)

Quote:
Addendum 2: Regarding the Gaussian distribution, the 21S is my handy benchmark (it just calculates the error probability, while we integrate from minus infinity as we were taught in math): According to my quick check, the results of the 21S are well equal to those of the 34s within |z| < 12. Personally, I don't care too much about probabilities below 1E-30, but YMMV.

Others do not care about angles between 89.9 and 90 degrees, or 12 to 16 places of Pi, but this certainly is no reason why incorrect results are acceptable. Look, this is a scientific calculator. In such a device, the least thing I expect are correct results over the whole working range. For daily use my 35s holds a normal distribution program that, of course, accepts p = 1E-499 and returns z = -47.8372821357. BTW within two seconds, which in some cases is faster than the emulator on a 1,8 GHz machine. ;-) Of course events with such a low probabilty virtually "do not happen at all", but that does not mean such values are meaningsless. A calculator is a "math tool", and it should give mathmatically correct answers. Not interpretations like "a very small number without practical meaning".

If the algorithm really is not able to handle values beyond |z| = 12 or p < 1E-40 it has to return an error message, and this restriction has to be documented in the manual.

But, honestly, I would expect the 34s to work like any other HP, TI, Casio, whatever calculator: simply return the correct answer. Am I asking for too much?

Dieter


#23

Hallo Dieter,

point well taken - we'll look into it. It was just an attempt ... ;-)

Walter


#24

I now would like to know a bit about the working range of the 34s. Obviously it can handle values below 10385. So it makes sense that the calculator does not accept exponents greater than this - an attempt to key in "E385" simply cancels the leading 3.

At the other end of the working range I found a strange behaviour:

  • 10-384 can not be entered as [E] [+/-] [3][8][4]. On the other hand [E] [3][8][4] [+/-] is possible.
  • The calculator can handle even lower numbers down to about 10-398, but with reduced accuracy. Try this: Fill the stack with 1/3, then enter 1E-380 and press the multiplication key several times. As the result drops below about 10-387 the number of significant digits decreases. Eventually the result is displayed as "0 -398".
Now, what is the official working range of the "real" 30b Hardware? I searched its manual and was quite suprised I couldn't find a specific value. Also, does the hardware use BCD or binary arithmetics? The calculator seems to work with 16 (BCD?) digits while 12 digits are displayed. Compared to the HPs I know of, these four guard digits are not removed, so the user can make them visible if he wants to. Reminds me of the good old days when I used a TI58/59 now and then (10-digit display, three additional hidden digits). Or does the 30b (resp. 34s) handle numbers differently?

Dieter


#25

Wikipedia knows it: http://en.wikipedia.org/wiki/Decimal64_floating-point_format

#26

Quote:
The calculator can handle even lower numbers down to about 10-398, but with reduced accuracy. Try this: Fill the stack with 1/3, then enter 1E-380 and press the multiplication key several times. As the result drops below about 10-387 the number of significant digits decreases. Eventually the result is displayed as "0 -398"

You just discovered sub-normal numbers :-)

We support full IEEE-854 decimal arithmetic. This includes infinities, sub-normals and not numbers.


- Pauli

#27

Hallo Dieter, all,

1) the complex log bug you found is fixed now,
2) LOGy works as documented from now on (hopefully ;-)

Get the most recent build at sourceforge and enjoy!

Walter


#28

I haven't tried the latest version yet, but I hope you changed the documentation resp. the bitmap files and not the log-function. Else I would have to keep the first version. ;-)

Dieter


#29

10
ENTER
100
g logY
Result: 2

Is this what you wanted?


#30

Marcus,

This may have already been discussed, but wouldn't LOGx be more natural than LOGy? Surely LOGy is a useful instruction and should save a couple of steps in a program, but only one step if it has to be used together with x<>y, which may happen more often.

Gerson.


#31

Exactly! I see I'm not the only one. ;-)

Dieter

#32

No, I'd prefer it just the other way round, i.e. LOGx of Y. IMHO that's far more useful. Think of something like log3sqrt(3*pi) - you would first calculate the square root and then the base-3 logarithm. [3] [Pi] * [SQRT] 3 [LOGxY]. Just the way you'd calculate a cube root by pressing 3 [XROOT] - I think HP knew why they did it that way. ;-) The way the log implemented on the 34s now requires an additional x<>y.

Dieter


#33

Walter and Pauli are the custodians of the keyboard and the functionality. They will certainly chine in here.


#34

This one was Walter's choice :)
I don't much mind either way -- I'm forever doing x<>y before subtract and divide as it is.


- Pauli


#35

So now you know who's to blame [;-)

How about starting a poll: As long as yx is the general exponentiation, shall LOGy x or LOGx y be the general logarithm? RPN enthousiasts of all countries, vote!

Walter


#36

We could implement both but we'd still need to favour one for the keyboard.

I did have both y^x and x^y in an early version but the latter was vetoed :-)


- Pauli


#37

The HP-35 is the only HP calculator that had x^y. According to the Museum, because it lacks 10^x. Whilst this allows the decimal logarithm to be computed using only three keystrokes, most of the times it will require an aditional x<>y for the much more common exponentiation operation.

Another reason why y^x is better than x^y is this nice keystroke sequence for the last Heegner number:

1 ENTER 2 ENTER 3 ENTER 4 y^x * +

Gerson.

#38

LOGx y, as in the first release. Example:

32 ENTER 2 LOGxy       ->  5 

On the hp 33s, I usually do

32 ENTER 2 LN x|/y LN  ->  5

where x|/y == XROOT

because XROOT is a primary function and it's close to LN.

Thanks!

Gerson.


#39

Quote:
On the hp 33s, I usually do

32 ENTER 2 LN x|/y LN  ->  5

where x|/y == XROOT


Why on earth not 32 LN 2 LN / ????
One keystroke less and the same entry order.


- Pauli


#40

I should have said 32 was already on the X stack register as the result of a previous calculation when I did that, thus ENTER was not necessary. In that case [2] [LN] [XROOT] [LN] is the shortest way to get log232, both in number of steps and finger travel accross the keyboard. Other options I see are [LN] [x<>y] [LN] [/] [1/x] and [x<>y] [LN] [x<>y] [LN] [/], but they are one step longer. Furthermore, [/] is way farther than [XROOT] :-)

Gerson.

#41

Mathematica uses:

Power[x, y] gives x to the power y.

Binomial[n, m] gives the binomial coefficient .

Log[b, z] gives the logarithm to base b.

Therefore I suggest to use: Logy x

Best regards

Thomas


#42

Quote:
Log[b, z] gives the logarithm to base b.

This sure makes sense for a system where an expression is entered essentially the same way it is written on paper, i.e. with a usual computer/typewriter keyboard. There, writing LOGab as LOG[a, b] is fine and perfectly intuitive. But I do not think this is the case on a pocket calculator, especially with RPN.

Dieter


#43

What would you expect without reading the manual?
Log[b, z] or Log[z, b] ?

I just wanted to point out that your favored choice contradicts what probably most people are used to. IMHO this has nothing to do with RPN. Once you've decided whether the base b is the first or the second argument of the logarithm function all the rest follows. And yes, this has something to do with how RPN works: arguments of a function are pushed to the stack in the order they appear from left to right.

Cheers

Thomas


#44

I still think this example makes the choice for me:

Think of something like log3sqrt(3*pi) - you would first calculate the square root and then the base-3 logarithm. [3] [Pi] * [SQRT] 3 [LOGxY].

Compute the value, then enter the log base and compute LogxY.

#45

Quote:
What would you expect without reading the manual?

In our case, the function is (will be) printed on the keyboard so no reference to the manual is required.


- Pauli

#46

Okay, you know what I'm thinking, so just for the record: LOGxY of course. Shorter, faster, more intuitive. Or in other words: simply the RPN way. ;-)

Dieter

#47

Quote:
No, I'd prefer it just the other way round, i.e. LOGx of Y. IMHO that's far more useful. Think of something like log3sqrt(3*pi)

To me, this is a compelling reason for logx instead of logy. The base is likely to be a very simple expression - usually a constant. The argument will probably be more complicated. So by doing logx you likely reduce the number of stack levels needed to evaluate the expression.

Dave


#48

I agree with this.

#49

Copy screen should work, at least it did once. I'll check it. Try to paste into a graphics application like IrfanView.

Copy number might be broken because it assumes too much about the 20b/30b firmware which was replaced by a totally different beast. Forgive me! I guess I can change that easily. It's just a matter of getting up from the couch back to my development system. ;)


#50

Okay, so "copy screen" writes an image to the clipboard. I had expected something like an ASCII-representation. :-) Works fine with both XnView and the Faststone Image Viewer (if you only know Irfanview, just give them a try).

However, the "copy number" function obviously needs an update. While we're on this topic: what about the usual shortcuts Ctrl+C, Ctrl+V? Maybe with an additional Ctrl+Shift+C for "copy screen"? At the moment Ctrl+C or V does the same as a simple "C" or "V".

Dieter


#51

Quote:
However, the "copy number" function obviously needs an update. While we're on this topic: what about the usual shortcuts Ctrl+C, Ctrl+V? Maybe with an additional Ctrl+Shift+C for "copy screen"? At the moment Ctrl+C or V does the same as a simple "C" or "V".

I have yet to understand how to program a Windows GUI. At the moment I'm totally happy with being able to adapt it to our needs. Don't wait for Ctrl-C!

I've updated copy & paste. Just give it a try!


#52

The copy and paste functions work fine now - thank you very much. Also a new "copy textline" function has been added.

Let me mention just one detail: the copied number always has a decimal point, regardless which radix mark is set on the calculator. There also are no thousands separators. In other words: while the display shows 12.345,67 the copied string is 12345.67 - that's no big deal, but... ;-)

Anyway - I really appreciate your work on this project. If it eventually comes alive to run on a physical 30s it sure will be the most remarkable effort of this communitiy. At least I do not know of anything that comes close. :-)

Dieter


#53

In order to convert the X register to something suitable for the clipboard, I use an internal function of the decimal library. This lib has no notion of the calculator flags. It neither honors any FIX or ENG display settings.

On "Copy Textline", I tried to copy the current display string in the upper area, if set, and the alpha register if not. I don't know why, but obviously the function always returns the alpha register. Maybe it will stay like this.

#54

After playing with the GUI emulator, I'm convinced.

I want one. We should start a drive where we make a list of what needs to happen to bring it to life. We need a plan laid out.


#55

The firmware will be created in the foreseeable future, it's just too much fun for stopping it early. :)

Hardware modifications are a completely different task. Any help is greatly appreciated.


#56

At the very least, some sort of sticky overlay could be done for the shift functions.

The primary key functions might require a bit more work, but I'm not above using WHITE OUT fluid if I have to and then a permanent marker.

I think Jake Schwartz is going to weigh in on this aspect at some point.

But Bravo!


#57

Quote:
But Bravo!

Accepted! :)
#58

Quote:
I think Jake Schwartz is going to weigh in on this aspect at some point.

I was considering using CD label paper and printing the keytop labels on it, cutting them out and then peeling off the backing and sticking them directly to the keys. When the time is right, I'll report on the success of the method. The preparation may be the larger job - which would be figuring out the best size for each key label for printing.

Wouldn't it be cool if at the HHC2011 conference, the user community "announced" a new scientific calculator *to HP* ?

Jake


#59

Jake,

do you really think T.W. isn't reading this? ;-)

Walter


#60

Nope.

TW

#61

Jake,

Announcing the WP34S based on customizable HP calculators should make HP glad, since we have to buy MORE of their machines to create the custom version.

Of course history of calculators and electronics has shown how products ended being used or customized beyond the manufacturer's original plan and vision.

Namir

#62

Quote:
After playing with the GUI emulator, I'm convinced.

I want one.


I second Gene!

Were is the list I can put my name on so that I receive one when it's released?? :)

No honestly, very fine work! We'd all do good not tp press release of this goody! I think it deserves every ounce of time it takes to come up with solid firmware and reworked hardware. I for sure will patiently await the release...

Regards,
Timo


#63

My guess is that there won't be any formal reworked "hardware".

the firmware would be available, you would have to flash your 30b (or 20b but why not a 30b?), and then perhaps use a kit someone might make to redo the keyboard and keys with some kind of labels.

#64

It will be a DIY project. When we are done, you'll find a flash image which you can download to a 20b or 30b. The rest is up to you. ;)


#65

Quote:
It will be a DIY project. When we are done, you'll find a flash image which you can download to a 20b or 30b. The rest is up to you. ;)

Even better so, it cuts waiting time considerably! ;)

However, I wonder what HP would do if you approached them with this "ready to use" firmware. It shouldn't take them too long to come up with a changed 30B faceplate and key labeling, or should it? Is this maybe something to talk about at the upcoming HHC2011?


#66

We have already massacred our poor HPs for the project. My 20b still has all the original key labels but I've soldered a JTAG connector and an external power supply to the board. I'll probably create a keyboard overlay next.

It's not a beauty, more of a prototype board. I can post photos when I'm done. At the moment it just runs the 20b firmware or Cyrille's number guessing game. That will certainly change.


#67

A slight problem I see is, that not everyone interested in the WP will possess a flash programmer - I certainly do not. However, I would actually consider buying one as it would give you the possibility to continously upgrade the calc once new bug fix releases of the firmware come out.

As for the labeling:
We have a shop next door doing all kind of very professional labeling on whatever you give them for merchandising purposes. I wouldn't be suprised if they could erase the existing labels using some clever laser treatment and then place new lables on the keys and the faceplate. It would maybe not be a bargain, but it would be worth the investment in my eyes (at least considering what some of us do spent on vintage calculatorts anyway...) ;)


#68

Programming is possible through a serial cable that Tim Wessman distributes for free. You just need some free software from Atmel (SAM-BA).


#69

with the appropriate cable (these were given out at HHC 2010) and a free software package and a serial port on a PC.


#70

A what port? You mean those DB-9 connectors for RS-232/422? What if I don't have a computer from the 20th century?


#71

Any low-cost USB to serial RS-232 DB9 adapter cable would do.

#72

Quote:
What if I don't have a computer from the 20th century?

Then you don't need a calculator that should have been from the 20th century :-)

- Pauli

#73

Well, given that we are Apple guys, we don't really know what those are anyway.

Was running MacPaint 2.0 a while ago. Heh.

You should consider coming to HHC 2011 in San Diego this year. You'd enjoy it and would be good to see you again!

#74

Quote:
However, I wonder what HP would do if you approached them with this "ready to use" firmware.

They weren't interested when I approached them about this.
Of course, there wasn't ready to run firmware and there still isn't.


- Pauli

#75

How do you flash a 20b? There's no pre-designed I/O. Would you have to REALLY DIY it, as in opening the case, and connecting the chip to a PC?


#76

Have a look here under "Communications". The development kit can be downloaded a little further down on that page.

There is a programming connector under the backpane of the calc. You would, however, need a flash programmer as far as I understand it...
--> Correction: See message #37 posted by Marcus


Edited: 18 Mar 2011, 4:40 p.m.

#77

Sounds great. I have an hp20b & cable ready. Two things:

Marcus; Please use the most standard methods to send this over the internet that you can find. There was a 20b > hp45 rewrite a while back but the writer only provided it through some goofball hermaphroditic sort of file compression that i & no one i know could get to work. It does no good if we can't decompress it. Again, PLEASE.

Gene; Back when they were just cheap and not extremely collectible, i printed the global labels and functions i used onto my cx blanknut. For the function names i used the stickers that came with my first 41. This would probably work better for someone who has cleaner hands at work. I found no good way for the program names so i just used some finger nail polish and the tiniest brush i could buy - applied before my morning coffee. It stuck great but is in-elegant.

#78

Quote:
The first thing I tried was the normal distribution (sorely missed on most other calculators). It looks like the 34s cannot handle values in the far tails: For x < -10 the results first get less precise, then everything beyond x = -13.3 simply returns zero. There are similar issues with the inverse function: the problems start somewhere beyond 1E-30, and finally everything less than about 1E-45 returns the same result -12,41...

Our accuracy on the probabilities distributions isn't as good as I'd like. Especially for their inverses which use the solver code.
Something to work on I guess.

- Pauli


#79

The source code is freely available via Subversion on SourceForge. So if anybody wants to chime in...

#80

Quote:
The first thing I tried was the normal distribution (sorely missed on most other calculators). It looks like the 34s cannot handle values in the far tails: For x < -10 the results first get less precise, then everything beyond x = -13.3 simply returns zero. There are similar issues with the inverse function: the problems start somewhere beyond 1E-30, and finally everything less than about 1E-45 returns the same result -12,41...

I started looking at this and the problem lies in the implementation of the regularised incomplete gamma function. The normal CDF is a special case of this function. Does anyone know of a reliable series approximation that converges over the reals?


Pauli

#81

Quote:
The first thing I tried was the normal distribution (sorely missed on most other calculators). It looks like the 34s cannot handle values in the far tails: For x < -10 the results first get less precise, then everything beyond x = -13.3 simply returns zero. There are similar issues with the inverse function: the problems start somewhere beyond 1E-30, and finally everything less than about 1E-45 returns the same result -12,41...

I've mostly fixed the first half of this. For values x >= -10, the function should be returning sixteen digit accuracy. For values x < -10, it is only getting about 10 digits -- increasing as x decreases further. The next release will include this change (probably fairly soon). For the very curious, I calculated Q using the error function ERF: Q(x) = 0.5 * (1 + ERF(x / sqrt(2))). ERF was being calculated to pretty much full precision (39 digits) but its value was very close to -1. Cancellation ensued :-( Thus the loss of accuracy and eventual zero result.


The inverse function is more problematic. The solver is having trouble with these very small values. I'm going to have to implement a specific inverse either to Q, ERF or our regularised incomplete gamma function.


- Pauli


#82

Quote:
For values x >= -10, the function should be returning sixteen digit accuracy. For values x < -10, it is only getting about 10 digits -- increasing as x decreases further.

I assume the CDF returns 16 valid digits for 0 <= |x| <= 10, and further out in the tails it drops down to 12...10...8 digits, maybe even less. Did I get you right?

If the problem is in the far tails there is an easy solution that provides exact results, works fast and requires not much effort: simply use the well-known continued fraction representation for the CDF. For |x| > 10 only 12...5 terms are needed.

Quote:
ERF was being calculated to pretty much full precision (39 digits)

That means... you have 39-digit internal precision? Great! In this case the following suggestion should work:

Quote:
The inverse function is more problematic. The solver is having trouble with these very small values.

What about this: If you really want to use the solver, simply do not solve for p but for ln p instead. This requires up to three additional digits internally: A relative error < 1E-16 means that the logarithm has to carry 16 places behind the decimal point, plus up to three for the integer part. So, if 19-digit accuracy is possible, this might be a way. Use sqrt(-2*ln p) as the initial guess and the solver should find the solution almost instantly.
Quote:
I'm going to have to implement a specific inverse either to Q, ERF or our regularised incomplete gamma function.

There are rational approximations for the normal quantile with relative errors less than 1E-16. If only values far out in the tails are problematic one can think about such an approximation for this interval only.

BTW - the last time I used it the inverse Q function accepted arguments =< 0 and >=1. This should be easy to fix. :-)

Dieter


#83

Quote:
I assume the CDF returns 16 valid digits for 0 <= |x| <= 10, and further out in the tails it drops down to 12...10...8 digits, maybe even less. Did I get you right?

Not quite. We should get 16 digits for x >= -10, at least rounded within 1 ULP. Large positive x isn't a problem, the problem came only from negative x losing too many digits due to a subtraction (1 + almost -1 means loss of digits whereas 1 + almost 1 doesn't).

I'm using a continued fraction expansion for x < -10, I should add a few more terms to get those last few digits.


Yes, we carry 39 digits internally. It is an odd number but there are reasons for its choice.


I'm not fixated on using the solver, it makes for very small code thats all and we're pressing against the flash space limit on the device. The lack of range checking in the distribution inverses isn't good & I've just committed a fix.


- Pauli


#84

Quote:
Large positive x isn't a problem, the problem came only from negative x losing too many digits due to a subtraction (1 + almost -1 means loss of digits whereas 1 + almost 1 doesn't).

I usually do it this way: ignore the sign of x, simply take abs(x) and evaluate the upper tail integral, i.e. get a result that's always less than 0.5. If this is done by means of the error function, use the complementary error function erfc() instead of erf(), which solves exactly the problem you mentioned. Finally, return this result or 1-result, depending on the sign of x.

Quote:
I'm using a continued fraction expansion for x < -10, I should add a few more terms to get those last few digits.

The larger |x| gets the less terms are needed. However, since speed is not an issue here you can simply use the number of terms required for the lowest x. For x >= 10 and 16 digits this should be something like 12 terms.
Quote:
Yes, we carry 39 digits internally. It is an odd number but there are reasons for its choice.

Great. So the solver can be used. Suggestion: let q = min(p, 1-p), find x so that ln Q(x) = ln q, and finally adjust the sign of x.

Dieter


#85

Quote:
I usually do it this way: ignore the sign of x, simply take abs(x) and evaluate the upper tail integral, i.e. get a result that's always less than 0.5. If this is done by means of the error function, use the complementary error function erfc() instead of erf(), which solves exactly the problem you mentioned. Finally, return this result or 1-result, depending on the sign of x.

I looked for a nice series for erfc() and didn't find one :-( I am sure some are out there but all too many implementations use 1-erf() which will encounter the same problem I did. I'll keep looking.

I'm actually using the regularised incomplete gamma function to implement erf() which is then used to get Q(x).


Quote:
Great. So the solver can be used. Suggestion: let q = min(p, 1-p), find x so that ln Q(x) = ln q, and finally adjust the sign of x.

I've implemented solving for the log probability. Not with the minimum you suggest but it seems to work okay, although I've not checked the accuracy properly. Not sure if it made it into the latest release or not.

The min(p, 1-p) isn't going to work for all the other distributions we support -- they are all solved the same way.


Since you've clearly got some insight here, feel free to recode or add to some of the routines. The sources are all available :-)


- Pauli

#86

This is a very cool emulator!! Excellent job Paul!!

:-)

Namir


#87

Marcus (& HP) are responsible for the emulator.

I'm responsible for pretty much all the rest of the code.


Still, we're glad you like it :)


- Pauli


#88

It's probably more HP than me. Still enough work from me but the credits go elsewhere. I'm pretty good in generalizing other's work.

#89

Well that emulator interface looks vaguely familiar. . . :-)

TW


#90

What I mainly did was separating the emulator MFC kernel from the application in a DLL with a single interface. If you are interested, look at emulator_ddl.c and wp34sgui.c in the sources available via SVN. Some streamlining made things smoother and the skin files are customized for the modified keyboard layout.

The mechanics of the emulator are well thought out. This made porting it a manageable task. Thanks HP!

Edited: 18 Mar 2011, 6:35 p.m. after one or more responses were posted


#91

Quote:
...and the skin files are customized for the modified keyboard layout.

And the (not supplied because it isn't quite working) red LED skin looks great :-)


Pauli


#92

Quote:
And the ... red LED skin looks great :-)

Especially at night :-)

Walter

#93

I would love to load this on my Mac but, for some reason, I can't seem to get it to launch from the terminal. Can you give me some insight on this?

Thanks,

Mark


#94

Try:

wine wp34sgui.exe

Failing that, there is a Mac console version but it is nowhere near as pretty.

- Pauli


#95

Quote:
Try:

wine wp34sgui.exe

WINE isn't installed by default on my Macs. Can you explain where to get it, Pauli?

#96

Wine Is Not an Emulator

Try http://winehq.org/.

#97

Alternatively, a very good commercial packaging of WINE is available from Codeweavers. That company is one of the primary contributors to the WINE project. The principle benefits of the commercial software are lots of prebuilt installers for popular Windows software, and a nice GUI for managing all the bits.


#98

I run Windows XP under Parallels on my Macs, so no need for another commercial offering in this arena. I just wanted to see, how it would look like with MacOS window decorations.


#99

I think I will do something similar. I have Windows7 launching in a VirtualBox (a very good free virtualization program) environment. I just don't like resorting to doing that when I prefer using a Mac.

Mark

Quote:
I run Windows XP under Parallels on my Macs ..

WINE is a bit lighter in its footprint than virtual machines like Parallels or Virtual Box. It's a Windows API compatibility layer so there is no need to boot a separate OS or fire up a virtual machine. On my Mac, all that extracts a penalty in performance. On the other hand, a real copy of Windows running in a VM is obviously going to do better at providing a consistent platform for Windows applications. Some programs won't run in WINE, or run with glitches.

I don't use a lot of Windows software, but if I have to, I try it under WINE first. If that fails, I'll boot Windows on Parallels.


Howard, which wine implementation for Mac are you using? I couldn't find a precompiled binary on the winhq pages.


Quote:
Howard, which wine implementation for Mac are you using? I couldn't find a precompiled binary on the winhq pages.

Hi, Marcus,

As I mention above, I use Crossover partly out of laziness, but also because Codeweavers does so much to sustain the WINE project. They contribute all of their extensive work on the WINE core back upstream.

There's a WINE available under Macports. Macports, if you aren't familiar with it, provides a ton of Unix and Linux open source software in packages called "ports." These packages provide source code that the "port" command uses to automatically build and install binary packages. It's an idea derived from FreeBSD, which MacOS uses for a lot of its "userland" environment. With Macports installed, all you have to do is issue a command like "port install wine" or something similar. It can take a while before the binary package gets built from source code. Here's a guide that claims to walk you through the process of installing WINE with Macports. The tutorial looks good to me, but I haven't tried it.

Good luck,

Howard

Edit:


I have a new Mac on which I didn't have Macports installed, so I went through installing wine as described at the above referenced site. It took quite a long time. With a new Macports installation, a ton of prerequisites needed to be built. The whole thing took over two hours to complete. The results were good, however. I ended up with a fully functional copy of wine accessible from the command line

Regards,

Howard

Edited: 24 Mar 2011, 3:54 p.m.

Thanks. I will try the wine version. However, I downloaded the Mac console version and it won't launch.

Mark

Edited: 19 Mar 2011, 1:31 p.m.


Mark, with XCode installed and the source tree which is freely available, you can compile the console version yourself.


I would if I knew what I was doing in that regard. I'm a finance/accounting/business guy - not a programmer/scientist guy. :D

Mark


I just run it in Parallels. WinXP forever!


LOL...

I have VirtualBox running Windows 7. I'll just run it that way.

Mark

Quote:
I'm a finance/accounting/business guy - not a programmer/scientist guy.

That isn't an excuse ;-)

At a guess, the console version isn't working because it needs a library of some kind. I included the one which I knew was non-standard but you might need to install XCode as well.

If you're going that far, get X11 (again from Apple) and Wine and run the GUI version. The console version is hideous and difficult to use in comparison.


- Pauli


Yeah, I guess I can try running it in Wine in X11. But, I will likely run Windows in VirtualBox and run it that way.

Thanks for your help.

Mark

Okay... I got it working in Windows 7 in virtualization. Way cool. Good job!

Regards,

Mark

For all interested, there have been some changes, updates and improvements lately which can now be found on the download site http://sourceforge.net/projects/wp34s/files/.

- It's still logY I'm afraid.

- It's still only an emulator, not a hardware port.

- Accuracy on some functions might still improve.

But have a look at the third skin! :)

Edited: 21 Mar 2011, 6:16 a.m.

Can you add in the next version of the emulator a feature to read/write programs, memory registers, and the entire machine's state?

Namir


The entire machine state should be saved into wp34s.dat on quit. This is to simulate continuous memory.

We don't have read/write programs or registers separately. Not too difficult to add but these won't/can't be present on the real hardware.


- Pauli

Why not implement complex support like in the 15C, with a parallel stack for the imaginary numbers? All commands work equally well on reals as on complex numbers, and there's no need to have 'c' counterparts for sin, cos and whatnot.


There was a reason which slips my mind. Walter might remember. It might not even be relevant anymore. I have a vague feeling that originally it might have been that we hadn't allocated enough registers for a parallel complex stack.


Truth be known, I don't much like the 15c's handling of its complex stack. I always get the number entry wrong and having Re<>Im in a shifted position isn't optimal :-( I don't like the complex vs real mode separation all that much either. I do like the comprehensive suite of operations however.


Since the 20b's display isn't up to displaying a full complex number like the 42s can (and we did consider this), we had to compromise. We went the way of the 32sii and its successors. We filled out the operations available since the 32sii is lacking in this regard.

This solution allows for a lot more flexibility: a two or four level complex stack (plus complex last x) or a four or eight level real stack (plus real last x and an extra register I). You also get complete control over the stack and it is a natural extension of traditional RPN operation.


Has anyone played with SSIZE8 (from the Mode catalogue) and complex numbers?


- Pauli


We added complex STO and RCL (and arithmetic flavours), complex stack manipulations (x<>y, Rv, R^, FILL etc) and complex conditional tests to make dealing with complex number that little bit easier.

I wouldn't mind feedback from someone (or someones) who use complex numbers often.


- Pauli


Quote:
I wouldn't mind feedback from someone (or someones) who use complex numbers often.

I would prefer the 15C paradigm. Replace the CPX key with an "i" key, with a shifted theta function to enter in polar form. (If you want to convert everything to rectangular form after entry, that's OK with me.) That should help you enter the components in the proper order. When you enter a complex number using the "i" or theta key, it automatically switches to complex mode. I would have no problem with re-allocating the 100 storage registers such that R0 is paired with R50, R1 with R51, etc. to form the complex pairs when in complex mode. In other words, I would gladly take 50 complex registers over 100 real registers in order to get the complex number functionality that I want.

I realize the above is easy for me to propose and there may be reasons it cannot be done, including you and Walter simply liking your way better. Thanks for your work on this project, you and Walter have done a great job. I look forward to loading it on a 30b regardless of how it handles complex numbers.

Best regards,

Jeff

...


Quote:
...
I realize the above is easy for me to propose and there may be reasons it cannot be done, including you and Walter simply liking your way better. Thanks for your work on this project, you and Walter have done a great job. I look forward to loading it on a 30b regardless of how it handles complex numbers.
...

I agree with this statement. It is easy to suggest alternate ways of doing things, but not easy to get as far as you have with the WP-34s. I cannot wait to try it out on the actual hardware. Once that is done, you may find that other projects will use the WP-34s as a basis for alternate firwares! (Individual users could have their own custom firmware for example).

Quote:
I realize the above is easy for me to propose and there may be reasons it cannot be done, including you and Walter simply liking your way better.

Well, it would require a lot of work to make such a change and many many things would be impacted.

Of course the sources are freely available so feel free ;-)


Quote:
Thanks for your work on this project, you and Walter have done a great job. I look forward to loading it on a 30b regardless of how it handles complex numbers.

Thanks for the voice of support (& thanks to all the others expressing similar).


- Pauli


From what I can find in the manual, the 100 data registers are fixed... no partitioning between memory and program space?


Correct, no memory partitioning. Much simpler to code that way. I hope the balance we've achieved is adequate for most.


There are more than 100 registers BTW.

* A, B, C, D are the top four levels of the eight level stack and are freely available if the four level stack is being used.

* I is the complex part of Last X and is free to use if complex operations aren't.

* J & K are used to specify parameters to statistical distributions and are free otherwise.

* Finally, X, Y, Z, T & L which aren't freely usable but are registers nonetheless.


So 112 registers in all. For most operations you can just press the corresponding letter key to get the extra register.


- Pauli

Correct. We tried to keep things as simple as possible. The number 100 has some nice side effects, please see page 10.

Walter


I asked only because I had hoped for more program steps. Can't please everyone eh?

Back in my TI-58C days, I always partitioned the unit to be 320 steps and 20 memories.

I've just gotten used to being able to change and 100 was larger than I ever kept my 41c. :-)


Quote:
I asked only because I had hoped for more program steps. Can't please everyone eh?

Exactly, we can't please everyone. I'm sure some people will want more registers and others more program space. I'm in the latter camp but we had to draw a line somewhere and 100 registers is a nice round number.

Fortunately, the source code is available and we'd likely be interested in dynamic allocation between programs and registers if somebody took the effort to code it. Four program steps would equal one register.

You are going to have more of both registers and program than the TI-58C. And our program steps are more powerful and fully merged. We've got over twenty thousand different opcodes available in program mode :-)

As usual, it comes back to how many steps do you want on a device with no IO?

- Pauli

Edited: 22 Mar 2011, 7:46 a.m. after one or more responses were posted


True true.

I did have a question about the BACK instruction.

It seemed the manual suggested that was not available in regular programs? Yes? No?


At the moment it is: CPX h-shift CPX.
Don't tell Walter :-)

- Pauli

What did you say? ;-)

The commands on pp. 56f are for the system programmer's use. No attempt has been made to give them a user-friendly face. In such an environment, you move at your own risk. That said, that's what you do everyday, don't you? Just remember there won't be any label like "hot beverage" ;-)


Quote:
No attempt has been made to give them a user-friendly face.

I think they are sane enough and mostly safe enough to be useful in some situations. I've added some sanity checks to their code to prevent some failures.


However, Walter is quite correct, use at own risk.

You will crash your calculator, your pets will expire, your country will sink, the Moon will explode, the Earth will fall into the Sun and melt and the universe will end. Apart from these, nothing untoward will be noticed.


- Pauli

Quote:
As usual, it comes back to how many steps do you want on a device with no IO?


I'll go ahead and ask a potentially stupid question. Could programs be developed on an emulator, then uploaded to the calculator as part of or otherwise with the rom?


Quote:
I'll go ahead and ask a potentially stupid question. Could programs be developed on an emulator, then uploaded to the calculator as part of or otherwise with the rom?

There are no stupid questions :-)

Yes and no. It depends on exactly what you're wishing to do.

Can you write a program on the emulator and then add it directly to the existing ROM? No. There are more than a few problems to overcome before this would be possible (reducing the firmware footprint, adding some file management commands and hooking everything together).

Can you write a program and add it to the firmware source code which then gets built into the ROM? Yes. Solve, integrate, sum and product are all examples of this -- their key stroke sources are in the xrom.c file. There are hooks to call code in ROM via user commands but they require knowledge of what is there to function and they aren't very flexible.

The big caveat is that there will be very limited ROM space left. The exact amount is not currently known & won't be until there is a hardware port. There are also a few extra functions slated for possible inclusion (see the back of the manual). Then if there is any space left over, I suspect we'll be asking for suggestions for what to put in.

More pie in the sky would be hardware modifications to include a serial port to allow save and restore or even a SD card which could not only save and restore but allow direct program execution. This kind of thing is just a dream currently. Let's get something going on the hardware first :-)


- Pauli


I see a remote possibility to update the internal RAM via the programming cable under program control. We'll need some space in the ROM to implement a simple up/down-loading protocol. The cable needed would be the same that is needed to reprogram the device.

This has not the highest priority, of course.


We'd need commands to save/restore registers, programs & everything. Maybe the HP-41 card reader would be a good model for this.

Anyway, let's wait until after we've got working hardware.....


- Pauli


Possibly Related Threads...
Thread Author Replies Views Last Post
  [WP-34S] Unfortunate key damage with update to V3 :( svisvanatha 5 140 12-10-2013, 11:37 PM
Last Post: Les Bell
  WP-34S (Emulator Program Load/Save) Barry Mead 1 69 12-09-2013, 05:29 PM
Last Post: Marcus von Cube, Germany
  DIY HP 30b WP 34s serial flash/programming cable Richard Wahl 2 117 12-04-2013, 11:14 AM
Last Post: Barry Mead
  WP 34S/43 ?'s Richard Berler 3 120 11-10-2013, 02:27 AM
Last Post: Walter B
  My FrankenCulator (wp-34s) FORTIN Pascal 4 128 11-09-2013, 06:18 PM
Last Post: FORTIN Pascal
  WP 34S Owner's Handbook Walter B 5 205 11-09-2013, 05:34 PM
Last Post: Harald
  wp 34s overlay and programming. FORTIN Pascal 6 167 11-08-2013, 01:28 PM
Last Post: Nick_S
  m.dy in display of WP-34S Harold A Climer 3 98 11-05-2013, 11:28 AM
Last Post: Andrew Nikitin
  WP 34s : An old problem coming back Miguel Toro 2 85 11-05-2013, 03:00 AM
Last Post: Marcus von Cube, Germany
  [WP 34s] Pressure Conversion Factors Timothy Roche 8 191 11-04-2013, 07:17 PM
Last Post: Dave Shaffer (Arizona)

Forum Jump: