wp34s - New Release



#78

We've made some progress regarding numeric accuracy and usability of wp34s. Find a new release here: http://sourceforge.net/projects/wp34s/files/. You want to grab wp34s.zip.

The math and statistic specialists here are kindly asked to check the probability functions again. Pauli has put some work in better algorithms.

For the rest of us: The overall usability has improved. As an example, navigating in catalog(ue)s is possible with sequences of alpha characters. Typing C L R will bring you directly to CLRREG in the X.FCN catalog(ue). A short time of inactivity resets the sequence, so typing C L, waiting 3 seconds and then typing R will take you to RESET.

You should also notice, that the key labels of the compact and LED skins are better readable then before.

Enjoy!

Edited: 24 Mar 2011, 8:25 a.m.


#79

Question: Was there a specific reason not to have an A key in addition to B C D ?

The Sigma+ function could have been the default above the key and an A key placed there instead.

As well thought out as everything is, I'm betting you guys had a reason. ;-) Just curious.


#80

Gene,

As you may have seen, the default primary functions of the other hotkeys appear elsewhere on the keyboard. So when any of the labels B, C, D is used in a program, the respective function is easily accessible still. OTOH Sigma+ has no backup location. Sigma+ shall be a primary function in any case IMHO - and in almost all vintage HP calculators it is. And it shall be located either next to '+' or at another position reached easily. Since in the WP 34S R/S took the location often held by Sigma+ in the past (IIRC we even had a poll about that here), top left or top right were two positions coming into my mind next. The top right side takes all the prefixes, so top left was left ;-) Sufficient?

Walter

Edited: 24 Mar 2011, 9:36 a.m.


#81

Yep, makes sense Walter. Had not noticed that the B, C, D functions existed somewhere else on the keyboard. And, the explanation makes sense.

#82

How do I turn on chain algebraic mode? My math isn't working right.

TW


#83

I hope you're kidding.

Or is chain mode an explicit requirement for any 20b/30b repurposing project? I couldn't find it in the license texts of the SDK.


#84

It is in a very, very, very small font. ;-)

TW

#85

Quote:
How do I turn on chain algebraic mode?

This feature is very well hidden. First you need to visit your friendly back street neurosurgeon. Ask nicely for the wire hook lobotomy. Once that is done, you'll understand ;-)


- Pauli

#86

I was not involved in the decision, I joined the team when the functionality was long decided upon. But I have an opinion, of course. :)

Firstly, I agree. Another directly addressable label seems logical. But, secondly, the default function of the key must exist somewhere else on the keyboard or in a catalogue. Burying Sigma+ too deeply is probably a bad idea because it might not be used by everybody, but if, then it should be readily available on the keyboard for rapid data entry.

Make a suggestion where to put Sigma+ when label A is in use and Pauli and Walter will decide upon this.

#87

Log base x is back!

Thank you all very much!

Gerson.


#88

Well, thank *you* all - it was a result of a poll on this forum ;-)

Walter

#89

Ah, great - it's LOGxY again. :-)

