Foating point bug

Post here to share useful tips and tricks, to ask questions about using your DM42 or to report software-related problems
Post Reply
User avatar
pica
Posts: 70
Joined: Fri Mar 30, 2018 11:36 am
Location: Eswatini

Foating point bug

Post by pica »

Yesterday my DM42, running FW version 3.10 hung up a couple of times within about 15 minutes, after running flawlessly for many weeks.
I then went online and upgraded to version 3.11 and the problem has not re-occurred.
I also found out about the issue with the newer version of the Intel floating point library.
I was playing with the PRF (Prime factor) program (Pfactor.raw), doing things like PRF (N! + 1), looking for big primes.

I wonder if dividing very big integers by big primes is one way of highlighting the problem, as this possibly tests the floating point library in an unusual way. I don't remember exactly which number N was, but I suspect somewhere between 17 and 25.

The error message each time was "Reset in protected area. Reg ID d3770103, fw 3.10"

On another tack, is this the right place to report error codes?

I can't backtrace where I got the program from, it could even have been preloaded in the DM42 flash disk, but here is the listing.

Code: Select all

00 { 235-Byte Prgm }
01▸LBL "PRF"
02 SIGN
03 STO 06
04 X<>Y
05 STO 05
06 LASTX
07 ENTER
08 STO 04
09 6
10 STO 03
11 4
12 STO 02
13 -
14 STO 01
15 FIX 00
16 CF 29
17 CLA
18 ARCL ST Y
19 "~="
20 MOD
21 X=0?
22 XEQ 02
23 CLX
24 3
25 MOD
26 X=0?
27 XEQ 02
28 CLX
29 5
30 MOD
31 X=0?
32 XEQ 02
33 SIGN
34 SIGN
35▸LBL 01
36 X<> ST L
37 RCL 03
38 +
39 MOD
40 X=0?
41 XEQ 02
42 X<> ST L
43 RCL 02
44 +
45 MOD
46 X=0?
47 XEQ 02
48 X<> ST L
49 RCL 01
50 +
51 MOD
52 X=0?
53 XEQ 02
54 X<> ST L
55 RCL 02
56 +
57 MOD
58 X=0?
59 XEQ 02
60 X<> ST L
61 RCL 01
62 +
63 MOD
64 X=0?
65 XEQ 02
66 X<> ST L
67 RCL 02
68 +
69 MOD
70 X=0?
71 XEQ 02
72 X<> ST L
73 RCL 03
74 +
75 MOD
76 X=0?
77 XEQ 02
78 X<> ST L
79 RCL 01
80 +
81 MOD
82 X=0?
83 XEQ 02
84 X<> ST L
85 X↑2
86 X<Y?
87 GTO 01
88 SIGN
89 X=Y?
90 GTO 05
91 X<>Y
92 ARCL ST X
93 "~↑1"
94 STO÷ 04
95 DSE ST X
96 STO× 04
97 R↑
98 RCL 05
99 Y↑X
100 1
101 +
102 STO× 06
103 AVIEW
104 GTO 05
105▸LBL 02
106 STO 00
107▸LBL 03
108 ISG 00
109 CLX
110 X<> ST L
111 STO÷ ST Y
112 STO÷ ST Z
113 STO÷ ST T
114 MOD
115 X=0?
116 GTO 03
117 ARCL ST L
118 "~↑"
119 ARCL 00
120 X<> ST L
121 STO÷ 04
122 SIGN
123 X≠Y?
124 "~*"
125 CLX
126 LASTX
127 DSE ST X
128 STO× 04
129 X<> ST L
130 STO 07
131 RCL 05
132 Y↑X
133 SIGN
134 STO 08
135▸LBL 04
136 LASTX
137 ×
138 STO+ 08
139 DSE 00
140 GTO 04
141 X<> 08
142 STO× 06
143 X<> 07
144 SIGN
145 AVIEW
146 RTN
147▸LBL 05
148 FIX 04
149 SF 29
150 RCL 04
151 RCL 60
152 END
HP50G HP35s Free42 DM42.
Testing WP43S, C43.
grsbanks
Posts: 1122
Joined: Tue Apr 25, 2017 11:23 am
Location: Preston, Lancs, UK
Contact:

Re: Foating point bug

Post by grsbanks »

The bug in V3.10 occurred when raising a number to a power that is an integer. The program you've been using for this does use the 'Y^X' function, so that could be the cause.
There are only 10 kinds of people in the world: those who understand binary and those who do not.
Thomas Okken
Posts: 1098
Joined: Tue May 02, 2017 5:48 pm
Location: Netherlands
Contact:

Re: Foating point bug

Post by Thomas Okken »

grsbanks wrote:
Sun Oct 14, 2018 12:08 pm
The bug in V3.10 occurred when raising a number to a power that is an integer. The program you've been using for this does use the 'Y^X' function, so that could be the cause.
I think it's the call

Code: Select all

BIDECIMAL_CALL1_NORND(bid128_to_int32_xrnint, exact_y, y);
in the new logic in bid128_pow(); that seems to hang, or somehow cause a hang later on, when the exponent is >= 2^31-1/2. Whether the exponent is an integer or not doesn't seem to matter.

This looks like an error in the way the BIDECIMAL_CALL1_NORND macro is expanded, or a bug in the libgcc used by the DM42 SDK. (*)

I tried getting the PRF program to crash my DM42, using inputs of n!+1 with n>=17, but I guess I wasn't patient enough. Even on my iPhone, that program takes a long time when you throw 20-digit numbers at it!

(*) I wonder if this is related to the test cases from the Intel library's test suite that fail in my Android and iOS builds. The affected functions are all conversions, just like the one in question here. These test case failures don't affect Free42 because none of the affected functions are used by Free42, but now I wonder, will that still be true if I build with 2.0u2? And another question: what happens when you run the test suite against the DM42 build of 2.0u2? Any conversion function failures?
Thomas Okken
Posts: 1098
Joined: Tue May 02, 2017 5:48 pm
Location: Netherlands
Contact:

Re: Foating point bug

Post by Thomas Okken »

Thomas Okken wrote:
Sun Oct 14, 2018 7:01 pm
(*) I wonder if this is related to the test cases from the Intel library's test suite that fail in my Android and iOS builds. The affected functions are all conversions, just like the one in question here. These test case failures don't affect Free42 because none of the affected functions are used by Free42, but now I wonder, will that still be true if I build with 2.0u2?
The Android and iOS builds, with 2.0u2, do not have the Y^X bug. So, it doesn't look like something that affects ARM builds in general.
Post Reply