43S News

General discussion about calculators, Swiss Micros or otherwise
User avatar
Jaymos
Posts: 282
Joined: Sun Nov 04, 2018 6:03 pm
Location: Cape Town

Re: 43S News

Post by Jaymos » Fri Aug 16, 2019 1:34 pm

Over_score wrote:
Fri Aug 16, 2019 12:53 pm
Jaymos wrote:
Thu Aug 15, 2019 9:48 pm

Code: Select all

RESET 
EXIT
g[pi] [ENTER] 10 x
Results in 31.41.. in X and 0 in Y

Code: Select all

RESET 
EXIT
g[pi] g[pi] 10 x
Results in 31.41.. in X and 3.14.. in Y.

I think the stack lift enable is not set.
I don't understand what's wrong.
In the 1st case, ENTER disables stack lift so 10 overwrites pi in X.
In the 2nd case stack lift is enabled after each g[pi] so when entering 10 results in Z=pi, Y=pi and X=10.
My apologies, you are absolutely correct, there is nothing wrong.
My report was due to operator error.
Thank you for the reply.
J
Jaco Mostert
Elec Eng, South Africa
WP34C, HP42S, DM42 for complex math; 35S, 28C, 32Sii, WP34S, EL-506P, EL-W506, FX750P; owned FX702P & 11C; used 67 & 85. iOS: 42s (Byron), Free42, WP31S/34S, HCalc.
43S operators right. DM42 sn. 03818.

User avatar
Jaymos
Posts: 282
Joined: Sun Nov 04, 2018 6:03 pm
Location: Cape Town

Re: 43S News

Post by Jaymos » Tue Aug 27, 2019 12:38 pm

Suspected SL issue: I hope I am not wrong again...

RESET 2 ENTER CC renders 2.+I*2 which is right, but SL is not set. But I think at that point, CC terminated entry, and SL should be set, and it is not.
(The problem case for me was: RESET 2 ENTER CC 2 * which rendered 0, then I saw why.)
RESET 2 EXIT 2 EXIT CC also renders 2.+I*2, but with SL set. This is correct, but I think only correct because SL was set before by EXIT.
So it seems CC does not change the SL status, and it should set it always.

Different when CC used as interactive entry, i.e.
with 2 CC 2 ENTER SL should not be set. It does it correctly.
with 2 CC 2 EXIT SL should be set. It does it correctly.

Regards
Jaco
Jaco Mostert
Elec Eng, South Africa
WP34C, HP42S, DM42 for complex math; 35S, 28C, 32Sii, WP34S, EL-506P, EL-W506, FX750P; owned FX702P & 11C; used 67 & 85. iOS: 42s (Byron), Free42, WP31S/34S, HCalc.
43S operators right. DM42 sn. 03818.

User avatar
Over_score
Posts: 44
Joined: Fri May 05, 2017 7:37 pm
Location: France

Re: 43S News

Post by Over_score » Wed Aug 28, 2019 11:43 am

Hi Jaymos,

it's better to report a bug that is not a bug than to risk not reporting a real bug!
This one is a real one and is corrected in the master branch.

Cheers
DM42 (SN 00284 & 03835), DM15L, HP41CV, HP42S, HP35s, WP34S, HP Prime

User avatar
Jaymos
Posts: 282
Joined: Sun Nov 04, 2018 6:03 pm
Location: Cape Town

Re: 43S News

Post by Jaymos » Fri Aug 30, 2019 8:51 am

43S feature change request: RBR and STATUS

Could you please consider refining both RBR and STATUS viewers to remember where you left the browser, so that when you re-enter the browser, that it re-opens on the same place where you left off?

The very practical reason for this is that if you are using the browser, it will likely be to fault find RPN program steps, and equally likely that you will want to jump back to program mode, back to R/S, back to viewer, etc. Currently it is cumbersome to start with a register number every time you enter the RBR, eg. [f] [RBR] 47 instead of just [f] [RBR].

Similarly, for the STATUS viewer, but there are only two fixed non-scrolling screens. If you are watching flags in the second screen, it will be less cumbersome to not have to use the arrow to change screens every time you access STATUS.

I do not foresee the need for these to be remembered after switch-off. It wold be reasonable to browse back after switch-on even though it won't be bad if the position is retained the same way the stack is retained.
Jaco Mostert
Elec Eng, South Africa
WP34C, HP42S, DM42 for complex math; 35S, 28C, 32Sii, WP34S, EL-506P, EL-W506, FX750P; owned FX702P & 11C; used 67 & 85. iOS: 42s (Byron), Free42, WP31S/34S, HCalc.
43S operators right. DM42 sn. 03818.

User avatar
Jaymos
Posts: 282
Joined: Sun Nov 04, 2018 6:03 pm
Location: Cape Town

Re: 43S News

Post by Jaymos » Fri Aug 30, 2019 9:21 am

Jaymos wrote:
Sat Aug 03, 2019 10:00 pm
Over_score wrote:
Sat Aug 03, 2019 9:39 pm
Hi Jaymos,

