Page 43 of 47

Re: 43S News

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

Code: Select all

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

Code: Select all

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.

Re: 43S News

Posted: Tue Aug 27, 2019 12:38 pm
by Jaymos
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.


Re: 43S News

Posted: Wed Aug 28, 2019 11:43 am
by Over_score
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.


Re: 43S News

Posted: Fri Aug 30, 2019 8:51 am
by Jaymos
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.

Re: 43S News

Posted: Fri Aug 30, 2019 9:21 am
by Jaymos
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.

Code: Select all

[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 (6.71 KiB) Viewed 718 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.

Re: 43S News

Posted: Fri Aug 30, 2019 9:49 am
by Jaymos
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:

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 (3.03 KiB) Viewed 719 times
Mockup screen showing shortcuts to popular bases and word sizes

Fault report

Posted: Sun Sep 01, 2019 7:01 pm
by Jaymos
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.


Change Request

Posted: Sun Sep 01, 2019 7:10 pm
by Jaymos
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?

Fault report

Posted: Sat Sep 07, 2019 7:21 am
by Jaymos
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.

Fault report

Posted: Sun Sep 08, 2019 1:12 am
by Jaymos
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