Both in this and in earlier releases I noticed some details I would like to mention.

  1. At several occasions the emulator simply disappeared from the screen and did not come back - although it was still active and its icon was visible in the task bar. Start WP34s, switch to another program (e.g. Notepad), try to switch back to WP34s - and nothings happens. The only way to resolve this: close the program and restart it. OS: Windows XP SP3.

  2. After the emulator has been switched to "hide titlebar" there is no way to move it across the screen. The user has to turn the titlebar on, move the program window and hide the titlebar again. I think the usual keyboard shortcuts like Alt+Space (Windows) should work even with the titlebar turned off.

  3. A right-click anywhere on the calculator surface works like pressing the f prefix. Is this a bug of a hidden feature?

  4. While a program is running the display shows the x-register, not something like "running", like other HPs. The only thing that hints at a running program is a tiny flashing "RCL" in the upper right corner. BTW, I would prefer something moving across the display, like... a running chicken, a swimming duck, ...you get the idea. ;-)

  5. VIEW is not working (edit: not SHOW, as originally stated). At least it's not working the way I'd expect. Try this short example:
       001 LBL B
    002 1
    003 0
    004 STO 01
    005 LBL 01
    006 VIEW 01
    007 PSE
    008 DSZ 01 ; aaah, finally DSZ is back. :-)
    009 GTO 01
    010 RTN
    Instead of the expected countdown the display shows nothing but a "10" (or simply X, if interrupted and restarted) and a flashing RCL-announciator - for the whole ten seconds the program is running.

  6. -123 mod 5 gives -3 on the 34s. My other HPs with MOD or RMDR function return 2. I assume that's also true for the 42s which the manual refers to regarding this function.

  7. The normal CDF now is more precise, but full machine precision is not achieved. Especially in the tails (x >= 2) this could be done easily with a simple continued fraction expansion. Unoptimized pseudo-code:
       n := 4 + 100 div (x-1)  ; see below
    s := 1/n
    for c := n-1 downto 1 do
    s := c / (s + x)
    s := s + x
    cdf := pdf(x) / s
    I tried to determine a rule for the number of terms n, depending on x and the desired accuracy (d digits). As far as I can tell on a system working with usual binary double precision numbers (15-16 valid decimals) this value can be estimated for d = 8...16 digits quite exactly by
       k >= 17 + d * (d-5) / 2   (the example uses k = 100 for d ~= 16)
    n >= 4 + int(k / (x-1))
    This should return the value for s with d valid digits and an error near 0,2 ULP. With 39 internal digits on the 34s the desired 16-digit result can be evaluated without effort, since the required pdf and its exp(-0,5*x^2) can be evaluated with sufficient precision. All this is calculated in virtually no time.

  8. While we're on this topic: the common use of the symbols P and Q for the cumulative normal distribution is P for the lower tail and Q for the upper. The 34s uses both symbols exactly vice versa. Thar's why I think either the symbol should be changed or the values should get the opposite sign:
       x =  1,5   =>   Q =  0,06681
    x = -1,5 => Q = 0,93319
    Q = 0,1 => x = 1,28155
    Q = 0,9 => x = -1,28155

  9. Regarding Sigma-plus: I never understood why this function should require a primary key. Even in the days when I used statistics virtually every day I never used this function on any of my calculators. I always wondered if someone really used this function at all. ;-) Using my 41C it always drove me mad when I wanted to start a program at label A, but instead Sigma+ was executed because I forgot to turn on user mode. And so one accidental key press destroyed not less than six memory registers. No, LastX Sigma- is not always an option.

    In other words: If I could design a calculator, this Sigma+ key would be the first function I'd remove from a primary key. The 34C uses f Sigma+ and g Sigma-, which is perfectly okay. In simple words: yes, I want a decicated "A"-key.

Otherwise I think an actual "hardware" 34s would be one of the greatest calculators I ever used. ;-)

Dieter


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


#90

Dieter, I can only comment on the first few items.

The emulator kernel is still mostly what comes with the SDK. I couldn't reproduce the "can't find the window again" problem you're mentioning. My development system is a WinXP virtual machine, so close enough to what you are using.

Dragging a frameless window should be no problem at all. Just grab the window anywhere and drag it around. I can't comment on standard Windows shortcuts, I just didn't dig deep enough into the emulator mechanics. I was happy enough to cope with the MFC code without being dependent on the runtime DLLs. ;)

The right click anywhere except the logo is borrowed from the original code which sends a blue shift to the application. I just adapted the behavior to the wp34s key layout.

The proper display in run mode is still under investigation. I did some changes to Pauli's routines in preparation for the hardware port which might have broken the intended functionality. Walter should add this to our internal bug list.

All the math questions go to Walter and Pauli...

Quote:
Otherwise I think an actual "hardware" 34s would be one of the greatest calculators I ever used. ;-)

Danke für die Blumen. :)


#91

If that comes from some of the original emulator UI code from a while back (which I highly suspect is the case), that non redrawing bug can be found in the cDlg file. If it is the same and I am remembering properly, it happens when you minimize and then maximize the window. It could cause a flag not to be set properly and it wouldn't redraw correctly.

Not sure if that is the case, but it could be.

TW


#92

I can't reproduce the error here. Sorry for any inconvenience.

#93

Quote:
The emulator kernel is still mostly what comes with the SDK. I couldn't reproduce the "can't find the window again" problem you're mentioning.

It happens especially every time I use notepad.exe and close it again. Afterwards the WP34s simply has disappeared.
Quote:
Dragging a frameless window should be no problem at all. Just grab the window anywhere and drag it around.

