DM42 resets during program run

 Posts: 4
 Joined: Fri Apr 16, 2021 6:07 am
DM42 resets during program run
I have a program that runs fine on many RPN platforms but causes the DM42 to reset and lose memory after several hours. Other platforms that run the program fine include Free42s (on IPad), DM41x, wp34s, and HP41c. Some of these platforms are not appropriate due to limited precision, excessive calculation times.
The program is a numerical solution to a lunar orbit. I'm doing a numerical solution because this is part of a nbody problem solution for which, of course, there is no closedform simple analytic solution.
Abstract of the program
Starting constants and conditions:
GMe = 3.986004418E14
Rinit = 363,228,900 (meters, perigee of lunar orbit)
Vinit = 1082 (m/s, velocity of moon at perigee)
Oribit period = 2,416,890 (s) (to use as max time)
Delta time = 2.41689 (s)
Loop:
update radius for delta time
up acceleration vector for delta time
update velocity vector for delta time
update position vector for delta time
update accumulated time by delta time
End loop when accumulated time > orbital time
(Program is 111 lines long, has some intermediate outputs; position, velocity vectors stored in registers).
In this instance, intention is to run 1 million iterations.
What happens is program runs for several hours, usually up to accumulated time of maybe 1,500,000 simulated seconds, or about 650,000 iterations. When calc dies, memory is lost so I don't know these times exactly.
As program runs, I periodically monitor intermediate outputsall values reasonable, no warnings, no indications of impending reset.
Then...eventually, it does reset, screen shows:
"DM Calculator Platform
DMCP v3.20 (IFC 0.315) BASE
...
Program Loaded DM42PGM
Version 3.16/2.5.20
Press Exit to continue.
"
This is 100% reproducible.
Physical status:
Calc is USB connected, known good cable, known good USB power supply.
Post crash (reset) battery indicator shows all bars (near 100% charge).
Calc is on fancooled bench, never gets warm (don't think? thermal shutdown is at play)
Other platforms:
DM41x same program runs to completion (though precision is not good enough).
Free 42s (IPad) same program has run up to 10 billion iterations, ie delta time = 0.000241689, (takes weeks and precision is not good enough).
HP41c(v,x) same program runs to completion (has run more iterations but requires weeks, AC power adapter; precision not good enough).
The program is a numerical solution to a lunar orbit. I'm doing a numerical solution because this is part of a nbody problem solution for which, of course, there is no closedform simple analytic solution.
Abstract of the program
Starting constants and conditions:
GMe = 3.986004418E14
Rinit = 363,228,900 (meters, perigee of lunar orbit)
Vinit = 1082 (m/s, velocity of moon at perigee)
Oribit period = 2,416,890 (s) (to use as max time)
Delta time = 2.41689 (s)
Loop:
update radius for delta time
up acceleration vector for delta time
update velocity vector for delta time
update position vector for delta time
update accumulated time by delta time
End loop when accumulated time > orbital time
(Program is 111 lines long, has some intermediate outputs; position, velocity vectors stored in registers).
In this instance, intention is to run 1 million iterations.
What happens is program runs for several hours, usually up to accumulated time of maybe 1,500,000 simulated seconds, or about 650,000 iterations. When calc dies, memory is lost so I don't know these times exactly.
As program runs, I periodically monitor intermediate outputsall values reasonable, no warnings, no indications of impending reset.
Then...eventually, it does reset, screen shows:
"DM Calculator Platform
DMCP v3.20 (IFC 0.315) BASE
...
Program Loaded DM42PGM
Version 3.16/2.5.20
Press Exit to continue.
"
This is 100% reproducible.
Physical status:
Calc is USB connected, known good cable, known good USB power supply.
Post crash (reset) battery indicator shows all bars (near 100% charge).
Calc is on fancooled bench, never gets warm (don't think? thermal shutdown is at play)
Other platforms:
DM41x same program runs to completion (though precision is not good enough).
Free 42s (IPad) same program has run up to 10 billion iterations, ie delta time = 0.000241689, (takes weeks and precision is not good enough).
HP41c(v,x) same program runs to completion (has run more iterations but requires weeks, AC power adapter; precision not good enough).
Re: DM42 resets during program run
There have been several updates of the DM42 firmware since the one you're using. I would suggest that you bring yours up to date and try again.
viewforum.php?f=16
viewforum.php?f=16
There are only 10 kinds of people in the world: those who understand binary and those who do not.
Re: DM42 resets during program run
It would also help if you posted the program itself; I'd like to see what it is you're doing.
Or, that even after 10 billion iterations, the solution is still not accurate enough? Then, perhaps a calculator is not the right
tool
Cheers, Werner
Do you mean that the precision of Free42 is not good enough? It is the same as in the (slower) DM42.prd6920766@gmail.com wrote: ↑Wed Apr 21, 2021 11:58 pmFree 42s (IPad) same program has run up to 10 billion iterations, ie delta time = 0.000241689, (takes weeks and precision is not good enough).
Or, that even after 10 billion iterations, the solution is still not accurate enough? Then, perhaps a calculator is not the right
tool
Cheers, Werner
42S #3249S01123
DM42 #00345
DM41X #01215
DM42 #00345
DM41X #01215
Re: DM42 resets during program run
There are two versions of Free42 for desktop/laptop computers. There is Free42 Decimal, which is the same as the version embedded in the DM42, but there is also Free42 Binary, which uses standard 64bit(?) floating point.
There are only 10 kinds of people in the world: those who understand binary and those who do not.

 Posts: 913
 Joined: Tue May 02, 2017 5:48 pm
 Location: United States
 Contact:
Re: DM42 resets during program run
True, but prd692etc mentioned insufficient precision in a test on their iPad, so that would have been the decimal version, unless they built Free42 Binary for iOS themselves. (This is possible, it's a simple matter of picking the "Free42 Binary" target in the Xcode project, but I don't publish the binary version for iOS or Android myself.)

 Posts: 4
 Joined: Fri Apr 16, 2021 6:07 am
Re: DM42 resets during program run
DM42, Another reset, loss of program, data, approx 80 hours into execution of SOrbit (attempted to post program earlier; post may have been too large, format wrong, ... it wasn't posted..); delta t set to 0.02416890, Tmax = 2,416,890 sec (in case it does get posted).
Can't see how to blame env., other calcs doing fine same setup.
Have not reflashed yet (don't know how on Linux, don't have Windows).
Don't have issues with Free42 runing on other platforms.
Can't see how to blame env., other calcs doing fine same setup.
Have not reflashed yet (don't know how on Linux, don't have Windows).
Don't have issues with Free42 runing on other platforms.
Re: DM42 resets during program run
How to reflash the calculator is described in the manual on the website. It is done on Linux in exactly the same way as on Windows and MacOS.
https://technical.swissmicros.com/dm42/ ... date_guide
As for the previous post, I did not let through and had the forum send you an explanation. Basically, you had posted what looked like 4 or 5 times exactly the same thing concatenated together, so I asked you to edit it down so that there was only one copy of all the information.
https://technical.swissmicros.com/dm42/ ... date_guide
As for the previous post, I did not let through and had the forum send you an explanation. Basically, you had posted what looked like 4 or 5 times exactly the same thing concatenated together, so I asked you to edit it down so that there was only one copy of all the information.
There are only 10 kinds of people in the world: those who understand binary and those who do not.

 Posts: 4
 Joined: Fri Apr 16, 2021 6:07 am
Re: DM42 resets during program run
2nd attempt to post this.
Reentered the Simple Orbit test program.
Ran the first test at 10E6 iterations. Executed completely in 84 minutes with expected results.
Started a second test at at 10E8 iterations. Approx 80 hours in, reset, loss of program, data.
(I Realize I'm way outside of normal use case envelope, but don't believe I'm misusing the product.)
RE this little test program, what it’s for: it’s a really stripped down simple Newtonian lunar orbit program meant to check on the errors in magnitudes (mostly of the radius vector between earth and moon) as a function of how fine the delta times used. In the complete model I’m building on a PC, I’m looking at errors in functions of order of magnitude jumps in delta time, so I’m doing the same thing here.
Sorry for the listing rather than a binary.
Orbit period of moon is taken to be 2416890 sec. Used as Tmax.
Desired #of iterations Delta T Expected error in x component of radius
10E6 2.41689 13758.3 meters
10E7 0.241689 1375.84 “
10E8 0.0241689 137.584 “
10E9 0.00241689 13.758 “
10E10 0.000241689 1.376 “
10E11 0.0000241689 0.138 “
Running program:
1. preload Reg 00 with # of iterations between display updates, say 100, or 1000.
2. program prompts for delta t (eg. 0.241689 sec – run time approx 14 hours)
3. program prompts for t max (for a single lunar orbit use 2416890)
(I’ve computed the 10E10 and 10E11 results on other platforms, they'd take too long on the DM42.)
Results for position vector will be Reg 04, 05; velocity vector Reg 06, 07.
01 LBL "SOrbit" 45 LBL 04 87 LBL 05
02 363,228,900 46 RCL 04 88 RCL 10
03 STO 04 47 x^2 89 "T="
04 1082 48 RCL 05 90 ARCL ST X
05 STO 07 49 X^2 91 AVIEW
06 0 50 + 92 RTN
07 STO 05 51 ENTER
08 STO 06 52 SQRT 93 LBL 06
09 STO 10 53 STO 01 94 RCL 08
10 "Delta T" 54 RDN 95 ST 10
11 PROMPT 55 3.986004418e14 96 XEQ 05
12 STO 08 56 X<>Y 100 .END.
13 "T Max" 57 /
14 PROMPT 58 CHS
15 STO 09 59 STO 11
60 RTN
16 LBL 01
17 RCL 08 61 LBL 03
18 ST+ 10 62 RCL 11
19 RCL 09 63 2
20 RCL 10 64 /
21 X>Y? 65 RCL 08
22 GTO 06 66 X^2
23 XEQ 02 67 *
24 RCL 10 68 RCL IND 02
25 RCL 08 69 RCL 01
26 / 70 /
27 RCL 00 71 *
28 MOD 72 RCL IND 03
29 X=0? 73 RCL 08
30 XEQ 05 74 *
31 GTO 01 75 +
76 RCL 11
32 LBL 02 77 RCL 08
33 XEQ 04 78 *
34 4 79 RCL IND 02
35 STO 02 80 RCL 01
36 6 81 /
37 STO 03 82 *
38 XEQ 03 83 ST+ IND 03
39 5 84 RDN
40 STO 02 85 ST+ IND 02
41 7 86 RTN
42 STO 03
43 XEQ 03
44 RTN
So one of the questions: is DM42 the right tool?
Not for entire solar system model. But for checking bits and pieces, intermediate results, etc. – yes, it’s the best easytouse, programinaninstant, usually sufficiently accurate tool I know of.
Re: precision in quick estimates.
The g++ compilers I use on Linux and Raspberry PI support double double type variable definitions, but the double double types currently are no more precision than double types, 64 bits. IEEE requires only that double doubles be no less precise than doubles. (I’ve written all of my vector and tensor C++ libraries to use double doubles in hopes that the compilers will soon support additional precision.) Meanwhile, it's GMPL libraries. Changes the coding paradigm from “justentertheequation” to “enterlongsequenceoffunctioncalls.” Fine. Doing that anyway for the main solar system model. For quick checks, sanity checks, intermediate results, logic verifications, etc. the DM42 is ideal. Quick, efficient RPN entry, excellent precision. Handy! (BTW, I'm also using HP41C MLTI library on a couple of HP41CL's, not nearly so handyglad someone developed it, but a little too complicated for my purposes.)
Sort of related: It’s really cool to switch between 64bits and 128 bits on the wp34s. Can leave your program in memory, run it at one precision, switch precision, rerun, compare. (Registers do get reorganized.)
2nd attempt to post this.
Reentered the Simple Orbit test program.
Ran the first test at 10E6 iterations. Executed completely in 84 minutes with expected results.
Started a second test at at 10E8 iterations. Approx 80 hours in, reset, loss of program, data.
(I Realize I'm way outside of normal use case envelope, but don't believe I'm misusing the product.)
RE this little test program, what it’s for: it’s a really stripped down simple Newtonian lunar orbit program meant to check on the errors in magnitudes (mostly of the radius vector between earth and moon) as a function of how fine the delta times used. In the complete model I’m building on a PC, I’m looking at errors in functions of order of magnitude jumps in delta time, so I’m doing the same thing here.
Sorry for the listing rather than a binary.
Orbit period of moon is taken to be 2416890 sec. Used as Tmax.
Desired #of iterations Delta T Expected error in x component of radius
10E6 2.41689 13758.3 meters
10E7 0.241689 1375.84 “
10E8 0.0241689 137.584 “
10E9 0.00241689 13.758 “
10E10 0.000241689 1.376 “
10E11 0.0000241689 0.138 “
Running program:
1. preload Reg 00 with # of iterations between display updates, say 100, or 1000.
2. program prompts for delta t (eg. 0.241689 sec – run time approx 14 hours)
3. program prompts for t max (for a single lunar orbit use 2416890)
(I’ve computed the 10E10 and 10E11 results on other platforms, they'd take too long on the DM42.)
Results for position vector will be Reg 04, 05; velocity vector Reg 06, 07.
01 LBL "SOrbit" 45 LBL 04 87 LBL 05
02 363,228,900 46 RCL 04 88 RCL 10
03 STO 04 47 x^2 89 "T="
04 1082 48 RCL 05 90 ARCL ST X
05 STO 07 49 X^2 91 AVIEW
06 0 50 + 92 RTN
07 STO 05 51 ENTER
08 STO 06 52 SQRT 93 LBL 06
09 STO 10 53 STO 01 94 RCL 08
10 "Delta T" 54 RDN 95 ST 10
11 PROMPT 55 3.986004418e14 96 XEQ 05
12 STO 08 56 X<>Y 100 .END.
13 "T Max" 57 /
14 PROMPT 58 CHS
15 STO 09 59 STO 11
60 RTN
16 LBL 01
17 RCL 08 61 LBL 03
18 ST+ 10 62 RCL 11
19 RCL 09 63 2
20 RCL 10 64 /
21 X>Y? 65 RCL 08
22 GTO 06 66 X^2
23 XEQ 02 67 *
24 RCL 10 68 RCL IND 02
25 RCL 08 69 RCL 01
26 / 70 /
27 RCL 00 71 *
28 MOD 72 RCL IND 03
29 X=0? 73 RCL 08
30 XEQ 05 74 *
31 GTO 01 75 +
76 RCL 11
32 LBL 02 77 RCL 08
33 XEQ 04 78 *
34 4 79 RCL IND 02
35 STO 02 80 RCL 01
36 6 81 /
37 STO 03 82 *
38 XEQ 03 83 ST+ IND 03
39 5 84 RDN
40 STO 02 85 ST+ IND 02
41 7 86 RTN
42 STO 03
43 XEQ 03
44 RTN
One question was: is DM42 the right tool?
Not for entire model. But checking bits and pieces, intermediate results, etc. – it’s the best easytouse, programinaninstant, usually sufficiently accurate tool I know of.
Re: precision in quick estimates.
The g++ compilers I use on Linux and Raspberry PI support double double type variable definitions, but the double double types currently are no more precision than double types, 64 bits. IEEE requires only that double doubles be no less precise than doubles. (I’ve written all of my vector and tensor C++ libraries to use double doubles in hopes that the compilers will soon support additional precision.) Meanwhile, it's GMPL libraries. Changes the coding paradigm from “justentertheequation” to “enterlongsequenceoffunctioncalls.” Fine. Doing that anyway for the main solar system model. For quick checks, sanity checks, intermediate results, logic verifications, etc. the DM42 is ideal. What they call "elegant." Quick, efficient RPN entry, excellent precision. Handy! (BTW, I'm also using HP41C MLTI library on a couple of HP41CL'snot nearly so handyglad someone developed it, but a little too complicated for my purposes.)
Sort'a related: On wp34s, it’s really cool to switch between 64bits and 128. Leave program in memory, run at one precision, switch precision, rerun, compare. (Registers do get reorganized.)
Reentered the Simple Orbit test program.
Ran the first test at 10E6 iterations. Executed completely in 84 minutes with expected results.
Started a second test at at 10E8 iterations. Approx 80 hours in, reset, loss of program, data.
(I Realize I'm way outside of normal use case envelope, but don't believe I'm misusing the product.)
RE this little test program, what it’s for: it’s a really stripped down simple Newtonian lunar orbit program meant to check on the errors in magnitudes (mostly of the radius vector between earth and moon) as a function of how fine the delta times used. In the complete model I’m building on a PC, I’m looking at errors in functions of order of magnitude jumps in delta time, so I’m doing the same thing here.
Sorry for the listing rather than a binary.
Orbit period of moon is taken to be 2416890 sec. Used as Tmax.
Desired #of iterations Delta T Expected error in x component of radius
10E6 2.41689 13758.3 meters
10E7 0.241689 1375.84 “
10E8 0.0241689 137.584 “
10E9 0.00241689 13.758 “
10E10 0.000241689 1.376 “
10E11 0.0000241689 0.138 “
Running program:
1. preload Reg 00 with # of iterations between display updates, say 100, or 1000.
2. program prompts for delta t (eg. 0.241689 sec – run time approx 14 hours)
3. program prompts for t max (for a single lunar orbit use 2416890)
(I’ve computed the 10E10 and 10E11 results on other platforms, they'd take too long on the DM42.)
Results for position vector will be Reg 04, 05; velocity vector Reg 06, 07.
01 LBL "SOrbit" 45 LBL 04 87 LBL 05
02 363,228,900 46 RCL 04 88 RCL 10
03 STO 04 47 x^2 89 "T="
04 1082 48 RCL 05 90 ARCL ST X
05 STO 07 49 X^2 91 AVIEW
06 0 50 + 92 RTN
07 STO 05 51 ENTER
08 STO 06 52 SQRT 93 LBL 06
09 STO 10 53 STO 01 94 RCL 08
10 "Delta T" 54 RDN 95 ST 10
11 PROMPT 55 3.986004418e14 96 XEQ 05
12 STO 08 56 X<>Y 100 .END.
13 "T Max" 57 /
14 PROMPT 58 CHS
15 STO 09 59 STO 11
60 RTN
16 LBL 01
17 RCL 08 61 LBL 03
18 ST+ 10 62 RCL 11
19 RCL 09 63 2
20 RCL 10 64 /
21 X>Y? 65 RCL 08
22 GTO 06 66 X^2
23 XEQ 02 67 *
24 RCL 10 68 RCL IND 02
25 RCL 08 69 RCL 01
26 / 70 /
27 RCL 00 71 *
28 MOD 72 RCL IND 03
29 X=0? 73 RCL 08
30 XEQ 05 74 *
31 GTO 01 75 +
76 RCL 11
32 LBL 02 77 RCL 08
33 XEQ 04 78 *
34 4 79 RCL IND 02
35 STO 02 80 RCL 01
36 6 81 /
37 STO 03 82 *
38 XEQ 03 83 ST+ IND 03
39 5 84 RDN
40 STO 02 85 ST+ IND 02
41 7 86 RTN
42 STO 03
43 XEQ 03
44 RTN
So one of the questions: is DM42 the right tool?
Not for entire solar system model. But for checking bits and pieces, intermediate results, etc. – yes, it’s the best easytouse, programinaninstant, usually sufficiently accurate tool I know of.
Re: precision in quick estimates.
The g++ compilers I use on Linux and Raspberry PI support double double type variable definitions, but the double double types currently are no more precision than double types, 64 bits. IEEE requires only that double doubles be no less precise than doubles. (I’ve written all of my vector and tensor C++ libraries to use double doubles in hopes that the compilers will soon support additional precision.) Meanwhile, it's GMPL libraries. Changes the coding paradigm from “justentertheequation” to “enterlongsequenceoffunctioncalls.” Fine. Doing that anyway for the main solar system model. For quick checks, sanity checks, intermediate results, logic verifications, etc. the DM42 is ideal. Quick, efficient RPN entry, excellent precision. Handy! (BTW, I'm also using HP41C MLTI library on a couple of HP41CL's, not nearly so handyglad someone developed it, but a little too complicated for my purposes.)
Sort of related: It’s really cool to switch between 64bits and 128 bits on the wp34s. Can leave your program in memory, run it at one precision, switch precision, rerun, compare. (Registers do get reorganized.)
2nd attempt to post this.
Reentered the Simple Orbit test program.
Ran the first test at 10E6 iterations. Executed completely in 84 minutes with expected results.
Started a second test at at 10E8 iterations. Approx 80 hours in, reset, loss of program, data.
(I Realize I'm way outside of normal use case envelope, but don't believe I'm misusing the product.)
RE this little test program, what it’s for: it’s a really stripped down simple Newtonian lunar orbit program meant to check on the errors in magnitudes (mostly of the radius vector between earth and moon) as a function of how fine the delta times used. In the complete model I’m building on a PC, I’m looking at errors in functions of order of magnitude jumps in delta time, so I’m doing the same thing here.
Sorry for the listing rather than a binary.
Orbit period of moon is taken to be 2416890 sec. Used as Tmax.
Desired #of iterations Delta T Expected error in x component of radius
10E6 2.41689 13758.3 meters
10E7 0.241689 1375.84 “
10E8 0.0241689 137.584 “
10E9 0.00241689 13.758 “
10E10 0.000241689 1.376 “
10E11 0.0000241689 0.138 “
Running program:
1. preload Reg 00 with # of iterations between display updates, say 100, or 1000.
2. program prompts for delta t (eg. 0.241689 sec – run time approx 14 hours)
3. program prompts for t max (for a single lunar orbit use 2416890)
(I’ve computed the 10E10 and 10E11 results on other platforms, they'd take too long on the DM42.)
Results for position vector will be Reg 04, 05; velocity vector Reg 06, 07.
01 LBL "SOrbit" 45 LBL 04 87 LBL 05
02 363,228,900 46 RCL 04 88 RCL 10
03 STO 04 47 x^2 89 "T="
04 1082 48 RCL 05 90 ARCL ST X
05 STO 07 49 X^2 91 AVIEW
06 0 50 + 92 RTN
07 STO 05 51 ENTER
08 STO 06 52 SQRT 93 LBL 06
09 STO 10 53 STO 01 94 RCL 08
10 "Delta T" 54 RDN 95 ST 10
11 PROMPT 55 3.986004418e14 96 XEQ 05
12 STO 08 56 X<>Y 100 .END.
13 "T Max" 57 /
14 PROMPT 58 CHS
15 STO 09 59 STO 11
60 RTN
16 LBL 01
17 RCL 08 61 LBL 03
18 ST+ 10 62 RCL 11
19 RCL 09 63 2
20 RCL 10 64 /
21 X>Y? 65 RCL 08
22 GTO 06 66 X^2
23 XEQ 02 67 *
24 RCL 10 68 RCL IND 02
25 RCL 08 69 RCL 01
26 / 70 /
27 RCL 00 71 *
28 MOD 72 RCL IND 03
29 X=0? 73 RCL 08
30 XEQ 05 74 *
31 GTO 01 75 +
76 RCL 11
32 LBL 02 77 RCL 08
33 XEQ 04 78 *
34 4 79 RCL IND 02
35 STO 02 80 RCL 01
36 6 81 /
37 STO 03 82 *
38 XEQ 03 83 ST+ IND 03
39 5 84 RDN
40 STO 02 85 ST+ IND 02
41 7 86 RTN
42 STO 03
43 XEQ 03
44 RTN
One question was: is DM42 the right tool?
Not for entire model. But checking bits and pieces, intermediate results, etc. – it’s the best easytouse, programinaninstant, usually sufficiently accurate tool I know of.
Re: precision in quick estimates.
The g++ compilers I use on Linux and Raspberry PI support double double type variable definitions, but the double double types currently are no more precision than double types, 64 bits. IEEE requires only that double doubles be no less precise than doubles. (I’ve written all of my vector and tensor C++ libraries to use double doubles in hopes that the compilers will soon support additional precision.) Meanwhile, it's GMPL libraries. Changes the coding paradigm from “justentertheequation” to “enterlongsequenceoffunctioncalls.” Fine. Doing that anyway for the main solar system model. For quick checks, sanity checks, intermediate results, logic verifications, etc. the DM42 is ideal. What they call "elegant." Quick, efficient RPN entry, excellent precision. Handy! (BTW, I'm also using HP41C MLTI library on a couple of HP41CL'snot nearly so handyglad someone developed it, but a little too complicated for my purposes.)
Sort'a related: On wp34s, it’s really cool to switch between 64bits and 128. Leave program in memory, run at one precision, switch precision, rerun, compare. (Registers do get reorganized.)
Re: DM42 resets during program run
Thanks for your kind words about the WP34S.
Regarding your post: It consists of two halves which seem to be identical. If true, please edit your post (yes, you can!) and delete what's just repeated. TIA
Regarding your post: It consists of two halves which seem to be identical. If true, please edit your post (yes, you can!) and delete what's just repeated. TIA
DM42 SN: 00041 β
WP 43S running on this device
HP35, HP45, ..., HP35S, WP 34S, WP 31S, DM16L
WP 43S running on this device
HP35, HP45, ..., HP35S, WP 34S, WP 31S, DM16L
Re: DM42 resets during program run
There is no such type as double double in C/C++. I think you mean long double?
GCC supports 128bit floating point on some architectures, including x86 and AArch64/ARM64 using the _Float128/__float128 type and libquadmath.
(Also, your program listings are a mess. One instruction per line please!)
GCC supports 128bit floating point on some architectures, including x86 and AArch64/ARM64 using the _Float128/__float128 type and libquadmath.
(Also, your program listings are a mess. One instruction per line please!)