it’s not a bug, it’s a feature!
In both cases (10 and 100), the numbers are long integers, not reals.
Try

Code: Select all

[RESET] [EXIT]
[g] [DISP] [FIX] [2]
.01 [ENTER]
.1 [ENTER]
10. [ENTER]
100. [EXIT]
note the . after 10 and 100
I understand that now. Thanks. And understand the workaround to force reals.

This feature is annoying though. I'm not saying I know how to fix it, because without knowing what the user is typing in, you must make some assumptions. I don't like the assumption that after typing reals, the next number would be a integer type.

In real use, one would seldomly work with say complex vectors and reals, then change to integer math, then back. I think this calls for a conscious mode change and not automatic type assumption.

Feature change request: No assumption of longint type if decimal is not typed.

I would like to request to refine this feature, re. the assumption of type to be a configurable option. Options could be:

(a) auto mode: assume that the user means integer if he does not type a decimal (this is the status quo). This allows either to be entered without being in a certain "mode".

(b) realSP, realDP or integer mode: Let the user decide which type he wants regardless of whether the decimal is typed for an integer number. (RealSP would be the norm for many users in engineering at least). This implies you must add an entry mode, i.e integer / real mode (similar to 42S) or realDP mode (like on the WP34C).

The practical issue here is in ENG or SCI display modes where the display looks different than configured when integer types are mixed with real types when not intended. it would add consistency of display. (Let's add that to all the other "first world problems" we discuss here, but I'll leave that for another day ;-) ).

ex1.png
ex1.png (6.71 KiB) Viewed 340 times
Example of assumed integer type 33000 among other real values using typical electrical engineering quantities in ENG 3 display mode (2.7 MVA, 33 kV, rt3, 0.1%).

Edited to include example screen shot.
Last edited by Jaymos on Fri Aug 30, 2019 9:55 am, edited 2 times in total.
Jaco Mostert
Elec Eng, South Africa
WP34C, HP42S, DM42 for complex math; 35S, 28C, 32Sii, WP34S, EL-506P, EL-W506, FX750P; owned FX702P & 11C; used 67 & 85. iOS: 42s (Byron), Free42, WP31S/34S, HCalc.
43S operators right. DM42 sn. 03818.

User avatar
Jaymos
Posts: 282
Joined: Sun Nov 04, 2018 6:03 pm
Location: Cape Town

Re: 43S News

Post by Jaymos » Fri Aug 30, 2019 9:49 am

Walter wrote:
Sun Aug 04, 2019 8:12 pm
Jaymos wrote:
Thu Aug 01, 2019 11:05 am
1. # Base change:

Currently to change base, you press [f][#][H] or [f][#][D] or [f][#][2] or the obvious for any number base in range.
...
If there would have been no indication (at all), one needs to remember, but with irrelevant text and keys marked, it is misleading. The IJKL registers, ST.X..through ST.D, and the VARS item and the [->] do not work if you press it and do not belong there.
...
I would have liked to see an indication on a menu for HEX, DEC, BIN, OCT and # instead of this. I realise this possibly will mean a menu rather than going straight to the TAM input screen. Maybe a menu with:

HEX, DEC, OCT, BIN, NN
where NN in turn calls the existing function which brings up the TAM screen or a modified one for custom bases.

Possibly on the [f] shift of the menu, the common WSIZEs as in
4 b, 8 b, 16 b, 32 b, 64 b, NN
where NN again calls the existing WSIZE input TAM screen or a modified one for custom sizes.
The emulator shows the TAM virtual keyboard with the intention to ease your path. Please note that [->][ST.x] works after [#] (with x denoting any valid stack register). VARS are not implemented yet.

Perhaps the virtual keyboard concept is just a bit too simple here. One virtual keyboard can't do for TAM for all commands. As you rightfully stated, there won't be an issue on the real HW, however.
...
Will think about more dedicated menus along the lines of your suggestions.
...
Feature change request: #

I attach below a mockup to aid understanding of my above quoted.

It was a quick menu, I would agree DEC and OCT would be better swapped if I had thought about it and of course both NN options mentioned above must still be added, but this illustrates the idea, from the 42S BASE menu example. (Of course everything shouldn't be 42S, this is a powerful new calculator leaving 42S behind, but I'm just acknowledging where it comes from).

ex2.png
ex2.png (3.03 KiB) Viewed 341 times
Mockup screen showing shortcuts to popular bases and word sizes
Jaco Mostert
Elec Eng, South Africa
WP34C, HP42S, DM42 for complex math; 35S, 28C, 32Sii, WP34S, EL-506P, EL-W506, FX750P; owned FX702P & 11C; used 67 & 85. iOS: 42s (Byron), Free42, WP31S/34S, HCalc.
43S operators right. DM42 sn. 03818.

User avatar
Jaymos
Posts: 282
Joined: Sun Nov 04, 2018 6:03 pm
Location: Cape Town

Fault report

Post by Jaymos » Sun Sep 01, 2019 7:01 pm

Fault report 1: Problem with exit from integer input method: RESET 5#
When an integer in a base is entered, like 5#, neither EXIT not ENTER works to abort, and the only way to cancel is to do multiple backspaces which is not intuitive. EXIT should always exit (I think).

Fault report 2: Problem with exit from CC:
RESET 2 CC EXIT, and RESET 2 CC ENTER result in 2.+ix1. It would be better if zero is assumed instead of 1, such as to render 2.+ix0 when you terminate entry halfway.


Regards
Jaco
Jaco Mostert
Elec Eng, South Africa
WP34C, HP42S, DM42 for complex math; 35S, 28C, 32Sii, WP34S, EL-506P, EL-W506, FX750P; owned FX702P & 11C; used 67 & 85. iOS: 42s (Byron), Free42, WP31S/34S, HCalc.
43S operators right. DM42 sn. 03818.

User avatar
Jaymos
Posts: 282
Joined: Sun Nov 04, 2018 6:03 pm
Location: Cape Town

Change Request

Post by Jaymos » Sun Sep 01, 2019 7:10 pm

Request1: CPX menu: Please advise on Sign and UNITV that seem to be the same. Is it meant to be the same? If the same, why not remove either?

Request2: STAT menu: it makes more sense to have both E+ and E- on a primary FN1 and FN2. If one would be inclined to use either, it would be better to have it more readily available. A solution would be to put E+ and E- next to one another on primary FN keys.

Request3: CATALOG menu: DIGITS: It makes more sense to move the positions of ABCDEF to be on the primaries, to be same as in the INTS menu. Maybe for consistency?

Request4: Regarding: >R >P and RECT POLAR
I previously commented on >R and >P in viewtopic.php?f=2&t=1816&p=10814&hilit= ... lar#p10814.
I believe that >R and >P can easily and automatically perform the POLAR and RECT command IF the X register contains a complex type. You maybe want to interlock it to be active only when CPXRES is true, or not. Can this work?
Jaco Mostert
Elec Eng, South Africa
WP34C, HP42S, DM42 for complex math; 35S, 28C, 32Sii, WP34S, EL-506P, EL-W506, FX750P; owned FX702P & 11C; used 67 & 85. iOS: 42s (Byron), Free42, WP31S/34S, HCalc.
43S operators right. DM42 sn. 03818.

User avatar
Jaymos
Posts: 282
Joined: Sun Nov 04, 2018 6:03 pm
Location: Cape Town

Fault report

Post by Jaymos » Sat Sep 07, 2019 7:21 am

Fault report in Long integer operation, sign is not processed correctly:
RESET 2 [+/-] ENTER 3 [y^x] and the same for
RESET 2 ENTER [+/-] 3 [y^x] and
RESET 2 ENTER [+/-] 3 EXIT [y^x]

all render 8, not -8.

Interestingly, shortint works correctly:
RESET 2 # 10 ENTER [+/-] 3 [y^x]

and also Real16 and Real34 work correctly as expected.
Jaco Mostert
Elec Eng, South Africa
WP34C, HP42S, DM42 for complex math; 35S, 28C, 32Sii, WP34S, EL-506P, EL-W506, FX750P; owned FX702P & 11C; used 67 & 85. iOS: 42s (Byron), Free42, WP31S/34S, HCalc.
43S operators right. DM42 sn. 03818.

User avatar
Jaymos
Posts: 282
Joined: Sun Nov 04, 2018 6:03 pm
Location: Cape Town

Fault report

Post by Jaymos » Sun Sep 08, 2019 1:12 am

Fault Report:

Using a freshly compiled emulator, I removed bin file for a fresh start, then 77 ENTER 88 [y^x] keeps on crashing, with "segmentation fault 11".


Integer operation question:
77. ENTER 8. [y^x] works and when this real number is converted to short int it works. # 10, and the answer a short int.
Larger numbers fail. As test, I take:
2.0 ENTER 55 [y^x] which gives 3.6... x 10^16, within range of short int.
I then do # D which gives me 0 base 10. Not right. I expected it to give me a 15 odd significant digit integer with zeroes where the figures were gone.
2.0 ENTER 45 [y^x] gives 35 184 372 088 832., also within range of short int. I then do # D which gives me 35 184 372 088 832 base 10. Correct answer.

To confirm that 2^55 is within range of the short int, I do 2#10 ENTER 55 [y^x] which produces a short int of 36 028 797 018 963 968 base 10.
I take this, multiply by 1.0, and convert back to base 10 short int, i.e.: 1.0 [*] # D, and I get 0 base 10 again. Not correct.

Maybe I am misunderstanding the expected conversion from real to longint. If so, please refer to a source where I can read.

Best regards
Jaco
Jaco Mostert
Elec Eng, South Africa
WP34C, HP42S, DM42 for complex math; 35S, 28C, 32Sii, WP34S, EL-506P, EL-W506, FX750P; owned FX702P & 11C; used 67 & 85. iOS: 42s (Byron), Free42, WP31S/34S, HCalc.
43S operators right. DM42 sn. 03818.

Post Reply