Aaaaaargghh.... I haven't even tried it - after clicking on the window I somehow expected the mouse coursor to become a hand, as usual. Since this did not happen... But okay, it works.
Quote:
Danke für die Blumen. :)

Bitte, bitte. 8-)

Dieter


#94

Quote:
It happens especially every time I use notepad.exe and close it again. Afterwards the WP34s simply has disappeared.

This used to happen here also (Vista). I was able to reproduce it by successively minimizing and maximizing the application by right-clicking the shortcut in the task bar, as Tim has suggested (I've hidden the title bar because I'm using 1280x800 resolution).

Gerson.

Edited to fix a typo


Edited: 25 Mar 2011, 6:33 a.m. after one or more responses were posted


#95

I can reproduce it now. It only happens with the Window frame hidden. If you leave the title bar on, everything works as expected.

The bug must be deeply hidden in the emulator sources. I'm not sure I'll ever find it.


#96

I think I found a fix. I commented out some strange code in the emulator sources and that seems to help. The next release will include the fix.


#97

I apologize. I should have reported earlier that with the titlebar absent, a minimized-to-the-taskbar WP34S could not be made to return for use, running under Wine (I'd assume fairly recent) under Ubuntu 10.04. It's been no big deal, as Alt+mouse_drag on the window for me allows shoving the titlebar off the top of the display anyway.


#98

The vanishing window is one of the issues fixed with the upcoming release. The EXE is ready but there are enough changes to justify a new manual with the release.


#99

The manual is ready now - we'll see to get all the stuff packed and zipped and then ... tataa! :-)

Dieter,

Great feedback thanks.

Quote:
While a program is running the display shows the x-register, not something like "running", like other HPs. The only thing that hints at a running program is a tiny flashing "RCL" in the upper right corner. BTW, I would prefer something moving across the display, like... a running chicken, a swimming duck, ...you get the idea. ;-)

We should be able to do something here.

Quote:
SHOW is not working. At least not the way I'd expect. Try this short example:

Yes, this one is known already :-( The pause is forcing a screen redraw which destroys the VIEW. If you replace the pause with a small loop it works okay but that isn't a fix.

We've always has ISZ and DSZ in order to support integer mode where ISG and DSE don't make much sense. They just happen to work on reals like the early HPs :-)

Quote:
-123 mod 5 gives -3 on the 34s. My other HPs with MOD or RMDR function return 2. I assume that's also true for the 42s which the manual refers to regarding this function.

Hmmm, bug or not? I'm not sure :-) We're honouring the sign the same as division or multiplication would.

Quote:
The normal CDF now is more precise, but full machine precision is not achieved.

Sadly, I've not got back to this one yet. It will be fixed eventually though.

Quote:
While we're on this topic: the common use of the symbols P and Q for the cumulative normal distribution is P for the lower tail and Q for the upper. The 34s uses both symbols exactly vice versa. Thar's why I think either the symbol should be changed or the values should get the opposite sign:

My vote was for Z.

Our P is a Poisson distribution not a normal one. The parameter comes from register J. We tried having the parameter(s) on the stack for the distributions but it was painful to do anything.

Again, thanks for the feedback,

- Pauli


Edited: 24 Mar 2011, 11:43 p.m. after one or more responses were posted


I'm working on the VIEW problems. The next release will be better (but probably far from perfect) in this respect. VIEW then displays the selected register and PAUSE does not destroy it. You will be able to omit the PAUSE and let the program continue without interruption. This will, of course, interfere with any flying gooses we might introduce.

Hi Pauli,

Quote:
The pause is forcing a screen redraw which destroys the VIEW. If you replace the pause with a small loop it works okay but that isn't a fix.

OK, I tried a loop instead of PSE:
5
0
0
0
0
0
LBL 02
DSZ X
GTO 02
The display now shows "10", then "18" (?!) and stays so until the program finishes after 10 seconds.
Quote:
My vote was for Z. (...) Our P is a Poisson distribution not a normal one.

The use of "Q" is perfectly okay - just change the sign of x. ;-) "Z" is not very clever here, as it refers to the pdf (cf. Abramovitz & Stegun). There's just one reason why P might be preferred: if for all other distributions the lower tail integral is determined, and using the upper tail only for the normal distribution would make it the only exception. Otherwise the solution is simple: use Q and evaluate the upper tail.

