WP-34s Functionality Poll



It looks like there is a small amount of flash free after all the current functions are included plus a couple of extras recently finished. So we're taking suggestions as to what should be included. There is no guarantee that anything specific will go in of course. There isn't even a guarantee that we'll add anything else.

We've recently added additional statistics and a very simple TVM equation. We will likely add a keyboard poll routine.

Things that aren't going to be possible, so don't bother suggesting these:

  • User writable flash based storage - there isn't a clear page.
  • I/O commands - there is none on the device.
  • Financial commands - we've got a TVM command and quite a few percentages already and that is enough. This is a scientific calculator not a business one.
  • Cannot use any RAM storage - persistent RAM is full and there isn't any spare.

What we do have implemented already and thus are easy to add are:

  1. AGM - The limit of the arithmetic / geometric mean. Defined in both reals and complex versions.

  2. Riemann's Zeta function - Defined for both real and complex argument.

  3. Digamma (Psi) - The digamma function d/dx Ln(Gamma(x)). Defined for both real and complex arguments.

  4. Jacobi's Elliptical Functions - SN, CN & DN defined for real and complex arguments.

  5. Bessel Functions (real) - Jn, In, Yn & Kn. Real order and argument. I've separated the real from the complex here since these functions are quite large and the complex versions aren't working yet.

  6. Bessel Functions (complex) - Jn, In, Yn & Kn. Complex order and argument. I've separated the real from the complex here since these functions are quite large and the complex versions aren't working yet.

  7. Fused Multiply Add - A single operation that returns X*Y+Z correctly rounded in the last digit. Defined for real arguments only. This operation can be done using a complex multiplication but less nicely.

  8. Cubes - Cube root of X and X^3. The cube root correctly handles negative values unlike 3 1/x y^x. Defined for real and complex arguments as well as in integer mode.

  9. x!! - The double factorial function defined for real and complex argument.

  10. !n - The subfactorial or derangement function defined for integer real arguments only.

  11. Easter - Given a year or date, return the date of Easter for that year.

The only other piece of functionality that can be easily included is to add a Ridder's Step into the solver. The solver uses a variation of Brent's Method and I didn't notice any improvement by adding Ridder's Step in the little testing I undertook.

Feel free to suggest other functions or capabilities (or better submit code for them).

We can also add keystroke programs to flash and these are generally fairly code dense. If people have pet programs of this nature, feel free to port them to the 34s and submit the code. There are fifteen hidden flags (00-14) and five hidden registers (00-04) that flash based programs can use freely without disturbing user programs. Flash based programs can optionally take a user label as an argument and can call back to this user code -- this being how solve and integrate are implemented.

- Pauli

edit: added note that RAM is full


Edited: 2 Apr 2011, 5:23 p.m. after one or more responses were posted


I suggest the following functions:

1. Legendre polynomials.

2. Lauguerre polynomials.

3. Hermite polynomials.

4, Chebyshev polynomials.

5. Gauss–Laguerre quadrature (from 0 to infinity).

6. Gauss-Chebyshev quadrature (from minus infinity to plus infinity).

Namir

Edited: 2 Apr 2011, 5:47 a.m.

I haven't been following the 34s as closely as I'd like, so I don't know if you have onboard help. If not, this might be a good thing to add.

But mostly, I would leave the space empty so there's room for future bug fixes.

Dave


We're talking of kilobytes not megabytes. ;)

No, help will certainly not be on the machine. The display is just too limited.

Hi Pauli,

I haven't studied the current 34s functionality yet, but are date calculations (as in the DATE menu on the 30b) included? This I find useful (and fun).

Out of the suggestions you put forward, I'd go for the Bessel functions.

Maarten


Hi Maarten,

Date calculations featured: DATE, DAY, DATE+, [Delta]DAYS, etc. Please read the documentation contained in the zipped package found here d8-) for full information.

Walter


And conversion to and from Julian day numbers.

And date of Easter if enough people want it :-)


- Pauli


The date routines only work for Gregorian Dates (i.e. since 15-Oct-1582). Adding Julian calendar support (by assuming a proleptic Julian calendar for every earlier date) is virtually no effort. Common algorithms handle years down to -4712. Various methods can be found on this Website. Readers interested in the basics of calendar calculations start here.

Another option is a general calendar flag (similar to the date mode setting) that switches between the Gregorian and Julian calendar - which is still used in some parts of the world.

This example is one of the reasons why I think the WP34s does not need more functions, but better implementations instead.

Dieter

Edited: 3 Apr 2011, 10:55 a.m.


Hallo Dieter,

Quote:
Another option is a general calendar flag (similar to the date mode setting) that switches between the Gregorian and Julian calendar - which is still used in some parts of the world.

I count this as your suggestion.
Quote:
This example is one of the reasons why I think the WP34s does not need more functions, but better implementations instead.

Where's the beef? What do you want implemented differently?

Walter


Hallo, Walter -

Quote:
I count this as your suggestion.

The addition of earlier dates than 15-Oct-1582, yes. The calculator should be able to handle dates both before and after this date. So that, for example, ddays(4.10.1582, 15.10.1582) will return 1 in Gregorian mode and 11 in Julian mode.
Quote:
Where's the beef? What do you want implemented differently?

There are issues with some functions regarding numeric accuracy. I expect a quality calculator to return results within 1 ULP. Otherwise this has to be documented and the result should be rounded to the number of actually valid digits. Back in the Seventies, my first calculator could evaluate all transcendent functions to not more than 5 significant digits. So it returned lg 2 as "0,30103" - and not one single digit more. At least an honest answer. It didn't pretend to be more precise than it actually was. ;-)

I haven't checked all more or less exotic functions on the 34s, but I took a closer look at the normal distribution. With 39 internal digits a 16-digit result should be no major problem, even with the quantile function. Right now this function returns good results in the far tails (the values I checked were correct within 1 ULP), but there is a problem with common values in the range p = 0,01 ... 0,2. Here, the emulator sometimes requires up to one whole second (!) on a 1,8 GHz system before it returns a result with not more than 11-12 valid digits:

    p        exact z-quantile            WP34s result
0,01 -2,326 3478 7404 0841 -2,326 3478 7404 0841 so far,
0,03 -1,880 7936 0815 1251 -1,880 7936 0815 1251 so good. ;-)
0,05 -1,644 8536 2695 1473 -1,644 8536 2697 9906 but then...
0,10 -1,281 5515 6554 4600 -1,281 5515 6554 8626
0,15 -1,036 4333 8949 3790 -1,036 4333 8949 4112
0,20 -,8416 2123 3572 9142 -,8416 2123 3574 9220
The problem already starts with the simple CDF:
    x        exact CDF                 WP34s result
-0,5 3,085 3753 8725 9869 E-1 3,085 3753 8726 0659 E-1
-0,8 2,118 5539 8583 3967 E-1 2,118 5539 8583 5966 E-1
-1,0 1,586 5525 3931 4571 E-1 1,586 5525 3932 2540 E-1
-1,5 6,680 7201 2688 5807 E-2 6,680 7201 2717 4097 E-2 (!)
-2,0 2,275 0131 9481 7921 E-2 2,275 0131 9481 7921 E-2
I also tried some calculations with Student's distribution - with similar results.
    p    df     exact t-quantile          WP34s result
