43S News

[Jaymos]

Hi Walter,

I found a strange anomaly in that the constants are showing weird numbers, i.e.

Earth's gravitational constant: g (cross-circle) = 11.308542 m/s/s according to the WP43S emulator. I expected 9.8xxx. The WP34S correctly shows g = 9.806....

Euler’s e (eE) in the WP43S shows 5.6070374…x10ˆ-8 where the WP34S correctly shows 2.7183…

Planck’s constant h shows as 41.0433… where the WP34S shows it correctly as 6.6261x10-34.

I did not check more, because there is clearly a systemic error.

[Over_score]

2. R <> P

[RESET] [3] [4] [>P] does not show the text on the left "r" & "angle" any more. p. 120 of the OM shows the texts.

[>R] does correctly show "x =" and "y =" on the left hand.

Thank you for reporting. It's fixed now.

[Over_score]

I found a strange anomaly in that the constants are showing weird numbers, i.e.

Earth's gravitational constant: g (cross-circle) = 11.308542 m/s/s according to the WP43S emulator. I expected 9.8xxx. The WP34S correctly shows g = 9.806....

Euler’s e (eE) in the WP43S shows 5.6070374…x10ˆ-8 where the WP34S correctly shows 2.7183…

Planck’s constant h shows as 41.0433… where the WP34S shows it correctly as 6.6261x10-34.

This is also fixed now.

[Jaymos]

Hi all,

I found another discrepancy using the display mode FIX:

Code: Select all

[RESET] [EXIT]
[g] [DISP] [FIX] [2]
.01 [ENTER]
.1 [ENTER]
10 [ENTER]
100 [EXIT]

The result on the stack is:

Code: Select all

.01
.10
10
100

This is not according to the OM description on p78 of how FIX should work. It is also different than what I am used to and is therefore probably incorrect.
I would have expected to 10 to be shown as 10.00 in FIX 2, and the 100 as 100.00.

[Over_score]

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

[Jaymos]

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.

best regards
j

[Walter]

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.

Why is B not defined to be a shortcut for binary?

Either way, upon pressing [#], on the emulator, appears a menu with ->, VARS, ST ... and it goes into entry mode with no indication that you are expected to press to change base. I know you always say that one should know what you want to do, but the rest of your calculator is ergonomically optimised, why not make this clear too?

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.

On the real hardware, it may be less of an issue, but still an issue, as the misleading data is less, and only the unresponsive menu line with --> VARS ST.X ST.Y ST.Z ST.T would appear, which is misleading.

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.

Oooh, and the key B is in no way shorter than [2].

Will think about more dedicated menus along the lines of your suggestions.

P.S.: There are many operations not coded yet, so some of our intentions may not become obvious at the present state of the emulator. And some concepts were transfered from the WP34S but might not have been implemented the same way. Futhermore, the WP34S manual may contain some documentation errors.

[Jaymos]

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.

Why is B not defined to be a shortcut for binary?

Oooh, and the key B is in no way shorter than [2].

The benefit is rather that the device would work right whether you type either 2 or B, i.e. that it does not refuse to go to binary when you press # B because you may be used to press # H for hex.

[Jaymos]

Stack issue reported

Using a fresh compile of the emulator,

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.

[Over_score]

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.