Edit - what about this: simply use an uppercase Greek Phi for the normal integral. This is a commonly used symbol. One might even provide a lowercase phi function that returns the pdf. :-)

Dieter

Edited: 24 Mar 2011, 7:12 p.m.


VIEW works now.

Walter


But has yet to be released?

I've found another problem: Solve (SLV) crashes the emulator. Try this simple test:

   LBL D
X^2
2
-
RTN

1 ENTER 2
SLV D

Instead of the expected instantaneous 1,4142... the emulator simply crashes.

Addendum:

Integrate crashes as well. Test:

   LBL D
SIN
RTN

DEG FIX 4
0 ENTER 90
Integrate D

Instead of the expected 180/Pi = 57,2958 the emulator crashes immediately.

Dieter


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


That works okay for me here using labels 'A', 'B', 'C', or 'D', with or without the final 'RTN' instruction. This with the latest build as of this date running via Wine on GNU/Linux, and as the only program in memory.

[edit: pertains only to the first part of your post]

[edit further: pertains /also/ to the second part -- "Works fine for me here"]

Perhaps a crash has left your "calculator" in a weird state. Try a reset. Though I should state that I'm using "." as the radix and didn't try it with ",", but I rather doubt that'd be the problem for you.

Edited: 26 Mar 2011, 12:54 p.m.


Dieter, I second Glen's proposal: reset the calculator or remove the wp34s.dat file. If you can reproduce the error with a certain dat file I'd be interested to debug the crash scenario here with your data.


Removing the .dat-file does not make a difference. Both Solve and Integrate crash immediately.

Dieter

I could reproduce both of these crashes, even with an erased wp34s.dat file. Latest build on Windows Vista x64.


Hmmh, I hate I have to concur. Crashed with program 1 (and 2) even after RESET, build 377. Windows 7.

Edited: 26 Mar 2011, 5:24 p.m.


OK, something to do on Sunday. :(


We found a fix. The next release will work. :)

This looks to be a problem with Windows. It works fine under Wine on a Mac (and Linux as mentioned below). Likewise the console versions seem to be okay too.

I'm assuming that sum and product are also broken the same way.

Will be looked into.


- Pauli


Right, the sum and product functions also crash.

Dieter

This morning, wp34s failed to start. I had to remove wp34s.dat (and immediately realized that this file could have been of interest :-/).

About rounding: ROUNDI rounds Integer x + 0.5 to x+1 always. Is there any way to change this behaviour?

And: Change the icon from hp to wp, please ;-).


The short answer is no. The longer answer involves the rounding modes supported by the IEEE standard.

The underlying mathematics library supports these rounding modes:

	Mode		Description			WP34S

CEILING round towards +infinity CEIL
DOWN round towards 0 (truncate) TRUNC
FLOOR round towards -infinity FLOOR
HALF_DOWN 0.5 rounds down
HALF_EVEN 0.5 rounds to nearest even
HALF_UP 0.5 rounds up ROUNDI
UP round away from 0

The WP34S also has an extra mode invoked by ROUND. This rounds to the value shown on the display using the current display mode settings.

So we support all but three of the available rounding modes. Half down is easy: CHS ROUNDI CHS. Round half even is more difficult.

It would be easy enough to add extra commands to support the other three modes if there is sufficient interest. So, if you want the extra commands please post which you want (& suggest command names -- limit of six characters).

- Pauli

oops: CHS ROUNDI CHS doesn't do half down :-(

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


AFAIK we don't feature TRUNC, it's called IP.

Quote:
So, if you want the extra commands please post which you want (& suggest command names -- limit of six characters).
I recommend HALF_EVEN, either as a dedicated function (RHEVEN), or as a MODE to ROUNDI. Anyone supporting this?

Just for curiosity: what do you need that for?


Quote:
Just for curiosity: what do you need that for?

Round half even is the recommended naive rounding mode for numerical computations. Rounding errors generally tend to cancel out better in this mode. Round half odd is also good but not typically supported. This error cancellation doesn't happen with round half up or round half down.

Of course, we're rounding to integer here (rather than rounding the last digit in the mantissa) so the whole thing is pretty moot. I don't see much reason to include this.

However, including support for the rounding modes is another matter. We use round half even for conversions to our register format.


And yes, it is IP not TRUNC :-(


- Pauli


Quote:
Round half even is the recommended naive rounding mode for numerical computations. Rounding errors generally tend to cancel out better in this mode. Round half odd is also good but not typically supported. This error cancellation doesn't happen with round half up or round half down.

Of course, we're rounding to integer here (rather than rounding the last digit in the mantissa) so the whole thing is pretty moot. I don't see much reason to include this.


Back in the late '70s I was working as a draftsman. Our drawings were in decimal inches, using two decimal places. The [rather large] company policy was a "5" in the third decimal place would round up a second-place "odd" but not a second-place "even". This was different from what I'd learned about rounding, namely that a "5" would always round up, so I inquired.

I was given the example of a part being an inch long with a hole placed at 3/8" from one end. If the dimensions were listed to both ends from the hole, they'd add up to 1.01 inches if both 0.375 and 0.625 had gotten rounded up.

Furthermore, all our calculations (figuring torque loads, etc.) were to be recorded on our scratch sheets using this method with the reason given as repeatability by subsequent folks who would likely have a different make/model calculator!

It would be very nice to be able to have a calculator which honored an individually-chosen rounding method, thus eliminating the necessity to "fix" two extra digits in the display. It would make it especially convenient to "RND" the displayed values, knowing that all results thus followed a (whichever) "proper" convention. It is exactly for this type of reason that prospects of such projects as this gives me joy. Depending on how far one might want to roll their sleeves up they should be able to customize to their heart's content.

Unbiased rounding, but w/o an application in mind. We discussed this earlier. In rare cases, a user might request a series of rounded numbers for further processing. However, to me it is just that I'm to proud using a rounding function only bankers would use ;-).

[Edit to remove one out of possibly many typos]

Edited: 27 Mar 2011, 7:28 a.m.


These commands round to integer. I just don't see the point of unbiased rounding here.


- Pauli


And I don't see the point of biased rounding ;-).

Well, hard to imagine anyone is doing statistics on rounded integers. OTOH ... you never know.

It's not at all important to me, I was just curious about the choice of the rounding method. I guess it is tradition, or to not be questioned by people expecting something different.

While we're on this topic: I really would like a special command that rounds the 16-digit value to the displayed 12 significant digits, removing the four additional "guard digits". In other words: a simple shortcut for

RCLM
X<>Y ; save display mode
SCI 11
RND ; round to 12 sign. digits
X<>Y
STOM ; restore display mode
DROP
...just without disturbing the stack. In the olden days there was a similar key sequence for the TI58/59 which used EE INV EE to remove the three guard digits.

Dieter


Hallo Dieter,

one possibility may be attaching a parameter to RND, so something like RND 12 would do what you want.

Walter


... using whichever "MODE"d method of rounding (or truncating) has been selected would be especially tasty...

Yes, this could actually be used for three different ways of rounding:

  • "RND 4" could round X to 4 digits behind the decimal point
  • "RND -4" might round X to 4 significant digits
  • "RND ," would round X according to the current display mode

Dieter

Executing ROUND in ALL mode also does this.

All mode is set by default after an erase and by "FIX ."


- Pauli

Quote:
Change the icon from hp to wp, please

We did already. We didn't highlight the changes, however, so look carefully ;-)

I'd have noticed, but I was using an outdated version. Great :-).


The logo looks like the hp logo but I can tell it is different. Also, if the keyboard is used, it is best to use the keypad or use NUM LOCK on the keyboard.

Might be better to make it even more distinctive that it isn't an "hp" and avoid any possibility some overzealous brand protection lawyer takes issue. They can even be sensitive about things like "the way it looks" and so on.

TW


Tim,

Please, send'em to China. They'll find more than enough important work there, so they don't need shooting at a community project.

Ceterum censeo: HP, launch a 43S yourself.

Walter

The latest enhancements, bugfixes and a new manual have been uploaded to SourceForge.

* All known bugs and crashes are hopefully gone.

* PSE (formerly PAUSE) now has a duration parameter in tenth of seconds. Indirection via -> works in the usual way.

* Two new functions compute the first and second derivative of a programmed function. See manual for details.

* Numerical accuracy has improved in certain areas.

It's still "only" an emulator. Feel free to complain. ;)

Edited: 27 Mar 2011, 2:38 p.m.


Fine - Solve and Integrate no longer chrash now. But Integrate returns its result with the wrong sign. At least if, according to the manual, the lower limit is in Y and the upper limit in X.

   LBL C                               LBL D
SIN X^2
RTN 2
-
DEG RTN
0 ENTER 90 Integrate C 0 ENTER 1 Integrate D
=> -57,2957795131 => 1,66666666667
Unlike the classic HP implementations, Integrate also does not seem to return the estimated error in Y.

I also noticed that Solve behaves slightly different from the way it is implemented in the 34C and 15C. There, X and Y return the two best possible approximations, which are usually equal or differ only in the last digit. 1 ENTER 2 SLV D returns 1,41421356237 in X, but 1,41421356696 in Y.

The manual also says that Solve and Integrate work as in the 15C. As far as I know the 15C fills the whole stack with the current x-value, just like my 34C. Here on the 34s, this obviously is not the case.

Is this the way these functions are supposed to work or is the manual wrong?

Dieter

Edited: 27 Mar 2011, 4:24 p.m. after one or more responses were posted


The sources of the solver and integrator are in the 34slib directory. So you can check for yourself. But I'm sure, Pauli will have some explanations for you.


I took a look at integrate.txt and found:

On return the stack looks like:
L integral (Gauss)
I unchanged

T lower limit (Y on input)
Z upper limit (X on input)
Y error estimate (Gauss - Kronrod)
X integral (Kronrod)

In fact, on return T holds the original X-value and Z the original Y-value, which would explain the erroneous sign.

On the other hand I was wrong about the missing error estimate. It actually is returned in Y, but it was zero for the example since the algorithm gives an exact result for the mentioned function.

Dieter


Just did an integration of sin(x)/x from -1 to 1 in RAD mode.

X returned value, but Y when shown with x<>y showed "Not Numeric".

Ideas?


"not numeric" indicates an IEEE NaN ("Not a Number"). You can easily create one with "0 ENTER 0 /". I've no idea what caused it in the integrator. We have to wait for Pauli to answer the question properly.


Probably the function is evaluated at x=0, when this happens.

Quote:
"not numeric" indicates an IEEE NaN ("Not a Number"). You can easily create one with "0 ENTER 0 /". I've no idea what caused it in the integrator. We have to wait for Pauli to answer the question properly.

Unless you set the danger flag (flag D), this won't create a NaN, it will show a domain error.

There is, however, an easy way to make one. In the constants catalogue there is a NaN entry :-)


- Pauli

Same here. And again the absolute value is right but the sign is wrong (result should be +1,892166...). In any case adjusting the integration algorithm is trivial. ;-)

Dieter

Quote:
Just did an integration of sin(x)/x from -1 to 1 in RAD mode.

X returned value, but Y when shown with x<>y showed "Not Numeric".

Ideas?


The Kronrod estimate failed because of the divide by zero when evaluating at the mid point, x=0, so the Gauss estimate was returned without an error estimate.

PS: use the built in SINC function instead for this. It handles x=0 properly :-)


- Pauli

The real sources are in trunk/xrom.c. Although this is a C file, it really contains keystroke programs.

The doc/integrate.txt version is slightly different but using both allows double integrals to be evaluated :)


- Pauli

Quote:
I also noticed that Solve behaves slightly different from the way it is implemented in the 34C and 15C. There, X and Y return the two best possible approximations, which are usually equal or differ only in the last digit. 1 ENTER 2 SLV D returns 1,41421356237 in X, but 1,41421356696 in Y.

This is the same behaviour. We converge slightly faster than the 34c and 15c usually do :-) We not only do a secant step with a bisection guard but we've got a quadratic regression step as well. There is the option for a Ridder's step as well but that didn't seem to improve matters enough to warrant the extra code.

That said, we don't always return the second best estimate, just a recent one. In this case, however, it is returning the previous estimate.


Quote:
The manual also says that Solve and Integrate work as in the 15C. As far as I know the 15C fills the whole stack with the current x-value, just like my 34C. Here on the 34s, this obviously is not the case.

We fill X, Y, Z & T with the value like the 15c and 34c.
This is the whole stack in SSIZE 4 mode and not in SSIZE 8 mode.


I've fixed the sign problem with integrate.
I have thought it was backwards for ages but didn't check the 15c manual to be sure.


- Pauli


Quote:
That said, we don't always return the second best estimate, just a recent one. In this case, however, it is returning the previous estimate.

I always considered the 34C/15C way very useful. Solving x^2 - 5 shows immediately that sqrt(5) is somewhere between 2,236067977 and 2,236067978. ;-)
Quote:
We fill X, Y, Z & T with the value like the 15c and 34c.
This is the whole stack in SSIZE 4 mode and not in SSIZE 8 mode.

Sorry, must have been my fault yesterday when it didn't work. Anyway, now it's working fine.
Quote:
I've fixed the sign problem with integrate. I have thought it was backwards for ages but didn't check the 15c manual to be sure.

If you look very closely the 34C and 15C key labels say "Integral from y to x". The limits are entered just the way you would expect. It's as intuitive as log_x of Y. :-)))

Dieter

I've just released a new version of the emulator dll. It fixes a minor annoyance with moving the frameless emulator off the screen.

Stay tuned for 1.17 and the "real thing"! we are making progress. :)


FYI the titlebarless minimize-to-taskbar is now completely borken in my wine/Linux. I must kill the process manually. It's inconsequential to me in any event since I just shove the titlebar out the top of the display anyway. If the program was stopped normally with a hidden titlebar, at next restart it's initially displayed with space allocated above it for a titlebar anyway, so there's absolutely no benefit to be derived for me to hide the titlebar; I must still Alt-grab/move the window anyway.

All else that I've toyed with in the "calculator" seems to work just fine; I realize this current "problem" doesn't reflect upon the calculator operation itself, but I suppose anything worth doing is worth doing right; right? :)


Glen, I apologize. This is code originally created by HP. It makes some assumptions about what is passed as the position on the screen to the move routine on minimize/restore. Probably Wine works differently here. You should replace the dll by the old version if you still have it. Walter B benefits from the recent changes, as do presumably other Windows users.

Any Wine specialists here who know what gets passed to the window move message in x and y when an application is minimized? On Windows it's -32000 for both.

EDIT: I've updated the DLL again. Please try it out and report here!


Edited: 1 Apr 2011, 4:09 a.m.


Now the old bug returned: Under Windoofs 7 (not that I like it but I have it) I cannot move the emulator window over the top limit of the screen again. We had that once before and repaired it ... :-?


The repair broke Wine. I can move the emulator (but not beyond the LCD). It works only in frameless mode.


Oh, well. May just as well get the code compiled where it'll run on the native hardware at this point instead of chasing this little mess. Whatever you want to do with the emulator is fine by me. I rarely run it without the titlebar (mostly just to test what you're ever currently trying at the moment). And I almost-as-rarely minimize a window, seeing how the "device" maintains state and is so readily accessible.

Thanks for all your (plural) work on this project.


Progress on the hardware port is slow. It is really hard to deal with all the power saving stuff necessary to conserve battery power while maintaining a good performance and useful overall functionality. A first go on the hardware may be possible some time next week. I need the weekend for other things. :)


Possibly Related Threads...
Thread Author Replies Views Last Post
  Another wish for next Prime firmware release Jose Gonzalez Divasson 0 277 11-21-2013, 06:55 AM
Last Post: Jose Gonzalez Divasson
  latest prime software release? Geoff Quickfall 3 476 10-12-2013, 03:53 PM
Last Post: Tim Wessman
  HP-15C Simulator / Release 3.2.00, Build 5319 Torsten 10 838 05-11-2013, 05:19 PM
Last Post: Thomas Klemm
  [WP34S] WP34S firmware on the AT91SAM7L-STK dev kit? jerome ibanes 1 318 10-04-2012, 04:59 PM
Last Post: Paul Dale
  WP 34S: New release on SF Marcus von Cube, Germany 5 463 02-20-2012, 04:49 AM
Last Post: Marcus von Cube, Germany
  New release of go41cx Olivier De Smet 6 539 02-02-2012, 04:06 AM
Last Post: Alexander Oestert
  [wp34s] Incomplete Gamma on the wp34s Les Wright 18 1,176 12-06-2011, 11:07 AM
Last Post: Namir
  [wp34s] Romberg Integration on the wp34s Les Wright 2 382 12-04-2011, 10:49 PM
Last Post: Les Wright
  WP 34S: Release Planning Marcus von Cube, Germany 3 324 10-27-2011, 02:24 AM
Last Post: Alexander Oestert
  HP 15c LE - pre-release firmware available? Alexander Oestert 0 185 10-03-2011, 04:34 AM
Last Post: Alexander Oestert

Forum Jump: