astonishing recurrence



#55

Consider this definition of a sequence:




  • What's the limit?
  • Use your favorite calculator to find it.

Cheers

Thomas


PS: Find the solution in a paper of Prof. W. Kahan.

PPS: The other problems in this paper are worth reading as well.

Edited: 16 May 2013, 6:26 p.m.


#56

Very surprising result!

Here is my first quick HP48SX RPL Solution. Now I have to think about it ;-)

<< DUP2 1500 ROT / NEG 815 + SWAP / NEG 108 + >> 'XNEXT' STO

Put x0 and x1 on the stack. Then press 'XNEXT' each iteration.

x0  =  4
x1 = 4.25
x2 = 4.470588235
x3 = 4.644736835
x4 = 4.770538091
x5 = 4.855697516
x6 = 4.910781705
x7 = 4.944198104
x8 = 4.939880369
x9 = 4.43188497
x10 = -7.379556398
x11 = 172.57617998
x12 = 102.09962458
x13 = 100.102731135
x14 = 100.005128552
x15 = 100.000256332
x16 = 100.000012814
x17 = 100.000000641
x18 = 100.000000032
x19 = 100.000000002
x20 = 100
x21 = 100
:

Edited: 17 May 2013, 7:33 p.m. after one or more responses were posted


#57

Since I had my Casio fx-9860GII sitting on my desk (recommended by members of this forum for its backlight), I thought I would give it a try.

Interestingly, it gave different results if I entered the initial input value of 4.25 as a decimal, or if I entered it as a fraction. Otherwise the program was identical.


If I specify the initial variable as a decimal: 4.25

x0  =   4
x1 = 4.25
x2 = 4.470588235
x3 = 4.644736842
x4 = 4.770538244
x5 = 4.855700711
x6 = 4.910847469
x7 = 4.945536789
x8 = 4.966950156
x9 = 4.979795569
x10 = 4.982956917
x11 = 4.891981178
x12 = 2.935426196
x13 = -65.18635467
x14 = 112.6635673
x15 = 100.5618284
x16 = 100.0279291
x17 = 100.0013959

If, however I input the initial variable as a fraction: 4/1/4

x0  =   4
x1 = 4/1/4
x2 = 4/8/17
x3 = 4/49/76
x4 = 4/272/353
x5 = 4.855700713
x6 = 4.910847499
x7 = 4.945537404
x8 = 4.966962581
x9 = 4.980045686
x10 = 4.987979147
x11 = 4.992764238
x12 = 4.995534710
x13 = 4.994965516
x14 = 4.949870539
x15 = 4.017961989
x16 = -19.41827146
x17 = 130.7454029
x18 = 101.1756925
x19 = 100.0580991
x20 = 100.0029032

#58

To avoid potential problem of rounding, I use the 'exact mode' of the 50G :

'F(XP,X)=108-(815-(1500/XP))/X' DEFINE
<<
4 '17/4'
ROT 2 SWAP START
SWAP OVER F EVAL
NEXT
NIP DUP ->NUM
>>
'Calc' STO

21 Calc

'1192108586037617
/238423809278164'
~ 4.99995612707.

100 Calc

'19721522630525295135293987198350753758826715569420223551166026427884564
/3944304526105059027058900515174297154031550406109997834487745707081313'
~ 4.9999999999

But
200 Calc
~ 5.0000...2

400 Calc
~ 5.00000...1

In approx mode I got the same 'false' results of Michael


Edited: 17 May 2013, 9:07 a.m.


#59

Quote:
To avoid potential problem of rounding, I use the 'exact mode' of the 50G

Great idea! The recurrence has been set up to collapse under finite precision, no matter the number of digit. Even the wp34s in double precision eventually fails on that one:

ADDR  OPCODE     MNEMONIC

0001: 6264 LBL A
0002: 0009 4
0003: 010c FILL
0004: 020b 1/x
0005: 0301 +
0006: a70f # 015
0007: 9102 SDL 002
0008: 0000 ENTER[^]
0009: 0283 [degree]F[->][degree]C
000a: 0204 IP
000b: 3165 x[<->] Y
000c: 2e67 RCL/ T
000d: 0302 -
000e: 2e65 RCL/ Y
000f: 0003 +/-
0010: a76c # 108
0011: 0301 +
0012: 013b STOP
0013: 570d BACK 013
0014: 013a END

Keystroke Display
A 4.47058823529
R/S 4.64473684211
R/S 4.77053824363
R/S 4.85570071259
R/S 4.91084749908
R/S 4.94553740412
R/S 4.96696258176
R/S 4.98004570136
R/S 4.98004570136
R/S 4.99277028806
R/S 4.99565589151
R/S 4.99739126838
R/S 4.99843394394
R/S 4.99906007197
R/S 4.99943593715
R/S 4.99966152411
R/S 4.99979690075
R/S 4.99987813614
R/S 4.99992689282
R/S 4.99995639343
R/S 4.99997900336
R/S 5.00009075297
R/S 5.00212143356
R/S 5.04259444308
R/S 5.84480234426
R/S 19.4539639556
R/S 79.2983058468
R/S 98.6946953822
R/S 99.9338716019
R/S 99.9966913925
R/S 99.9998345642
R/S 99.9999917282
R/S 99.9999995864
R/S 99.9999999793
R/S 99.9999999990
R/S 99.9999999999
R/S 100.000000000
R/S 100.000000000


#60

Gerson, a good example of compactness versus readability. ;)

Does the series move away from 5 as soon as the value goes beyond that threshold? It seems to converge versus 5 as long as the values stay below 5.


#61

It doesn't move away from 5 once the value is greater than 5. For many inputs e.g. 1 and 3, it moves away immediately. The solution at 5 has to be approached along a very specific path to be found and any deviation will result in the solution at 100. The initial values were carefully chosen to be on the path. Even if you are on the path to 5, convergence is slow.

A slightly shorter program for this is:

	001:	LBL A
002: # 015
003: SDL 002
004: RCL/ Z
005: 8
006: 1
007: 5
008: -
009: RCL/ Y
010: # 108
011: +
012: R/S
013: GTO A

However, it is missing the inspired use of oF->oC command.


- Pauli


#62

Quote:
Even if you are on the path to 5, convergence is slow.

It's geometric with the factor 3/5. What do you consider slow?

Kind regards

Thomas


#63

The convergence certainly isn't fast.


- Pauli


#64

From Gilles post for N = 100:

Quote:
19721522630525295135293987198350753758826715569420223551166026427884564
/3944304526105059027058900515174297154031550406109997834487745707081313

WolframAlpha gives the following result:
4.9999999999999999999998693362...

But since (3/5)55 < 10-12 I assume about 55 elements should be enough. I agree with you that it's not super fast but still much better than the brute force summation of 1/k2 in a recent thread. We could also use convergence acceleration to improve on the result.

Kind regards

Thomas

#65

Compared to this?

STO 0
x<>y
RCL 3
x<>y
/
RCL- 2
RCL/ 0
RCL+ 1

108 STO 1
815 STO 2
1500 STO 3

4 ENTER
4.25 R/S
R/S
R/S
...


You can get a good visualisation of the dynamic of this sequence if you combine two succesive elements to a vektor zn = [ xn, xn+1 ]. If you follow the example in Kahan's paper and calculate the eigenvalues of the Jacobian matrix of first partial derivatives of F at the fixed-point [5, 5], you'll get 20 and 3/5. The corresponding eigenvectors are [20, 1] and [3/5, 1]. The first defines the direction that is repellant while the second is attractive. From that graph it should be obvious that there is as well a sequence converging to 5 with values bigger than 5. You may start with [8, 6.125].

Cheers

Thomas

Edited: 18 May 2013, 8:53 a.m.

#66

Quote:
a good example of compactness versus readability.

Perhaps not a good example of compactness, but surely an example of unreadability, absolutely not necessary for the WP-34S :-)
These kind of tricks were important on the HP-32SII, which had only 384 bytes of RAM. Program A is neither compact nor readable, but it is 4 bytes shorter than program B*. The results match Michael Kathke's ones for the HP-48SX, as we would expect:

A01 LBL A			B01 LBL B
A02 163 B02 815
A03 5 B03 1500
A04 * B04 R^
A05 ENTER B05 /
A06 ->oF B06 +/-
A07 SQRT B07 +
A08 ASINH B08 x<>y
A09 COSH B09 /
A10 x2 B10 +/-
A11 IP B11 108
A12 R^ B12 +
A13 / B13 STOP
A14 +/- B14 GTO B
A15 +
A16 x<>y
A17 /
A18 +/-
A19 108
A20 +
A21 STOP
A22 GTO A

CK=09CA 033.0 bytes CK=0A7B 037.0 bytes

4 ENTER 4.25 XEQ A 4 ENTER 4.25 XEQ B 4.470588235
R/S 4.644736835
R/S 4.770538091
R/S 4.855697516
R/S 4.910781705
R/S 4.944198104
R/S 4.939880369
R/S 4.43188497
R/S -7.379556398
R/S 172.57617998
R/S 102.09962458
R/S 100.102731135
R/S 100.005128552
R/S 100.000256332
R/S 100.000012814
R/S 100.000000641
R/S 100.000000032
R/S 100.000000002
R/S 100
R/S 100

* These can be further optmized, of course. We can save at least 5 bytes in program B, for example.

Edited: 18 May 2013, 4:26 p.m.

#67

Quote:
To avoid potential problem of rounding, I use the 'exact mode' of the 50G :
...

The 50g has an exact mode? Interesting. The only follow up to my 48SX was the 49g. I dislike the hardware, put him into the drawer and go back to my 48SX. ;-) Let's see what HP offers next.

Today I stick the keyboard stickers to build up the WP 34S. Now I have to solder some things and so on...


#68

Quote:
The 50g has an exact mode? Interesting. The only follow up to my 48SX was the 49g.

Yes, and so does the 49g.

#69

The 49G+ and 50G hardware is far better than the 49G (keyboard, screen speed etc.)