0,01 3 -4,540 7028 5856 8134 -4,540 7028 5856 8325
0,05 5 -2,015 0483 7333 3024 -2,015 0483 7333 3021
0,10 5 -1,475 8840 4882 4481 -1,475 8840 4882 4385

t df exact CDF WP34s result
-1 5 0,1816 0873 3824 5613 0,1816 0873 3823 9048
-2 7 0,0428 0966 4281 48803 0,0428 0966 4281 48889

So the precision is something between 10 and 16 digits. I just noticed that the latest 34s-version uses only the displayed 12 digits when "copy number" is used (instead of all 16 before). This makes some sense... ;-)

Dieter

Edit: correction because of cdf and pdf confusion. ;-)

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


I'm wondering how bad these values really are.

For the values I tested, applying the cdf to the answer comes back to the initial value within a couple of ULP and in many cases back to the exact initial value.


- Pauli


Yes, that's exactly the point: there are errors both in the CDF and its inverse. If the inverse (quantile) is calculated by the solver, it has to return an erroneous result, because it thinks it has found the correct inverse, since the CDF of the current root indeed returns the expected probability (and not the correct value, slightly off).

Example:

    Exact normal quantile for p = 0,1:
z = -1,281 5515 6554 4600
Normal CDF for this value on WP34s:
=> p = 0,1000000000007065
Which makes the solver think it has to correct the already exact z-result.

Actually the CDF is (almost) exactly 0,1:
p = 0,1 (+8E-17)

On the 34s only the "wrong" value
z = -1,281 5515 6554 8626
returns the same nearly-exact
p = 0,1 (-7E-17)

In other words, most of the inaccuracies (not all) should be gone once the CDF is computed correctly.

Pauli, please forgive me if I'm a bit picky here. I really appreciate all your (and Walter's) effort for the WP34s project. But all I want is a calculator that returns correct results. :-)

Dieter

Edited: 4 Apr 2011, 2:25 p.m.


Quote:
Yes, that's exactly the point: there are errors both in the CDF and its inverse. If the inverse (quantile) is calculated by the solver, it has to return an erroneous result, because it thinks it has found the correct inverse, since the CDF of the current root indeed returns the expected probability (and not the correct value, slightly off).

Drat, I thought I'd fixed the normal cdf problems :-( Obviously not quite yet.

Even if the cdf was correct, there will still be problems with the qf. The inversion maps p in the range 0, 1 onto x in the range -infinity, infinity. There must be multiple floating point values of x that map from the same p simply because there are more values of x than p.


Quote:
Pauli, please forgive me if I'm a bit picky here. I really appreciate all your (and Walter's) effort for the WP34s project. But all I want is a calculator that returns correct results. :-)

No, keep it up. This is the best way to identify and fix problems :-)


- Pauli


It's the main point of having ported the Windows emulator from the SDK over to wp34s: Attract more testers to find bugs or get their opinions.

I think the major problem here is the general common approach that's used for different distributions, not only for the Normal case. If I remember correctly, some time ago you said the Normal integral as well as some other CDFs are treated as a special case of some kind of Beta function, and for the inverse the solver is used.

Obviously the CDF is not evaluated exactly enough to get near machine precision. On the other hand, at least for the normal distribution the CDF can be computed with arbitrary precision - fast and with little memory usage. I tried the usual two algorithms (cf. Abramowitz and Stegun 26.2.11 for the center and 2.26.14 for the tails) on the emulator and the results are mostly within 1 ULP when rounded to 15 significant digits. With a working precision of 20 digits a full 16-digit result is no problem at all.

There are also fast and precise ways to determine the inverse. If the classic approach (three (7;7) rational approximations) is not possible the value can be evaluated to 9 digits with an additional Newton step, which is trivial since we know the CDF's derivative, i.e. the PDF.

However, using the solver should not be a problem here. First, the equation to solve for x can be ln(x) = ln(p), as discussed before. This requires at least three guard digits, so we're already on the safe side when we use the proposed 20 internal digits (39 are fine, but not necessary).

You said there will be a problem with the inverse since it maps the ]0; 1[ range to ]-inf, +inf[: "There must be multiple floating point values of x that map from the same p simply because there are more values of x than p." Well, this is also true for functions like arcsin or arccos. ;-)

For most values of p using the solver should return the correct result. Consider this example:

     p =  1 E-99
=> x = -21,16 5179 3439 3891 1286 9902 2340 ...
If this value, rounded to 16 digits, is fed back into the CDF routine, the correct result is
     x = -21,16 5179 3439 3891
=> p = 1,000 0000 0000 0027 E-99
If x is now increased only by 1 ULP, the CDF will change significantly:
     x = -21,16 5179 3439 3892
p = 0,9999 9999 9999 8152 E-99
So the solver "knows" that the exact value is somewhere between these two adjacent x-values, and there simply is no 16-digit result which would return an exact 16-digit 1,000 0000 0000 0000 E-99. The closest possible result is -21,16 5179 3439 3891.

It can be shown that there is no problem with any x >= 1. Here, changing x by one ULP means that the CDF will change by more than 1,7 ULP, up to several hundred ULPs (like in the example). In other words: any change in x will result in a more or less even bigger change in the CDF. So the solver can be used.

The only problem are values where x < 1. Here in fact several x-values can return the same CDF. Right in the center even a difference in the first or second (!) significant digit of x makes no difference for the CDF. So here the solver will fail. However, it will work if the calculation can be done with twice the number if digits required in the final result, i.e. in this case with 32 digits.

Dieter


Quote:
If I remember correctly, some time ago you said the Normal integral as well as some other CDFs are treated as a special case of some kind of Beta function, and for the inverse the solver is used.

I'm using the regularised incomplete gamma function for the normal. The incomplete beta is used for the F and T distributions amongst others. I've had doubts about the implementation of these two for a while now.

We've also found a problem with using for solver for Chi squared distribution. I'm going to rework all these distributions so that the solver isn't used. It will consume a goodly amount of our remaining space but it should be worthwhile.


- Pauli


Quote:
It will consume a goodly amount of our remaining space but it should be worthwhile.

For sure it shall, though it will consume a good amount d;-)

I've recoded the normal CDF and it looks good now. Your examples above are all coming out correct to the last digit. The solver seems to work okay but the time to computer will likely be large. The new binary is in subversion on sourceforge but not properly released yet.

Now the rest of the distributions...


- Pauli


Quote:
I've recoded the normal CDF and it looks good now. Your examples above are all coming out correct to the last digit.

Fine. BTW, for those who need high precision values for various functions (or simply want to check the results of their algorithms without a Mathematica installation): try this service by an unnamed calculator manufacturer. ;-) The maximum precision is 50 digits.

Quote:
The solver seems to work okay but the time to computer will likely be large.

So the two initial guesses are somewhat off. There are various simple ways to fix this for the normal quantile:
  • Determine a high-quality estimate by using a known approximation, such as the good old Hastings method (absolute error < 0,00045). Or, even better, the Bailey method (cf. Applied Statistics vol. 30 no. 3, 1981), or an improved version I worked out some time ago. ;-) After this, a few Newton iterations will provide the exact quantile. Or, even better, two or three Newton-Halley steps, which is trivially simple here, giving about 2-3 times the number of correct digits with each step. Of course also the solver can be used instead.

  • If the solver is used two quite good initial guesses can be evaluated this way:
        0,5 >= p >= 0,15         0,15 >= p > 0
    -----------------------------------------------
    a = 3 * (0,5 - p) a = sqrt(-2*ln(p) - e)
    b = a * 5/6 b = a - 1/4
    The exact result is in this interval. The two guesses differ only by 20% resp. by merely 0,25 so that the solver will find the result fast with only a few iterations.

Addendum: I just tried the solver in a WP34s user program with the two initial guesses mentioned above, solving for the root of the equation ln 1 + (cdf(x)-p)/p to avoid problems in the far tails, using the ln1+x function. The results are returned immediately and the values I checked show about 15 valid digits (out of the 16 used for all calculations).

Dieter


Edited: 7 Apr 2011, 9:09 a.m.


Hallo Dieter,

Quote:
BTW, for those who need high precision values for various functions (or simply want to check the results of their algorithms without a Mathematica installation): try this service by an unnamed calculator manufacturer. ;-) The maximum precision is 50 digits.

Great link. Thanks :-)

Walter

Quote:
BTW, for those who need high precision values for various functions (or simply want to check the results of their algorithms without a Mathematica installation): try this service by an unnamed calculator manufacturer. ;-) The maximum precision is 50 digits.

I use Wolfram alpha which seems to be Mathematica in disguise.


- Pauli

Quote:
If the solver is used two quite good initial guesses can be evaluated this way:
    0,5 >= p >= 0,15         0,15 >= p > 0
-----------------------------------------------
a = 3 * (0,5 - p) a = sqrt(-2*ln(p) - e)
b = a * 5/6 b = a - 1/4

This works wonderfully. I've modified the normal quantile function to start with these guesses and convergence to full precision is a matter or ten or so iterations everywhere except at the very extremes.

I've also fixed up the solver based quantile functions for the chi^2, t, f, binomial and Poisson distributions. Although the initial estimates here aren't very good so convergence isn't always quick. If anyone can suggest decent initial values for these distributions, it would be appreciated.


- Pauli


Quote:
This works wonderfully. I've modified the normal quantile function to start with these guesses and convergence to full precision is a matter or ten or so iterations...

Fine. Although it should take less than ten iterations. ;-)

Quote:
...everywhere except at the very extremes.

The mentioned formulas for the two initial guesses are very simple. But they approximate the exact value with a relative error less than 20% resp. an absolut error less than 0,25. With a little more effort we can easily provide two better guesses which can nail down the true value with an absolute error in the order of 10^-5 to 10^-8 (!) in the far tails (p =< 10^-10). This is possible because here the quantile can be evaluated by a series - the farther out in the tail, the less terms are required, especially with a little tweaking of the "exact" series. ;-) So it comes down to the question how much effort (and memory) can be spent for two even better initial guesses which would require, say, only 1/2 or 1/3 the number of iterations.

Here's a quick and dirty improvement for the far tail. It's a slight modification of the original formula, now providing two guesses that are only 0,09 or even merely 0,025 apart:

    0,15 >= p > 0
-----------------------
a = sqrt(-2*ln(p) - e)
b = a - 1/4
if a >= 4,5 then a = a - 1/a ; b = a - 1/11
or, even better, but on a smaller interval:
    if a >= 9 then a = a - a^-(3/4) ; b = a - 1/40

On the other hand, in the very center (i. e. p close to 0,5 resp. z close to zero) using the solver will cause problems because there are multiple z-values that will return the same 16-digit CDF. I would suggest the following solution:

Near p = 0,5 the quantile can easily be calculated directly (!) by a simple series:

     u  =  sqrt(2*Pi) * (p - 0,5)
1 7 127 4369 243649
z = u + -- u^3 + -- u^5 + --- u^7 + ---- u^9 + ------ u^11 + ...
3! 5! 7! 9! 11!
The nominators of the coefficients are integer series A002067.

For 0,495...0,505 (or |u| =< 0,0125) an exact 16-digit results requires only four terms, i.e. up to u^7. With one more term (u^9) the result is exact for p = 0,486...514 (or |u| =< 0,035).

This leads to the following algorithm (assuming p =< 0,5):

    if p > 0,15 then
u = sqrt(2*Pi) * (p - 0,5)
a = u + (u^3)/6 + (u^5)*7/120 + (u^7)*127/5040
if p > 0,495
then return a and quit ; a already is exact
else
b = a * 1,006
return solverresult(a, b)
end if
else ; p =< 0,15
a = sqrt(-2 * ln(p) - e)
b = a - 1/4
if a >= 9 then ; far tail
a = a - a^-(3/4)
b = a - 1/40
end if
return solverresult (a, b)
end if

In other words: for p > 0,15 determine a very good first guess. If p is close enough to 0,5 this guess already is exact, so simply return it as the final result. Otherwise provide a second guess slightly higher and let the solver do the rest. Which is done very quickly since the error is less than 0,6%. In the tails determine two reasonably good guesses, and in the far tails two even better ones that reduce the remaining error by a factor of 10.
Quote:
I've also fixed up the solver based quantile functions for the chi^2, t, f, binomial and Poisson distributions. Although the initial estimates here aren't very good so convergence isn't always quick. If anyone can suggest decent initial values for these distributions, it would be appreciated.

For these distributions things are a bit more complicated, especially in those cases where there's more than one parameter.

Dieter


Edited: 10 Apr 2011, 11:48 a.m.


Quote:
Although it should take less than ten iterations.

Not to full precision it shouldn't :-) I could cut back the accuracy to a few more than the 16 digits we need if performance is lacking.

I'll have a look at your other suggestions, this function is used internally in a couple of places so making it faster is worth a bit more flash (but not a lot).


I've done approximations for the chi^2 and t distributions that aren't awful. For chi^2 I'm using one of the asymptotic normal approximation to provide bounds -- unfortunately not fantastically tight but better than nothing.

For t, I'm solving exactly for v=1 or 2 and using the v=2 estimate and the normal estimate as bounds for the search -- the result must lie in this range. I looked at using the exact v=4 solution but it seemed to be more effort than it was worth. These bounds are fairly tight around the middle of the distribution and become progressively looser at the far extremes.


Pauli


Quote:
I could cut back the accuracy to a few more than the 16 digits we need if performance is lacking.

No way! I got this off-brand RPN-calculator, probably a kind of Novus clone, that needs several seconds for all its inverse trig functions, before it finally displays a 12-digit result... with usually 10 valid digits. I think we can do better. ;-)
Quote:
I'll have a look at your other suggestions, this function is used internally in a couple of places so making it faster is worth a bit more flash (but not a lot).

There are several options. It is quite easy to set up a simple approximation for the normal quantile with a combination of elementary functions. I tried a slighty more sophisticated approach than before, resulting in a maximum absolute error near 0.02, approaching zero in the center and something close to 1E-4 for p < 1E-50. On the other hand a very simple rational approximation can be used, which requires only four 3-digit coefficients and returns a result with absolute error less than +/- 0.002 over the whole range from p = 0,5...1E-400. I think this is the preferred solution.
Quote:
I've done approximations for the chi^2 and t distributions that aren't awful. For chi^2 I'm using one of the asymptotic normal approximation to provide bounds -- unfortunately not fantastically tight but better than nothing.

Sorry, right now I got no idea for the Chi^2 case.
Quote:
For t, I'm solving exactly for v=1 or 2 and using the v=2 estimate and the normal estimate as bounds for the search -- the result must lie in this range. I looked at using the exact v=4 solution but it seemed to be more effort than it was worth. These bounds are fairly tight around the middle of the distribution and become progressively looser at the far extremes.

There are algorithms like the good old A396 which - with some small improvements - can give results with errors near 1E-6. This method requires a more or less precise estimate for the normal quantile, where 6 digits of z should be fine for a decent t-approximation. Afterwards the solver should find the exact value with just a few iterations.

Dieter


A few days ago I wrote:

Quote:
On the other hand a very simple rational approximation can be used, which requires only four 3-digit coefficients and returns a result with absolute error less than +/- 0.002 over the whole range from p = 0,5...1E-400. I think this is the preferred solution.

And here it is - I designed a rational approximation, hand crafted to meet our needs. ;-) It has the following properties:
  • It works for probabilities down to 1E-500 or |z| up to 48.
  • It requires only four numeric constants with just two or three significant digits.
  • No special care has been taken of the center (z very close to zero) since here the exact quantile can be evaluated easily.
  • It returns an estimate for |z| which is slightly high (in absolute terms). The absolute error is greater than 0,0001 and less than 0,0036. So this estimate and a second guess 0,0037 lower define an interval that definitely includes the exact quantile.

So the normal quantile can now be evaluated this way:

if p > 0,5
then
signflag = false
q = 1 - p
else
signflag = true
q = p
endif
if q >= 0,495
then ; use series and determine exact result
t = (0,5 - q)^2 * 2 * Pi
z = (127/5040*t + 7/120)*t + 1/6)*t + 1) * sqrt(t)
else ; use solver with two close guesses a and b
t = sqrt(-2 * ln(q))
a = t - (0,373*t + 2,37)/((0,068*t + 1,1)*t + 1)
b = a - 0,0037
z = solver(a, b)
endif
if signflag then z = -z
return z

And now for the t-quantile... ;-)

Dieter

Now I feel ashamed.

My implementation of the incomplete beta function terminated when successive terms were 1e-10 apart. Fixing this, and the T distribution matches your values.

This should follow over for the F and binomial distributions which are also special cases of the incomplete beta function.

Still, the inverses could do with some work to avoid the solver.

- Pauli

[edit: and a similar problem in the incomplete gamma function]

Edited: 7 Apr 2011, 7:36 a.m.

I think I've finally fixed the cdfs. A new version is in subversion but not released yet.

Now for the quantile functions without the solver.


- Pauli

Quote:
The date routines only work for Gregorian Dates (i.e. since 15-Oct-1582).

They are coded to work for Gregorian and Julian dates with a change over 2nd of September 1752 the next day being the 14th. This matches the Unix date command. They worked when I last checked them (which was quite a while ago).

What exactly isn't working?


- Pauli


Hi Pauli,

Quote:
They are coded to work for Gregorian and Julian dates with a change over 2nd of September 1752 the next day being the 14th.

Yes, indeed. I was quite sure that the last time I checked, dates before 1582-10-15 were rejected. Which made perfect sense to me. Sorry for the confusion, you're right.

However, the switch between Julian and Gregorian dates should be between 1582-10-04 and 1582-10-15. This is the official date of the calendar switch, initiated by pope Gregory XIII - cf. Wikipedia: The last day of the Julian calendar was Thursday, 4 October 1582 and this was followed by the first day of the Gregorian calendar, Friday, 15 October 1582 (...).

It is correct that the Gregorian calendar was only gradually adopted throughout the world, especially in Protestant regions it took a while before the new calendar was used. In Britain (including its American colonies) the switch indeed took place in September 1752, while here in the Holy Roman Empire the Catholic parts of the country switched immediately in 1582, just as some South European countries, while others did so not before 1700. Japan followed in 1873 and Russia even continued to use the Julian calendar up to the 1920ies.

But if we have to set one single switch date, in my very humble opinion the only date that makes sense here is the 15th of October 1582, the official date mentioned in Inter Gravissimas. In this case the Julian day number for 1582-10-15 is 2299161, while the day before was 1582-10-04 with JD 2299160 (last day of the Julian calendar). The calendar algorithms I know of use this convention. OK, I don't know anything about Unix. ;-)

Dieter

I have just played for a few moments with the emulator, and browsed the overwhelming manual. In my opinion, mathematical/scientific needs have been impressively covered, beyond limits; so in first place receive my congratulations.

Given the display limitations and, worse, the key legends / overlay pending solution, I would suggest to implement one of the most useful features of the HP41/42, regrettably absent from other models, as the 48/49/50 and 32/33 lines: NULL. Holding down a key causes the function name to be dispayed and, after a couple of seconds, the function is cancelled. Going further, hints to function syntax may even be displayed in some cases.

For me, it's a good thing to check what function I'm about to invoke and, if the function is not the intended one, have a simple manner to cancel it. This is mostly useful when the keyboard can be remapped, but it also helps when the legends are not very readable, or when you just made a mistake.

Other possible feature on the "convenience" side may be a welcome screen with programmable owner's name (it must be a short string, indeed) and telephone number, allowing international formats as "+54 90 1234-5678","11 22 33 44", and "(212) 123-4567". The welcome screen should last for a configurable interval (for instance, 0, 5 and 10 seconds); the name may be scrolled due to display limitations. Regrettably, owner's email may be difficult to display.

Both of these functions don't need their own keyboard space, which seems to be more valuable and scarce than Flash space.

Best regards.

(Please disregard idiomatic mistakes)

Edited: 2 Apr 2011, 10:36 a.m.


I have yet to create the keyboard code for the real hardware. The emulator doesn't provide "key released" so this option is some more work if it should be available on the emulator as well as the hardware. Isn't it a bit confusing that a function is only executed as the key is released? What about repeating keys, e. g. the arrows?


Just some quick answers:

I don't think there is a serious problem if the emulator doesn't have the NULL option and the real hardware does.

In a calculator you don't have many auto-repeating keys, I can only think about Backspace and the up-down scrolling keys.

In normal use, there is no noticeable difference between functions executed on key press or on key release. Of course, a menu item may enable-disable this feature as per user preference.

Olá Andrés,

Quote:
I have just played for a few moments with the emulator, and browsed the overwhelming manual. In my opinion, mathematical/scientific needs have been impressively covered, beyond limits; so in first place receive my congratulations.

Muchas grazias! d:-)
Quote:
Given the display limitations and, worse, the key legends / overlay pending solution, I would suggest to implement one of the most useful features of the HP41/42, regrettably absent from other models, as the 48/49/50 and 32/33 lines: NULL. Holding down a key causes the function name to be dispayed and, after a couple of seconds, the function is cancelled. Going further, hints to function syntax may even be displayed in some cases.
Some syntax hints are displayed already, like on the HP 42S. I don't think we can go much further: the useable display space is very (!) limited indeed. Nevertheless, whenever you have ideas what may be displayed within 43x6 pixels, suggest it :-)

Personally, I think NULL is a good idea for the reasons you gave - and everybody can see it working on the 42S - but I'm not the HW guy in this project. I've experienced cases, however, where I'd wished NULL had been implemented already.

Quote:
Other possible feature on the "convenience" side may be a welcome screen with programmable owner's name (it must be a short string, indeed) and telephone number, allowing international formats as "+54 90 1234-5678","11 22 33 44", and "(212) 123-4567". The welcome screen should last for a configurable interval (for instance, 0, 5 and 10 seconds); the name may be scrolled due to display limitations.
We don't support scrolling yet - manual scrolling of alpha strings will come, automatic presumably not. Phone numbers may be displayed in the bottom line, but have a HW limit of 12 digits. So you better forget brackets, spaces and the like. Within these limits, almost everything is possible - see the extended character set provided d8-)

Walter

Nice suggestions.

You managed to hit one of the things I neglected to mention. Last time I checked, there were 12 bytes of RAM left & some of this will be required for the hardware drivers. So features that required extra storage are out.

This likely means no welcome message :-(

- Pauli

Edited: 2 Apr 2011, 5:21 p.m. after one or more responses were posted


Hello World!

We can display alpha or the contents of a user register on power up, if a flag is set.


Using a flag (or timeout values of 0, 5 and 10 secs, for instance) to display ALPHA and a user register may be a good way to show a welcome message and a telephone number without using extra memory. It would be nice to have some format options for the phone number, because not all countries have the same number and grouping of digits. Usual number formats will be of little help. Of course, the limitations of memory and flash space are there, and quite restrictive.


I suppose, the welcome message is intended for people who find (not steel) the lost calculator, not to remind the owner of his own phone number. In this case I suggest to just stick a printed label on the back. At least this is what I do with items I'm likely to lose because it doesn't depend on a working battery. And thieves won't be held back by either.

I don't see why Easter date calculation should take up memory. Don't you guys have a calendar? ;)

I also would not rule out business functions for the reason of it being a scientific calculator. These would open a large market. Business people would not mind the scientific functions and scientific users could use them from time to time as an added bonus.

Edited: 4 Apr 2011, 2:48 a.m.


Quote:
I don't see why Easter date calculation should take up memory. Don't you guys have a calendar? ;)

And your calendar tells you when Easter was in 1903 or when it will be in 2013? :-)


Quote:
I also would not rule out business functions for the reason of it being a scientific calculator. These would open a large market. Business people would not mind the scientific functions and scientific users could use them from time to time as an added bonus.

We're taking a perfectly good HP-30b and replacing its business functionality with scientific. Why would any business person want to do this? Any business functionality we add will pale in comparison to the original and the 30b has basic scientific support for those that require it.


- Pauli


Re: Easter

Sure, it might be a nice to have for some people (although I don't really see why one would need to find out the Easter date of 1903 on a calculator), if you have plenty of memory available! But if you don't, Easter would be the first to go IMHO.

Re: Business functions

There you have a point!

Re: Easter

Aren't there sometimes two different dates for Easter?

For instance next year, western Easter is April 8th but eastern (orthodox) Easter is April 15th.

Seems like more confusion than it's worth.


There are almost always different Easter dates for western and orthodox churches. Even if you would implement both functions, you still would have to accommodate Jewish and Muslim users with their even more different date calculation needs... ;)

But as I learned above, it is a purely scientific and not a business machine. Why would it need religious functions at all?

Edited: 5 Apr 2011, 2:03 a.m.


I suspect the likelihood of the Easter command being included it pretty close to zero, so we needn't worry ourselves.


- Pauli

Can you implement relational tests that compare the X and Y stack registers and SKIP TWO STEPS steps if the relation is false? I suggest the syntax to include TWO question marks, such as:

X=Y?? will skip two steps if X and Y are unequal.

X=Y? The current version that skips the next step if X and Y are unequal

I have come across many cases where I need to execute two steps if a relation is true. The suggested syntax will save using labels.

Example:

X#Y??
1
-
STO 0
...

As opposed to

X=Y?
GTO 1
1
-
LBL 1
STO 0
...

Namir


Edited: 2 Apr 2011, 1:10 p.m.


Next, you will want us to treat numbers (not digits) as a single step. Don't hold your breath!

There are the commands BACK and SKIP which are originally meant for the internal keystroke routines only but appear in a catalogue and can be used freely.


Edited: 2 Apr 2011, 1:30 p.m.

Yes, skipping two steps after a test would be nice. Or three steps, or four... ;-)

There are occacions where a "real", structured programming language has its advantages. But I don't think we will see much of this in the more assembler-like approach in an RPN calculator.

BTW - the problem you mentioned can be solved easily:

X#Y?             STO 01
DEC X or X#Y?
STO 01 DEC 01 ; leaves X unchanged
Yes, I like these INC and DEC commands. I already liked them 30 years ago on the TI58/59 with their OP 20..29 and OP 30...39. *g,d&r* ;-)

Dieter


Quote:
Yes, I like these INC and DEC commands.

Me too. They are a surprisingly recent addition and I'm finding I'm using them quite a bit already.

As for the initial question, negate the condition and use SKIP is the best solution.

I'm sorely tempted to expose some of the internal commands more freely:

  • SKIP nn - Skip ahead nn steps.
  • BACK nn - Skip back nn steps.
  • RTN+1 - Return from subroutine with a skip.

The first two are pretty useful to save labels and code space at the cost of uneditability. The third one is great for making your own conditional tests.

- Pauli

Edited: 2 Apr 2011, 4:53 p.m.


The BACK and SKIP commands should do instead of the multi-step-skip conditionals that I suggested.

Namir

My simple request would be to have the three decimal setting modes SCI/FIX/ENG automatically exit from FRACTION mode. I know the 32SII does this.


Quote:
My simple request would be to have the three decimal setting modes SCI/FIX/ENG automatically exit from FRACTION mode. I know the 32SII does this.

This is more like a bug than a new feature.
It will be done in the next release.


- Pauli

I don't know if this is easy or hard to add, but how about Stirling numbers and partition numbers? This would appeal to students and users of discrete math.

Paul Guertin

1) How about some extra statistics, if these aren't in already.

Covariance, standard error of the X and Y mean.

2) Of the ones already written, I'd like to see the Bessel functions and the double factorial.

But those are getting VERY picky on my part. :-)


Quote:
Covariance, standard error of the X and Y mean.

The latter two are in already, and standard error of weighted mean as well 8)

COV is a no-brainer - thanks for your suggestion - we missed that so far :)

Walter

If not too late, you can add this:

casio calculators (I have f9860g slim) has a mode where it is scientific but uses & accepts the greek alphabets to denote the 10^x part. for example. in electrical engineering, you can do 5V / 5k and you get the result in mA (5 / 5k = 1m).

I find it very useful especially in the lab, calculating stuff. I dont think hp calculators have that.

thanks,
erturk


Not that k and m look really Greek to me ;-) I understand what you want: kind of a special ENG mode with at least a part of the full line

 a   f   p   n   µ   m     k   M   G   T   P
-18 -15 -12 -9 -6 -3 0 3 6 9 12 15

I don't think any further prefixes became popular yet. So beyond P and below a the normal ENG mode would rule.

With the LCD given, however, and only 7 segments in the numeric section, displaying M in the exponent may look a bit strange, and I don't have any solution for m nor for differentiating P and p :-( So, sorry, I'd suggest a paper strip attached above of the display d:-)

Walter


Quote:
I don't think any further prefixes became popular yet. So beyond P and below a the normal ENG mode would rule.

'c' is quite popular :-)
It doesn't fit ENG mode.

At one stage, I did suggest some SI prefix constants/commands to do the multiply by the appropriate power of ten. It didn't make the cut.


- Pauli


Quote:
'c' is quite popular

Sharing my habitat with these units, I can tell you cm is the only really popular. And for beverages, you see cl on the jars. And that's it. But people understanding cm and cl understand mm and ml as well, so no need for an exception here. And those not understanding don't care either way.

Walter

Not for the WP-34S, but we may consider that, after P (peta) comes E (Exa). Certainly it would not fit, and an "E" may even be confusing with the "exponent" abbreviation for scientific notation. Oh , and now we have the "IT" prefixes like Ki (2^10), Mi (2^20) and so on. At least we don't have binary subunits!!

Paul,

My suggestion is the ‘two-sided’ inverse chi-square cumulative distribution function (to calculate confidence intervals for the variance and standard deviation).

Take example 1 on p. 18-34 of the HP 50g User's Guide (which is wrong).

‘Determine the 95% confidence interval for the population variance &#963;² based on the results from a sample of size n = 25 that indicates that the sample variance is s² = 12.5.’

The calculator would return two values, a = 12.79 and b = 40.38 (NOT a = 12.40 and b = 39.36 as given in the User's Guide), such that the integral from a to b of f(x), the chi-square probability density function, is 0.95 and that of x.f(x) is 24 (the number of degrees of freedom). The second criterion produces an ‘unbiased’ confidence interval that matches the unbiased estimator s². An equivalent criterion is that the integral from a to b of f(x) with an additional two degrees of freedom (i.e. 26) is also 0.95.

The confidence interval is then (7.43, 23.45).

Andrew

PS The work you have done is just outstanding.


Hi Andrew,

Quote:
My suggestion is the ‘two-sided’ inverse chi-square cumulative distribution function (to calculate confidence intervals for the variance and standard deviation).

Good idea. I'll check.

Walter


Andrew,

please apologize the long response time, but your question helped us unveiling a bug. Now here we go:

Quote:
‘Determine the 95% confidence interval for the population variance &#963;² based on the results from a sample of size n = 25 that indicates that the sample variance is s² = 12.5.’

Pedestrian's approach: 24 degrees of freedom, lower Chi^2 for 2.5% probability, upper Chi^2 for 97.5%.

Start WP 34S in FIX 2 mode (you can't do the following yet due to a bug in chi^2INV, but soon you will):

24 STO J
.025 chi^2INV ;returns 12.40 (access this function via PROB ^ XEQ)
/
12.5
x ;returns 7.62 as lower limit
RCL L
RCL J
x
.975 chi^2INV ;returns 39.36
/ ;returns 24.19 as upper limit
d8-)

IMHO the values given in the 50G manual are correct. Anyway, you suggest a function taking inputs of variance, probability, and degrees of freedom, and returning the limits of the confidence interval. For sake of equal opportunities, we shall then have similar functions for standard deviations and mean values. And other people may prefer single-sided limits. Eventually we’d have a whole bunch of special commands, where IMHO the look up time would exceed the time saved compared with keying in the formula directly. It's really easy as shown above. I’d prefer having a small routine for this task when I need such results frequently, assigned to one of the hotkeys. YMMV.

Walter


Walter,

Your response time is an order of magnitude better than mine. In helping you find a bug, at least I've made a small contibution to your work.

I'm not sure whether you are referring to the arithmetic or to the methodology in the HP 50g User's Guide. The arithmetic, as you have shown, is correct; the methodology is not.

An edge case will demonstrate why.

Let's change the example to calculate a 0% confidence interval, which must be [12.5, 12.5] because the confidence interval must contain the point estimator. According to the methodology of the User's Guide, the confidence interval would be [12.4998, 12.4998], which cannot be correct (although it is a very good approximation). The error arises from basing the confidence interval on the median instead of on the mean.

This only becomes relevant when calculating two-sided confidence intervals for asymmetric distributions, which excludes the normal and Student's t-distribution, leaving the chi-square and F-distributions, and I'm not sure there is any requirement to calculate two-sided confidence intervals for the F-distribution. Consequently, this would only need to be implemented for the chi-square distribution.

The function would take two inputs, the number of degrees of freedom (e.g. 24) and the size of the confidence interval (e.g. 0.95), and return two outputs, the lower and upper boundaries of the confidence interval (e.g. 12.79 and 40.38), which is different from combining the results for the lower and upper tails (e.g. 12.40 and 39.36) as you have done.

Andrew


Andrew,

Quote:
The function would take two inputs, the number of degrees of freedom (e.g. 24) and the size of the confidence interval (e.g. 0.95), and return two outputs, the lower and upper boundaries of the confidence interval (e.g. 12.79 and 40.38) ...

IMHO the function needs the point estimator, too, so three inputs. Anyway, please explain how you get 12.79 and 40.38.

Walter

Edited: 8 Apr 2011, 5:41 a.m.


Walter,

Thanks for your patience.

Let me run you through the steps. I used Excel to calculate the values, so I'll use Excel functions in what follows.

1. We're seeking a 95% two-sided confidence interval, which implies that CHIDIST(a, 24) – CHIDIST(b, 24) = 0.95, where a and b are the values from which we'll calculate the upper and lower bounds of the confidence interval respectively.

2. There are an infinite number of pairs of values (a, b) that meet this criterion, so we need a further criterion by which to choose the best one. We do this by noting that S² is an unbiased estimator, i.e. E(S²) = sigma², because the mean of the chi-square distribution is equal to the number of its degrees of freedom (24 in this case). Consequently, we choose the best interval to be the one that is unbiased. The unbiased interval will be the one such that the integral from a to b of x.f(x).dx, where f(x) is the chi-square probability density function, is equal to the number of degrees of freedom of f(x). This is equivalent to the additional criterion that CHIDIST(a, 24 + 2) – CHIDIST(b, 24 + 2) = 0.95 (i.e. the number of degrees of freedom increases by 2).

As an aside, S² is the maximum-likelihood estimator of sigma², and the unbiased interval is also the interval of maximum likelihood.

3. Iteration using Excel yields a = 12.79 and b = 40.38.

4. Checking against our criteria yields:

CHIDIST(12.79, 24) – CHIDIST(40.38, 24) = 0.9695 – 0.0195 = 0.9500; and

CHIDIST(12.79, 26) – CHIDIST(40.38, 26) = 0.9858 – 0.0358 = 0.9500.

Note that calculating a and b does not depend on s², so a function to determine a and b would not require s² (12.5) as an input.

5. We can now calculate the upper and lower bounds of the confidence interval:

Upper bound = 24 * 12.5 / 12.79 = 23.45; and

Lower bound = 24 * 12.5 / 40.38 = 7.43.

Note that this step is the same as in the HP 50g User's Guide, except that the values are different.

Andrew


Andrew, can you provide a reference or link to this method that describes why it does what it does? It isn't obvious to me why adding two to the degrees of freedom results in centrality of the confidence interval you suggest or how it ties into the sample standard deviation. It isn't something I remember encountering during my degree in statistics years ago (not that that means much these days).


- Pauli


Paul,

I don't have a reference. I tried googling for one, but only papers in academic journals seem relevant, and they'e all behind paywalls. I'd have to do a proper literature search, but I'm not a student or faculty member. Maybe someone on the forum could help.

As for why adding two degrees of freedom results in an unbiased confidence interval, it's just a matter of integrating by parts. I'd be happy to write out the derivation (in LaTeX or by hand) and forward it to you, although it would have to wait until the end of the week.

Andrew


Andrew, please send me the derivation as well. TIA.

After all these suggestions concerning new functions to add (and existing ones that should be improved) I would like to hear if the community also thinks that certain functions are obsolete and can be removed. This might also free up some RAM (or keys) that might be used for other, more useful things.

Okay, I'll start the list:

  • The // function IMHO is too special and is of only very limited use - if it is really required it takes only a few key presses or a very short routine in program memory.
  • After my first look at the %+ and %- functions I wondered what kind of image the programmers might have of "those business guys" that might use these functions. #-) Let's face it: noone (yes: noone) needs a function that does nothing but [%] [+], saving one single key. The %MU function (buried deep down in the X.FCN menu, and therefore obviously not intended for everyday use) is obsolete as well since the delta-% function can do the same job.

    If a percent function really makes sense it should be implemented similar to the %+MG function: 100 [ENTER] 20 [function] should not return 80, but 16,67. Pressing [-] then gives 83,33. That's a useful function e.g. for calculating prices with and without VAT, returning both tax and net price. Currently this can also be accomplished by keying 100 [ENTER] -20 [%+MG] if (!) this useful function was directly accessible on the keyboard (e.g. instead of the useless %+ and %- functions). It also should leave the y-register unchanged (no stack drop), just like the standard %-function.

  • Once again, I would like to mention that I really would prefer an "A" key instead of the current Sigma+. Does anyone really use this function so extensively that a primary key is required? In my humble opinion f Sigma+ and g Sigma- are fine, while on the other hand I really miss an "A"-key.
What could be implemeted instead of these functions? A few suggestions:
  • I could not find a function that calculates the population standard deviation (only the sample SD). It it really missing?
  • A cube and cube root function, or more generally an XROOT function would be nice. Not just because it's more convenient to use but also because the numeric precision is better. And finally that's what a calculator is all about, isn't it ?-)
  • We had this discussion about useful display formats. I think there were some good points that deserve to be realized on the 34s.

Dieter


I would also be fine with killing the %+ and %- functions, FWIW.


OK, two votes are a qualified minority on this forum ;-)

How about placing H.MS+ and H.MS- at these h-shifted locations instead?

Walter


I'd certainly be ok with that. More useful, I would think! :-)

And, Walter... do you have a word document of the 34s owners manual rather than the PDF? If so, can I have it? I'd like to start thinking of making some introductory material for it.


Gene,

Thanks for your kind offer. How about you setting up what you want to include, and then sending me a little .doc-file? Will be easier this way IMHO - though I've many years experience in repairing confused MS WORD formatting, it's not sufficient yet to make me like this job ;-) No personal offence intended, of course - I've simply seen enough. TIA

Walter


My feeling now is that the existing manual assumes way too much on the previous knowledge of the user. I mean, I have been using HP scientifics and programming for a long time and it is tough for ME to read...much less someone with less experience.

I think it needs some introductory material surrounding it.

My thought was to take the existing word document and start modifying it to add such material.

Sending you a word document probably would not work, since I would be taking a completely different approach to trying to explain things than has been done so far. I would work to create a complementary document, not a replacement for the existing one or the one you guys create/update.

Example: The bottom of the first page of explanation is already talking about the -> function and how it operates. Imagine the HP 67 owners manual talking about P<>S or MERGE on the first page.

I think it assumes a lot. Room for making it more "idiot friendly" ... and I'm an expert on being an idiot.

My 2 cents and worth less than that.


Gene, all,

Thanks for your advise. I never thought of this little file becoming a stand-alone manual. It was designed to be an addition to the manuals of the 'parent calculators', mainly the HP-42S and HP-16C. This intention was always clearly stated in the header of the Index of Operations. This statement is still there, but due to a lot of text preceding this index now it went to page 24 in my copy. Presumably I shall pull it to the front again :-)

I acknowledged your point about -> and changed the basic example, taking the key 5 now instead.

Wherever you find similar stuff feel free to point it out. That was our intention in publishing the emulator and its manual: take your chance and stand up - yes you can change things here, more than elsewhere. We will not follow everything, however, since we've got our own ideas as well and want them becoming reality with our project we pursue for some 28 months so far. But we read carefully - most times ;-)

Walter

Is there a problem with Gene writing a user's guide? I'd like that I think.

Walter's manual is very impressive but, as mentioned, it really isn't for novice users. It is a complete reference manual and specifications document for the device.

I vote for two manuals. One introductory and novice friendly and the other containing all the exquisite details.


- Pauli


Quote:
I vote for two manuals. One introductory and novice friendly and the other containing all the exquisite details.

Should this thing make it to the real hardware and be relatively stable by HHC2011 conference time, that would be an excellent place for at least one "workshop"-type session on introducing wp34S to the "masses". If we could round up enough 20bs, maybe they could all be re-flashed prior to the event and handed out to attendees. Of course re-labeling the keys is still a problem to be tackled.

Jake

P.S. - HHC2011 is now firm in San Diego in September....see http://hhuc.us/2011/index.htm for details


Jake, I've an image running on my 20b. :-)

I's on SVN, so feel free to get it.

I could certainly write a manual on my own without any direct permission :-) but what I was hoping to do was to not have to start from scratch. There is a great deal of information in the existing technical summary manual thing, but it is quite overwhelming and needs a lot of flushing out and added explanations.

That's why I was hoping to get a word document of the manual...not to edit it and send it back to the developers as a change of the existing technical document, but to create a totally separate user's guide that made fewer assumptions about the reader.

Lacking that, I can try starting from scratch, but the joy factor will be less. :-)


Gene,

You can get a .docx-file if you are willing to sign a nonproliferation agreement. I don't want to see this file spread all over the world for various reasons. Please drop me a mail.

Walter

Walter, maybe there is an even better idea. ;-) Since %+ and %- are shifted functions of the Plus and Minus-key they are the perfect place for + and -. This would free up the key in the upper left corner and allow for a dedicated "A"-key (finally). Even with another useful default function, for instance LN.

The 34s has one row of keys less than the 41-series or the 35s so that actually every single mathematical function (except + - x /) is shifted. So the default key assignments of the top row really make sense. My proposal would allow for another often used function. Yes, and an "A"-key as well. ;-)

Dieter


Dieter, please see below ;-)

Quote:
  • I could not find a function that calculates the population standard deviation (only the sample SD). It it really missing?
  • A cube and cube root function, or more generally an XROOT function would be nice. Not just because it's more convenient to use but also because the numeric precision is better. And finally that's what a calculator is all about, isn't it ?-)
  • We had this discussion about useful display formats. I think there were some good points that deserve to be realized on the 34s.

In order:

  • Population standard deviation is a lower case sigma in the statistics catalogue.

  • Cube and cube root are in just not in the release yet. XROOT is a good suggestion.

  • I not keen on doing too much with the real number formatting code. It is a pretty horrible piece and changes are difficult. Still, the ideas presented have been good.


- Pauli


Just to keep you posted. I've downloaded a first image to my 20b. The results are still frustrating. I'm at a very early state...


Things are starting to get better. The debugger is operational and some functions on the hardware are already working. Obviously some aren't such as power saving or on/off. Progress is better than I was hoping. I'm confident that the upcoming release will contain a working ROM image.

Order your cables now!


Woohoo!

Exciting! Cable and 30B standing by!


Be brave! Use SVN to get the most recent flash image out of SourceFourge!


I went to the sourceforge link and the file seemed 10 days old.

What is the link to the most recent files?

I used SVN to get the latest, and there appears to be 2 *.bin files: calc.bin and calc2.bin - which to use?


calc.bin did not flash for me.
calc2.bin did flash to the device, but the LCD is entirely lit up, but calculator is not functioning!


calc2.bin is outdated, calc.bin is the one to use. Why doesn't it flash?

If the problems persist, I can copy the binary elsewhere.

Here is a direct link to the repository. I've removed the outdated versions. The file to use is calc.bin.

Edited: 10 Apr 2011, 2:46 p.m.


Sweet! I wasn't patient enough! It did flash with calc.bin. I am pressed for time at this moment, but will do a video of it in action!

Thank you to Pauli, Walter and Marcus - amazing!

Dieter,

Quote:
Once again, I would like to mention that I really would prefer an "A" key instead of the current Sigma+. Does anyone really use this function so extensively that a primary key is required? In my humble opinion f Sigma+ and g Sigma- are fine, while on the other hand I really miss an "A"-key.

Maybe you have told us already, but I don't remember: What do you want to do with an "A"-key?

Walter


My guess is that it just looks odd and feels odd to some of us to have a Binary Coded Decimal key layout (BCD ha), but to have Sigma+ taking the spot where the A key would be.

Is the location of Sigma+ at that top corner that sacrosanct or important to make B, C, and D be the default user defined keys? Could it be moved over to the D location and BCD become ABC?

Eh... I'll just be tickled to have firmware to load and play with. Great job guys.


I'm trying hard to get past the most basic power saving options which are essential if you don't want to replace two 2032s on a daily basis. I was a bit busy today with other things. So you'll probably have to wait some more days. Days, not weeks! :)

I propose to delegate the sigma+/- functions to where the percentages are now. This gets us an A key and another secondary function.

Regarding H.MS+/-, I'm thinking of a different approach: It would be nice if numbers where flagged to be H.MS or real. H.MS values are converted to reals on the fly before processing. This renders + and - to H.MS arithmetic keys.


Marcus wrote:

Quote:
I propose to delegate the sigma+/- functions to where the percentages are now. This gets us an A key and another secondary function.

Incredible! That's exactly what I wrote five minutes ago. Great! This way we once again have a "qualified minority" here. :-)

Dieter


Dieter,

You didn't answer my question yet. Please see above.

Walter


I felt another explanation was not necessary because the "A"-key was already eplained here. ;-)

Yes, the label keys in the top row (now "B", "C" and "D") are fine. But can you imagine a TI58/59, a HP65 or HP67 with a top row labelled
+ B C D ? Even my HP-34C has A and B, not B and C. ;-) Another advantage is the additional default function that can be assigned to this key as long as LBL A is not defined. As proposed in my earlier post. This idea (assign the Sigma-functions to h + and h - and use the key in the upper left corner as an "A"-key, working just as the B, C and D-keys) seems to be so obvious that Marcus and I had exactly the same idea here. :-)

Dieter


You may have read that Gene was guessing there. Thus I wanted the original author explaining what he's after ;-) Now we know.

IMHO it's not really logic but psychologic (i.e. the opposite). For sake of peace, however, I suggest the following for the top left and bottom right keys:

What do you think?

Walter


Nahmt, Walter -

Quote:
IMHO it's not really logic but psychologic (i.e. the opposite).

Life is far more than just logic. ;-)
Quote:
What do you think?

That's better. However I would prefer a more useful function as default for the A-key. For instance LN.

In my humble opinion the idea that Sigma+ should be on a primary key "because it's important for the statistics guys" in about as correct as "those business guys need a [%+] and [%-] function". ;-)

Maybe we should have another poll here. :-D

Dieter

Quote:
Regarding H.MS+/-, I'm thinking of a different approach: It would be nice if numbers where flagged to be H.MS or real. H.MS values are converted to reals on the fly before processing. This renders + and - to H.MS arithmetic keys.

No RAM clear to store the extra information unfortunately.
I'd love to tag numbers based on what they are: angle mode, units, etc.


- Pauli

Hi world ! ;)

We are running out of flash space in the moment. I therefore ask you to think about functions you don't need or you would like to swap against different ones.

It might be necessary to create a common ground wp34s where functions can be added from several groups by changing options during compile. The final release will then include different versions of the flash image. That's some logistic work and I really don't like it. We're working on some more space savings but I see limits to this approach. So be inventive, please!


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

Forum Jump: