SwissMicros Calculator Forum

Regarding (290! + 1) - 290! it seems to me that Commit 0570007b (28.08.2019) has still mastered this task, but Commit 9292b1fb (29.08.2019) no longer, the program crashes. I'm writing here for the Windows emulator.

Always first backup.bin deleted, emulator started, then a RESET made, emulator stopped and restarted and then the first use.

I think I found the origin of all the hassle with long integers. I hope that it's fixed now.

Over_score wrote: ↑

Sun Sep 22, 2019 12:06 pm

I think I found the origin of all the hassle with long integers. I hope that it's fixed now.

Well done. Quite a number of changes required to do this!

My (n! +1) - n! = 1 test now runs to 965 max. Wow!! I did some more tests and the Mac emulator did not crash for any of the following longint results below:

• 965! (I actually did quite a number of x! from 290 through 1000 until I found 965). 965! is reported to be 734 638 077 538 293 124 001 787 521 309 991 047 x 10^2427
• (965! + 1) - 965!
• 77^88
• (301! . 302!) / (300! ^2) / 301 ^ 2 /302 = 1 as expected. Well done.
• Interesting, the calculator now does 6!! nice.

Question 1:
I tried "ALL 15" with 965! in the X register: I expected no change to the X register as there is no real in the X register. The result was that the calculator attempted to convert to real, which of course it cannot do at a X register value larger than 1e2462. So the longint changed to infinity and did not want to change back.
The question is not why it goes to infinity, the question is if the automatic conversion from longint to real is intended for (real) display mode change. I did not find any reference to that in the OM or ReM.

Question 2:
Is there a way to display more digits of a longint (I can't imagine for which reason one would need that, just asking)? OM p128/314 states larger than 42 digits are shown as exp. notation, but no mention is made of how to get the 2400 odd digits if needed. WA is probably one answer

Answer to Q1: Please see p.143 of the Owner's Manual.

Question to Q2: What's WA?

Walter wrote: ↑

Mon Sep 23, 2019 3:22 pm

Answer to Q1: Please see p.143 of the Owner's Manual.

Question to Q2: What's WA?

1. Thank you. Will look.

2. Wolfram Alpha

Walter wrote: ↑

Mon Sep 23, 2019 3:22 pm

Answer to Q1: Please see p.143 of the Owner's Manual.

Question to Q2: What's WA?

Hi Walter,

Thank you for the answer.

1. I did read this page before I asked, and p143 still does not clarify. It does not refer to integers or long integers and refers to fractions only.

Regards
Jaco

Fault report:

Compiling for DMCP, gives the following warnings, which were not there before:

Jaymos wrote: ↑

Sun Sep 22, 2019 6:44 pm

Question 1:
I tried "ALL 15" with 965! in the X register: I expected no change to the X register as there is no real in the X register. The result was that the calculator attempted to convert to real, which of course it cannot do at a X register value larger than 1e2462. So the longint changed to infinity and did not want to change back.
The question is not why it goes to infinity, the question is if the automatic conversion from longint to real is intended for (real) display mode change. I did not find any reference to that in the OM or ReM.

I checked some older versions of the specs. The automatic conversion you observe was intended until v0.10. It should have been removed thereafter. Thanks for reporting.

Jaymos wrote: ↑

Tue Sep 24, 2019 11:41 pm

Compiling for DMCP, gives the following warnings, which were not there before:

Code: Select all

...$ ./compilDMCP > aa.txt
src/wp43s/display.c: In function 'longIntegerToAllocatedString':
src/wp43s/display.c:1640:72: warning: format '%d' expects argument of type 'int', but argument 2 has type 'int32_t' {aka 'long int'} [-Wformat=]
     printf("In function longIntegerToAllocatedString: the string str (%d bytes) is too small to hold the base 10 representation of lgInt, %d are needed!\n", strLg, stringLg);
                                                                       ~^                                                                                     ~~~~~
                                                                       %ld
src/wp43s/display.c:1640:140: warning: format '%d' expects argument of type 'int', but argument 3 has type 'int32_t' {aka 'long int'} [-Wformat=]
     printf("In function longIntegerToAllocatedString: the string str (%d bytes) is too small to hold the base 10 representation of lgInt, %d are needed!\n", strLg, stringLg);
                                                                                                                                           ~^                        ~~~~~~~~
                                                                                                                                           %ld

This is fixed.

Walter wrote: ↑

Wed Sep 25, 2019 10:42 am

Jaymos wrote: ↑

Sun Sep 22, 2019 6:44 pm

Question 1:
I tried "ALL 15" with 965! in the X register: I expected no change to the X register as there is no real in the X register. The result was that the calculator attempted to convert to real, which of course it cannot do at a X register value larger than 1e2462. So the longint changed to infinity and did not want to change back.
The question is not why it goes to infinity, the question is if the automatic conversion from longint to real is intended for (real) display mode change. I did not find any reference to that in the OM or ReM.

I checked some older versions of the specs. The automatic conversion you observe was intended until v0.10. It should have been removed thereafter. Thanks for reporting.

This is fixed