The 49G hardware was ...:(

When I try sometimes tu use my old 48SX I love the keyboard touch (but not the agencement except the big ENTER), but it's so slow and the screen is poor...

Edited: 20 May 2013, 6:59 a.m.

#70

The TI-Nspire CAS goes off the rails fairly quickly in approximate mode. It does have a handy function for generating sequences, however.

Approximate:

seqGen(108-((815-((1500)/(u(n-2))))/(u(n-1))),n,u,{2,20},{4,4.25})
Exact:
(seqGen(108-((815-((1500)/(u(n-2))))/(u(n-1))),n,u,{2,70},{4,((17)/(4))}))->Decimal
        Approximate                        Exact
x0 4.0000000000000 4.0000000000000
x1 4.2500000000000 4.2500000000000
x2 4.4705882352900 4.4705882352941
x3 4.6447368420100 4.6447368421053
x4 4.7705382415800 4.7705382436261
x5 4.8557006697400 4.8557007125891
x6 4.9108466171500 4.9108474990828
x7 4.9455194518000 4.9455374041239
x8 4.9665996618000 4.9669625817627
x9 4.9727394954100 4.9800457013556
x10 4.8410665463200 4.9879794484784
x11 1.9582015026800 4.9927702880621
x12 -149.96677335313 4.9956558915066
x13 108.3266789440700 4.9973912683813
x14 100.3841271269200 4.9984339439448
x15 100.0191267431500 4.9990600719709
x16 100.0009559707500 4.9994359371468
x17 100.0000477925700 4.9996615241038
x18 100.0000023894600 4.9997969007134
x19 4.9998781354779
x20 4.9999268795046
x21 4.9999561270612
x22 4.9999736760057
x23 4.9999842055203
x24 4.9999905232822
x25 4.9999943139586
x26 4.9999965883713
x27 4.9999979530214
x28 4.9999987718123
x29 4.9999992630872
x30 4.9999995578523
x31 4.9999997347113
x32 4.9999998408268
x33 4.9999999044961
x34 4.9999999426976
x35 4.9999999656186
x36 4.9999999793712
x37 4.9999999876227
x38 4.9999999925736
x39 4.9999999955442
x40 4.9999999973265
x41 4.9999999983959
x42 4.9999999990375
x43 4.9999999994225
x44 4.9999999996535
x45 4.9999999997921
x46 4.9999999998753
x47 4.9999999999252
x48 4.9999999999551
x49 4.9999999999731
x50 4.9999999999838
x51 4.9999999999903
x52 4.9999999999942
x53 4.9999999999965
x54 4.9999999999979
x55 4.9999999999987
x56 4.9999999999992
x57 4.9999999999996
x58 4.9999999999997
x59 4.9999999999998
x60 4.9999999999999
x61 4.9999999999999
x62 5.0000000000000
x63 5.0000000000000
x64 5.0000000000000
x65 5.0000000000000
x66 5.0000000000000
x67 5.0000000000000
x68 5.0000000000000


#71

Is it possible to define a sequence based on an other sequence? So could you define a sequence a(n) that uses u(n), u(n+1) and u(n+2) in the definition? Because then you could use Aitken's delta-squared process to get a sequence that converges much faster:

Kind regards

Thomas

PS: You really have to enter ((17)/(4)) to make it exact? That's a strange syntax.


#72

It does look like Aitken's process will converge much more quickly. (I used, in this case, the spreadsheet feature, rather than nested sequences.) The results are:

          Exact               Aitken
x0 4. 6.1249999997025
x1 4.25 5.2977941178822
x2 4.47058823529 5.0978786250754
x3 4.64473684211 5.0341661805942
x4 4.77053824363 5.0121668031825
x5 4.85570071259 5.0043630620932
x6 4.91084749908 5.0015685124445
x7 4.94553740412 5.0005643812327
x8 4.96696258176 5.0002031404805
x9 4.98004570136 5.0000731259183
x10 4.98797944848 5.000026324821
x11 4.99277028806 5.0000094772632
x12 4.99565589151 5.0000034127263
x13 4.99739126838 5.0000012291514
x14 4.99843394394 5.0000004435337
x15 4.99906007197 5.0000001597038
x16 4.99943593715 5.000000055426
x17 4.9996615241 5.00000001847
x18 4.99979690071 5.
...
Unfortunately, TI makes extracting your work pretty painful, including, it appears, adding some unnecessary parentheses. This, unfortunately, turned 17/4 into (17)/(4).

#73

Thanks for taking the time to create the table, the more so as it was a pain to extract the data from the calculator.

Cheers

Thomas

#74

Can Aitken's process save the WP-34S in double precision mode?

         Double Precision  Aitken      
x0 4. 6.125
x1 4.25 5.29779411765
x2 4.47058823529 5.09787862513
x3 4.64473684211 5.03416618064
x4 4.77053824363 5.01216680321
x5 4.85570071259 5.00436306211
x6 4.91084749908 5.00156851243
x7 4.94553740412 5.0005643812
x8 4.96696258176 5.00020314054
x9 4.98004570136 5.00007312584
x10 4.98797944848 5.00002632469
x11 4.99277028806 5.00000947681
x12 4.99565589151 5.00000341164
x13 4.99739126838 5.00000122819
x14 4.99843394394 5.00000044215
x15 4.99906007197 5.00000015918
x16 4.99943593715 5.0000000575
x17 4.99966152411 5.00000002455
x18 4.99979690075 5.00000008579
x19 4.99987813614 5.00000158881
x20 4.99992689282 5.00005319189
x21 4.99995639343 4.99995065851
x22 4.99997900336 4.99997249558
x23 5.00009075297 4.99998348415
x24 5.00212143356 4.99997099445
x25 5.04259444308 4.99234537283
x26 5.84480234426 1.83899380969
x27 19.4539639556 107.996029692
x28 79.2983058468 100.018441722
x29 98.6946953822 100.000046095
x30 99.9338716019 100.000000115

#75

The result doesn't really surprise as the difference from the correct sequence is multiplied by 100 with each step. So if the base sequence deviates from the correct solution the accelerated sequence can't do much about it.

Let's assume that the sequence is: xn = a + c qn with |q| < 1. Then the limit is certainly a as n goes to infinity. When Aitken's process is applied to that sequence we get the correct limit a with the first step using just the first three elements of the original sequence:x0, x1 and x2.

Now our correct sequence is something like: xn = a + c 1 q1n + c2 q2n, with q1 = 3/5, q2 = 100 and c2 = 0. Due to rounding errors the second factor c2 isn't 0 anymore but a very small number. However this term gets blown up as n grows. When it gets dominant the Aitken's process uses this factor q2 = 100 instead of q1 = 3/5 to guess the limit. That's why we can observe an acceleration of the convergence to the limit 100 after x27.

Cheers

Thomas

#76

Quote:
PS: Find the solution in a paper of Prof. W. Kahan.


Well, this is some of the most interesting material I've read in a while. Thanks!

I've always been fascinated by the field of numerical analysis, and by one of its top mathematicians...the famous Dr. William Kahan. There is a 1997 DDJ interview with Dr. Kahan that is a short but enjoyable read.

#77

Could someone verify the N=6 case in the HP-97 column on page 2 of Kahan's paper? I don't have a 67/97 but neither my 19C nor 15C produce quite that value, though they agree with each other. They also agree with (most of) the succeeding values so I'm tempted to think it's a typo.

I'm also getting a discrepancy for N=9, but I'm willing to chalk this one to rounding/truncating.

I realize the point of the exercise is to demonstrate getting incorrect results, but I thought the 67/97 did arithmetic the same as the 19C/15C.


#78

Yes, it's a typo. Both the emulator RPN-67 Pro (with "Enhanced Calculator" set to Off) and a real HP-67 return 5.745 for N=6 and -18.74 for N=9.

#79

Good catch! I can confirm your observations using the HP-15C as I get:

N     xN        PREFIX
6 5.745 5745352800
9 -18.74 1873570590
I share your conclusions: probably a typo.

Kind regards

Thomas

#80

Looking at the formula you can see that the limit is 100. Excel confirms that!

If you change the first two values you should still get 100 as the limit.

I found an exception!! If the fist two values are 5, you get 5 as the limit.

Namir


Edited: 18 May 2013, 1:45 a.m.


#81

And 3, 3 yields 3. A plot of the function obtained by replacing all three x-values in the recurrence with the symbol x shows zeros at 3, 5, and 100.


#82

Hello Calc-Friends,

If you suppose existing limits, then you can set X=X_n=X_n-1=X_n-2 and you get an third grade equation which can be written as:

X^3 - 108X^2 + 815X -1500 = 0

and the hp 50 can this easily factorize to

(X-100)(X-5)(X-3) = 0.

There you have the three fixpoints. The recurrence is very unstable because of the difference.

greetings

peaceglue

Edited: 18 May 2013, 3:59 a.m.


#83

Quote:
The recurrence is very unstable because of the difference.

The recurrence isn't unstable per se as 100 is an attractive fixed point. However this specific sequence is prone to rounding errors as it converges to a hyperbolic fixed point (saddle point).

Cheers

Thomas

#84

Very good analysis!!!

:-)

Namir

#85

Quote:
an third grade equation

I think you mean "cubic"

At least I wasn't solving these when I was in third grade!


#86

Quote:
Quote:
an third grade equation

I think you mean "cubic"


Just for curiosity: How'd you call an equation going up to x^4 ? And to x^5 ? Thanks in advance for enlightenment.

d:-?


#87

Quartic; quintic.

#88

Quote:
How'd you call an equation going up to x^4 ? And to x^5 ?

Biquadratic, quartic. Quintic.

I think the point here is the use of "grade" for "degree". The former shouldn't be wrong, but it appears the latter is more common in English. I don't know what it's like in German, but in Portuguese we have only one word for both words: grau. Interestingly ensino de terceiro grau means "college-level education". Also, colégio means "high-school", not college. These are often mistranslated. In this example, for instance, "And I only got a third grade education" has been translated as "E eu só tenho uma educação de terceiro grau" (And I have only a college-level education), which causes perplexity: "Isn't that enough?" (In this corner of the world, it still is :-).

Regards,

Gerson.


#89

Quote:
I think the point here is the use of "grade" for "degree".

These are possible translations of the german word
Grad (as suggested by dict.cc):
  • rank
  • rate
  • grade
  • level
  • order
  • stage
  • standard
  • degree
Sometimes or often we choose a false friend.

Thomas

#90

Quote:
Looking at the formula you can see that the limit is 100. Excel confirms that!

What you probably mean is that 100 is a fixed point. But that doesn't make it the limit of the sequence. Just have a look at Gilles results using the HP-50g in exact mode.

Quote:
If the fist two values are 5, you get 5 as the limit.

The same happens for the given initial values. But the path starting from there is very prone to rounding errors. As soon as you miss the exact path only a little the sequence converges to 100.

Cheers

Thomas

PS: All the math is in Kahan's paper.


#91

Very interesting stuff to me. I've heard about in theory but never really touched it. These days I am diving into parallel-computing and CUDA it would help a lot.

The Wikipedia article about floating point has some useful links and google ;-)

- Handbook of Floating-Point Arithmetic (Jean-Michel Muller, et.al)

- Elementary Functions - Algorithms and Implementation (Jean-Michel Muller)

- What Every Computer Scientist Should Know About Floating-Point Arithmetic (David Goldberg)

- Pitfalls in Computation, or why a Math Book isn't Enough (George E. Forsythe)

- ...

PS: Here is another one:

 x(n+1) = n * x(n) - 1 with x(0) = e-1  <- this was wrong. Sorry!

x(0) = e - 1
x(n) = n * x(n-1) - 1

What's the limit? ;-)


Edited: 20 May 2013, 5:10 p.m. after one or more responses were posted


#92

Hello Michael,

there's no limit:

the first values are:

n=0  e-1
1 -1
2 -2
3 -5
4 -16
5 -65
6 -326

and so on....where is the problem?

Greetings
peacecalc

#93

But using Free42 the sequence first approaches 0 but then all of sudden turns negative and seems to diverge.

Kind regards

Thomas


#94

Hello Thomas,

now I understand (I hope), it is a problem of the calcs and not
of mathematics.

Greetings
peacecalc


#95

I was lazy and just copied the definition of the sequence into WolframAlpha. But we can solve the problem without that. A nested series for e can be obtained by factoring out 1/n:

In this form it's obvious what the sequence does with e:
peeling off one factor after the other. What's left in each step is something like: 1/n * (1 + ...) which will tend to 0 as n goes to infinity.

The problem here is that we can't start with the exact value of e. Therefore I assume even the HP-50g in exact mode will run into problems.

I'm not sure wether I understand your statement correctly but I think the problem is more of how we interpret the results of our calculators.

Kind regards

Thomas


#96

Hello Thomas,

I'm not quite sure if we are talking about the same problem, I refer to

x(0) = e - 1
x(n) = n * x(n-1) - 1

in the original post #30 from Michael Kathke (with correction).

In my opinion this recurrence can be written in a closed forn as:

X(N+1) = - SUMME(J;1;N;GAMMA(N)/GAMMA(N-J+1));

It reproduces the values I gave above, and there is no limit because every term of the sum is greater 1 and for N to infinity you get a lot of summands. The starting value is irrelevant because, if you calculate X(1) the starting value is multiplied with zero.

Please give me a hint, where my misunderstanding is?

Greetings
peacecalc


#97

I'd like to rewrite Michael Kathke's first (wrong) definition of the sequence by replacing n by n-1:

x(0) = e-1
x(n) = (n-1) * x(n-1) - 1

Your listing of the sequence is correct. WolframAlpha gave me a closed formula for your expression:

 - SUM[GAMMA(N)/GAMMA(N-J+1),{J,1,N}] =
-(e Gamma(N+1, 1)-1)/N
Only with this formula I was able to create a table:
Table[-(e Gamma(n+1, 1)-1)/n, {n, 1, 6}]
This agrees with your result: {-1, -2, -5, -16, -65, -326}

This is the definition of the sequence after the correction:
x(0) = e - 1
x(n) = n * x(n-1) - 1
Can you spot the difference? The factor is now n instead of (n-1). This sequence has limit 0.

Hopefully I could clarify things a little.

Thomas


#98

Hello Thomas,

thank you very much for sharing your knowledge and time with me.

Now I can see clearly now (@Johnny Nash ;-)). It's my mistake to suppose that n can be zero (which isn't possible, because the first element should be then X_(-1) and not X_0). Oh boy, I should first read exactly before I'm steeling other persons time and further investments.

Greetings
peacecalc

Edited: 20 May 2013, 4:11 a.m.

#99

Yes, that's right. Thank you for the clarification and sorry for the little mess ;-).

Hello Thomas,

I only like to report that you are right with your statement:

"The problem here is that we can't start with the exact value of e. Therefore I assume even the HP-50g in exact mode will run into problems."

As long as you don't leave the exakt modus, the terms of recurrence are calculated right (output in the form: A*e - B, A and B are integers). One gets false values (after the twelfth step) if one puts ->NUM on the whole difference. If you type: A*e ->NUM B ->NUM - you get certainly the right answer: 0,0000.

Greetings
peacecalc

Quote:
Use your favorite calculator to find it.

I tried this on the 39gII using the Sequence app. It choked. Seems to half-draw the screen and then hangs. I had to take the batteries out to recover. :-(


Screenshot:




(Note: If you are trying to reproduce this, I had Fibonacci in U1 and Kahan's sequence in U2)

Trying the same using the 40GS it takes a few minutes to come up with "UNDEF" as the value of the 3rd item in the sequence. It then takes another few minutes to come up with "UNDEF" for item 4 and so on. :-)

A suggestion for TW:- the soft key menu when entering a formula should be:

"(N-2) (N-1) (N) U1 CANCL ON" and not "(N-2) (N-1) N U1 CANCL ON" i.e. put brackets around the N when pressed. (These will have no effect if N is what is required but saves typing when U1(N) is required.)


Apparently the 39gII is not among my favorite calculators and probably never will be. Seriously, are these calculators only capable to solve simple problems that are expected in the context of education? IMHO that sounds really bad.

Kind regards

Thomas

Bruce,

What happened to your calculator? The lower right part of it on your picture looks quite bent :-( Or is it the camera?

@Thomas: I'd vote for "obviously" instead of "apparently".

d;-?


It's just lens distortion. I tried to take the picture from a more overhead position but just got a reflection of the camera in the screen.

Here is what I get with my 39GII and how to to

1/push APPS and choose 'Suite' (in french)

2/ Enter :

3/ Push PLOT if you want to see the graph :

4/ Push NUM if you want to see the value

I think it's well done but it is not stable and I also experimented some bad crashs both on real calc and emulator...

As you can see, the numeric output is quite the same than many others HP Calcs

Edited: 20 May 2013, 8:14 a.m.

Hi Bruce !

Your HP39GII don't have to crash with this but there is a bug that I saw in the picture ...

U2(N)=...U2(N)...

You may use
U2(N)= function of U2(N-1), U2(N-2)

else you have a kind of recursive call without any exit and the 39GII crash...

Edited: 20 May 2013, 10:39 a.m.


Hi Gilles,

You are exactly right - I entered the expression wrongly. (D'oh). Once corrected, the physical calc gives the same results you posted from the emulator.

However, this episode has revealed a bug: the 40GS results that I quoted were also with the wrong expression - so the older model is able to cope with a recursive use of 'U1(N)' without crashing or hanging. It also allows me to interrupt the slow calculation with On+F3 which I couldn't get to work on the 39gII.

So, I withdraw my previous suggestion to Tim around changing the "N" menu item to "(N)" (as that simply encourages idiots like me to make make idiotic mistakes) ;-) and instead suggest that any entered expression be parsed for 'U1(N)' and a warning displayed if present.


Or just add support to break from a recursion loop (or any other situation that crashes the calc).

(I wasn't able to break from an intentional recursion loop on the emulator, and it was FAR from running out of memory.)


Possibly Related Threads…
Thread Author Replies Views Last Post
  Astonishing ! Michael de Estrada 11 3,495 06-08-2012, 09:49 PM
Last Post: Randy

Forum Jump: