wp34s - FIB problem (DBLON)

[Gerson W. Barbosa]

That's a minor problem, actually. In double precision mode FIB returns a near-integer for most arguments. For example:

     10 FIB --> 54.99999999999999999999999999999995

A simple workaround is

10 FIB CEIL --> 55

I found it when computing the Reciprocal Fibonacci constant on the wp34s:

0001 **LBL A
0002 RCL X
0003 # 002
0004 MOD
0005 STO+ X
0006 DEC X
0007 # 000
0008 ENTER[^]
0009 STOS 00
0010 R[^]
0011 FIB
0012 RCL L
0013 INC X
0014 FIB
0015 RCL 03
0016 STO+ X
0017 INC X
0018 FIB
0019 RCL L
0020 INC X
0021 FIB
0022 RCL- 02
0023 STOS 04
0024 **LBL 000
0025 RCL 07
0026 1/x
0027 STO+ 00
0028 RCL L
0029 STO- 06
0030 x[<->] 06
0031 STO 07
0032 RCL L
0033 x[^2]
0034 RCL[times] 02
0035 RCL 05
0036 RCL+ 01
0037 STO/ Y
0038 y[<->] 01
0039 RCL L
0040 STO- 04
0041 x[<->] 04
0042 STO 05
0043 DSE 03
0044 GTO 000
0045 RCL+ 01
0046 1/x
0047 RCL+ 00
0048 END

In theory 9 iterations would have sufficed for correct 34 significant digits, but the last three digits went wrong:

9 A --> 3.359885666243177553172011302918861

After CEILing and a few necessary changes, the program gets all of them right:

        3.359885666243177553172011302918927

[Paul Dale]

FIB takes real arguments in addition to integers so CEIL isn't a general solution.


Pauli

[ijabbott]

(11-22-2018 07:59 PM)Gerson W. Barbosa Wrote:  That's a minor problem, actually. In double precision mode FIB returns a near-integer for most arguments. For example:

     10 FIB --> 54.99999999999999999999999999999995

A simple workaround is

10 FIB CEIL --> 55

Is it possible for the result of FIB (for a whole number) to be slightly larger than a whole number? If so, ROUNDI would be better than CEIL here.

[Gerson W. Barbosa]

(11-23-2018 08:08 AM)ijabbott Wrote:  

(11-22-2018 07:59 PM)Gerson W. Barbosa Wrote:  That's a minor problem, actually. In double precision mode FIB returns a near-integer for most arguments. For example:

     10 FIB --> 54.99999999999999999999999999999995

A simple workaround is

10 FIB CEIL --> 55

Is it possible for the result of FIB (for a whole number) to be slightly larger than a whole number? If so, ROUNDI would be better than CEIL here.

I'd examined FIB(23) down to FIB(1) prior to choosing CEIL, but you're right, ROUNDI is a safer alternative.

Here's my modified program:

0001 **LBL A
0002 RCL X
0003 # 002
0004 MOD
0005 STO+ X
0006 DEC X
0007 # 000
0008 ENTER[^]
0009 STOS 00
0010 R[^]
0011 FIB
0012 CEIL
0013 RCL 03
0014 INC X
0015 FIB
0016 CEIL
0017 RCL 03
0018 STO+ X
0019 INC X
0020 RCL X
0021 FIB
0022 CEIL
0023 x[<->] Y
0024 INC X
0025 FIB
0026 CEIL
0027 RCL- 02
0028 STOS 04
0029 **LBL 000
0030 RCL 07
0031 1/x
0032 STO+ 00
0033 RCL L
0034 STO- 06
0035 x[<->] 06
0036 STO 07
0037 RCL L
0038 x[^2]
0039 RCL[times] 02
0040 RCL 05
0041 RCL+ 01
0042 STO/ Y
0043 y[<->] 01
0044 RCL L
0045 STO- 04
0046 x[<->] 04
0047 STO 05
0048 DSE 03
0049 GTO 000
0050 RCL+ 01
0051 1/x
0052 RCL+ 00
0053 END

9 A --> 3.359885666243177553172011302918927

[Gerson W. Barbosa]

(11-23-2018 03:23 AM)Paul Dale Wrote:  FIB takes real arguments in addition to integers so CEIL isn't a general solution.

From Walter's Blue Book, page 223 of 244:

"In DECM, FIB returns the extended Fibonacci number"

So the only problem is it is not accurate enough in double precision mode for certain applications. Well, not really a problem once we are aware of that.

Gerson.

[Paul Dale]

(11-23-2018 10:45 AM)Gerson W. Barbosa Wrote:  So the only problem is it is not accurate enough in double precision mode for certain applications. Well, not really a problem once we are aware of that.

We deliberately made no guarantees about accuracy in double precision. That the FIB function is in XROM and working at double precision pretty much guarantees it will be off in the last place or so. Flash was full so I had to pull the C implementation that worked in higher precision.

I agree ROUNDI is better for your purposes.


Pauli

[Gerson W. Barbosa]

(11-24-2018 08:37 PM)Paul Dale Wrote:  

(11-23-2018 10:45 AM)Gerson W. Barbosa Wrote:  So the only problem is it is not accurate enough in double precision mode for certain applications. Well, not really a problem once we are aware of that.

We deliberately made no guarantees about accuracy in double precision. That the FIB function is in XROM and working at double precision pretty much guarantees it will be off in the last place or so. Flash was full so I had to pull the C implementation that worked in higher precision.

I agree ROUNDI is better for your purposes.

The accuracy of the FIB function in double precision is indeed very good. By "not accurate enough" I meant it failed giving the exact integer results I expected for integer arguments. I am sorry I haven't made myself clear about that.

Gerson.

[Gerson W. Barbosa]

Just a size-optimized version, without forcing integer results for FIB in double precision mode. As a result this will never get the last two or three digits right.

Code:


001:LBL A
002:RCL X
003:DEC X
004:(-1)ᵡ
005:RCL L
006:FIB
007:RCL Z
008:FIB
009:STOS 01
010:# 000
011:RCL 04
012:STO+ X
013:©STO 05
014:INC 05
015:FIB
016:RCL- 03
017:RCL 05
018:FIB
019:STO 05
020:RCL+ 06
021:RCL× 03
022:RCL 01
023:1/x
024:STO+ T
025:x⇆ L
026:x²
027:RCL/ Y
028:STO 06
029:©x⇆ 01
030:RCL- Y
031:x⇆ Y
032:©STO 01
033:⇆ ZZTX
034:y⇆ 05
035:STO- Y
036:DSE 04
037:BACK 018
038:RCL+ 06
039:1/x
040:RCL+ Z
041:END