C47 Bug Reports

This area is for discussion about these families of custom high-end Scientific Calculator applications for SwissMicros devices.
chris185
Posts: 31
Joined: Tue May 23, 2023 11:59 am

Re: C43/C47 Bug Reports

Post by chris185 »

Not sure whether this is a bug report, or just my lack of understand regarding The Solver:

In EQN I hit NEW and entered:

mix: tm = cc • tc + (1 - cc) • th

{tc: T-cold water, th: T-hot-water, cc: fraction which is cold, tm: resultant T-mixture}

Then I hit F6 [Solver] and get a menu containing the expected variables: tm cc tc th.

If I then enter

10 tc 60 th 0.5 cc tm

I get the expected 35.

And if I enter

40 th cc

I get the expected 0.4

So far so good.

Then I entered

0 cc 1 cc F5 [Draw]

I then get TWO sand-timer annunciations (the normal one and the one on the left (where the graph alphanumeric data goes).

I was expecting a graph of tm (y) against cc (x) ie. straight line from (0,60) to (1,10)

Instead I get a slight S curve (reflected), mostly a straight line from (0.35,2.5) to (0.47,-3.8) crossing at (0.4,0)

The 0.4 is encouraging, but what is y displaying?

I selected shift F1 [Δy/Δx]. After ~ 15s I get “Δ Num. differential” displayed to the left of the screen.

I hit OFF. — it displayed “OFF”. Then it displayed the thinking sand timer for several seconds and eventually turned off.

To get out of Draw mode, one needs to hit <- (clear). Hitting Exit quite the entire Solver. (I expect Exit to exit one menu-level…

I hit F2 [BOX] expecting the (0.52,2.9) (-0.025,-6.7) TL/BR coordinates to disappear — instead it thinks for ages again ~ 15s) and then appears to have done nothing.

Etc.

All very confusing (or at least, unexpected). All I’ve read is the WP43 section. Is there anything else? Am I just “doing it wrong”?
User avatar
Jaymos
Posts: 1635
Joined: Sun Nov 04, 2018 7:03 pm
Location: Cape Town

Re: C43/C47 Bug Reports

Post by Jaymos »

chris185 wrote:
Fri Jun 02, 2023 3:37 pm
Not sure whether this is a bug report, or just my lack of understand regarding The Solver:

In EQN I hit NEW and entered:

mix: tm = cc • tc + (1 - cc) • th

{tc: T-cold water, th: T-hot-water, cc: fraction which is cold, tm: resultant T-mixture}

Then I hit F6 [Solver] and get a menu containing the expected variables: tm cc tc th.

If I then enter

10 tc 60 th 0.5 cc tm

I get the expected 35.

And if I enter

40 th cc

I get the expected 0.4

So far so good.

Then I entered

0 cc 1 cc F5 [Draw]

I then get TWO sand-timer annunciations (the normal one and the one on the left (where the graph alphanumeric data goes).

I was expecting a graph of tm (y) against cc (x) ie. straight line from (0,60) to (1,10)

Instead I get a slight S curve (reflected), mostly a straight line from (0.35,2.5) to (0.47,-3.8) crossing at (0.4,0)

The 0.4 is encouraging, but what is y displaying?

I selected shift F1 [Δy/Δx]. After ~ 15s I get “Δ Num. differential” displayed to the left of the screen.

I hit OFF. — it displayed “OFF”. Then it displayed the thinking sand timer for several seconds and eventually turned off.

To get out of Draw mode, one needs to hit <- (clear). Hitting Exit quite the entire Solver. (I expect Exit to exit one menu-level…

I hit F2 [BOX] expecting the (0.52,2.9) (-0.025,-6.7) TL/BR coordinates to disappear — instead it thinks for ages again ~ 15s) and then appears to have done nothing.

Etc.

All very confusing (or at least, unexpected). All I’ve read is the WP43 section. Is there anything else? Am I just “doing it wrong”?
Thank you for the detailed report. Such detail helps.

Do check your statement and expected results for th = 40, you probably changed another variable as well or I think there might be a typo.

Either way, I worked through the first part of the example, and the reason for the graph not working is that the graphs work for an equation of the form "0 = f(x)" or just "f(x)" but not generally for "y = f(x)". This is because "Calc" works that way and Draw uses Calc to determine the graph. Your formula tm = cc • tc + (1 - cc) • th is in the form "tm = f (cc)" and to get a correct graph, it can work, but you need to zero tm first. The applies to Draw as well as Calc and applies equally for WP43 and C47 as the Calc code is shared. Your example with tm zeroed, below:
.
20230602-19103800.bmp
20230602-19103800.bmp (12.31 KiB) Viewed 1246 times
With th=40 and tc=10 and for cc running from 0 to 1, the graph is correct. The difference is you need to zero tm. If you don't zero tm, then the solver will do strange things.

When you press shift F1 [Δy/Δx] it will do a graphical numerical differentiation on the displayed samples and the result for a straight line of course is a constant. This negative slope is indicated as -30, which corresponds with the input of (10-40)/(1-0) = -30, and is displayed on the same set of axes, hence the scale change, see below:
.
20230602-19192800.bmp
20230602-19192800.bmp (12.31 KiB) Viewed 1246 times
The graphically determined slope indicated in the lower curve

The double timer icons are confusing and should be consolidated. I will put that on the bug list. The reason for that is, it shifts the timer to the left of the graph boundaries, but some part of the calculations insists on placing the timer icon in the usual place! That is a bug. I will investigate the menu flow later.

I did do the example on both simulator and hardware, and I can report that the hardware does it in about 3 seconds when on USB power. On battery it is around 15 seconds as you say.
Last edited by Jaymos on Fri Jun 02, 2023 7:57 pm, edited 1 time in total.
Jaco Mostert
Elec Eng, South Africa
https://47calc.com C47 (s/n 03818 & 06199), WP43 (0015). In box: HP42S, HP32Sii, WP34S&C, HP28C, HP35s, EL-506P, EL-W506, PB700; ex: FX702P, 11C, HP67 & HP85; iOS: 42s Byron, Free42+, WP31S/34S, HCalc.
User avatar
Jaymos
Posts: 1635
Joined: Sun Nov 04, 2018 7:03 pm
Location: Cape Town

Re: C43/C47 Bug Reports

Post by Jaymos »

Jaymos wrote:
Thu Jun 01, 2023 10:31 pm
chris185 wrote:
Thu Jun 01, 2023 2:43 pm
I managed to cause a crash :)

I _think _ what I do is try to call the Solver without having any Current Equation.
Thanks for reporting, we will investigate
Mihail has fixed the problem - you can test it in the next release.
Jaco Mostert
Elec Eng, South Africa
https://47calc.com C47 (s/n 03818 & 06199), WP43 (0015). In box: HP42S, HP32Sii, WP34S&C, HP28C, HP35s, EL-506P, EL-W506, PB700; ex: FX702P, 11C, HP67 & HP85; iOS: 42s Byron, Free42+, WP31S/34S, HCalc.
chris185
Posts: 31
Joined: Tue May 23, 2023 11:59 am

Re: C43/C47 Bug Reports

Post by chris185 »

Ah, thanks for the explanations!
Do check your statement and expected results for th = 40, you probably changed another variable as well or I think there might be a typo.
Yes. That was a typo. Should be ‘tm’. th stays at 60.


I was used to doing f(x) = 0 on the DM42 solver. I misunderstood (?) the WP43 docs on EQN.

The actual bug regarding the timer icons doesn’t appear to be particularly serious, imho.

I’m a bit puzzled by the execution speed though. The code doesn’t need to simulate (?) any ancient hardware. At what speed is the ARM actually running on the DM42 platform? Is it severely underclocked to reduce battery consumption?

I haven’t got around to looking at the code yet, but I intend to at some point (just out of interest — not implying I could do any better :-). [I’m more into ARM assembly code myself]
User avatar
ijabbott
Posts: 253
Joined: Fri Dec 15, 2017 2:34 pm
Location: GB-MAN

Re: C43/C47 Bug Reports

Post by ijabbott »

I managed to build the GTK3 simulation to run natively on Linux but I am having trouble getting any of the f/g-shifted functions to work, driving the simulation with the mouse. Every time I click on the shift button to select f or g, and then click on another button to select the shifted function, all it does is show the name of the function in the display, followed a second later by 'NOP'.

Could it be interpreting my mouse clicks as a long press or something?
User avatar
Jaymos
Posts: 1635
Joined: Sun Nov 04, 2018 7:03 pm
Location: Cape Town

Re: C43/C47 Bug Reports

Post by Jaymos »

ijabbott wrote:
Sat Jun 10, 2023 9:30 pm
I managed to build the GTK3 simulation to run natively on Linux but I am having trouble getting any of the f/g-shifted functions to work, driving the simulation with the mouse. Every time I click on the shift button to select f or g, and then click on another button to select the shifted function, all it does is show the name of the function in the display, followed a second later by 'NOP'.

Could it be interpreting my mouse clicks as a long press or something?
It is possible - this is the second time I hear of something like this. Have a look on this thread to see if something useful is said.

viewtopic.php?f=2&t=3452&p=26136&hilit=mouse#p26136



J
Jaco Mostert
Elec Eng, South Africa
https://47calc.com C47 (s/n 03818 & 06199), WP43 (0015). In box: HP42S, HP32Sii, WP34S&C, HP28C, HP35s, EL-506P, EL-W506, PB700; ex: FX702P, 11C, HP67 & HP85; iOS: 42s Byron, Free42+, WP31S/34S, HCalc.
User avatar
ijabbott
Posts: 253
Joined: Fri Dec 15, 2017 2:34 pm
Location: GB-MAN

Re: C43/C47 Bug Reports

Post by ijabbott »

Jaymos wrote:
Sun Jun 11, 2023 12:46 am
ijabbott wrote:
Sat Jun 10, 2023 9:30 pm
I managed to build the GTK3 simulation to run natively on Linux but I am having trouble getting any of the f/g-shifted functions to work, driving the simulation with the mouse. Every time I click on the shift button to select f or g, and then click on another button to select the shifted function, all it does is show the name of the function in the display, followed a second later by 'NOP'.

Could it be interpreting my mouse clicks as a long press or something?
It is possible - this is the second time I hear of something like this. Have a look on this thread to see if something useful is said.

viewtopic.php?f=2&t=3452&p=26136&hilit=mouse#p26136
I was indeed using a trackpad (built in to my Logitech wireless keyboard). I'll investigate further!

EDIT: Indeed it works if I press the physical "mouse left button" below the trackpad instead of tapping on the trackpad.

EDIT: I ran evtest to capture the input events from my keyboard/trackpad.

This is what was produced for a physical left button click:

Code: Select all

Event: time 1686485074.381406, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90001
Event: time 1686485074.381406, type 1 (EV_KEY), code 272 (BTN_LEFT), value 1
Event: time 1686485074.381406, -------------- SYN_REPORT ------------
Event: time 1686485074.509436, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90001
Event: time 1686485074.509436, type 1 (EV_KEY), code 272 (BTN_LEFT), value 0
Event: time 1686485074.509436, -------------- SYN_REPORT ------------
This is what was produced when the trackpad was tapped a couple of seconds later:

Code: Select all

Event: time 1686485076.817351, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90001
Event: time 1686485076.817351, type 1 (EV_KEY), code 272 (BTN_LEFT), value 1
Event: time 1686485076.817351, -------------- SYN_REPORT ------------
Event: time 1686485076.827392, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90001
Event: time 1686485076.827392, type 1 (EV_KEY), code 272 (BTN_LEFT), value 0
Event: time 1686485076.827392, -------------- SYN_REPORT ------------
Note that the events for the simulated button click produced when tapping the trackpad were not produced until the finger was lifted, so it is not possible to simulate a long press using this method.

The only difference between the two sets of events seems to be that the timing between press and release is shorter (only 10 ms between press and release) for the simulated button click.
avosough
Posts: 90
Joined: Tue May 30, 2023 3:14 am
Location: USA

Re: C43/C47 Bug Reports

Post by avosough »

I'm not sure if this is a bug or a poorly formed program. I work with feet and inches a lot in my work (hold any comments!), so I have recreated programs from my hp 50g on C47. My program to convert feet on Y register and inches on X register to a decimal feet value on the X register works just fine. Very simple.

A second program should convert a decimal feet value on the X register to feet on the Y register and decimal inches on the X register. I've tried this two different ways (see below), and both times repeated testing gives the correct result about 70% of the time and falsely gives 0 on the X register the other 30% or so. I can't tell any trend about stack contents affecting the results, but it has never failed when stepping through the program with the arrow keys or using R/S.

First version, matching my 50g program:

Code: Select all

LBL '->0'-0"'
ENTER
floor
X<>Y
12.
*
12.
MOD
END
Second attempt:

Code: Select all

LBL '->0'-0"'
ENTER
IP
X<>Y
FP
12.
*
END
So if I have 19.083 on the X register, running the program should return 19 on Y and 0.996 on X but sometimes will return 19 on Y and 0. on X. Am I doing something wrong?
User avatar
Jaymos
Posts: 1635
Joined: Sun Nov 04, 2018 7:03 pm
Location: Cape Town

Re: C43/C47 Bug Reports

Post by Jaymos »

avosough wrote:
Sat Jun 17, 2023 4:53 pm
I'm not sure if this is a bug or a poorly formed program. I work with feet and inches a lot in my work (hold any comments!), so I have recreated programs from my hp 50g on C47. My program to convert feet on Y register and inches on X register to a decimal feet value on the X register works just fine. Very simple.

A second program should convert a decimal feet value on the X register to feet on the Y register and decimal inches on the X register. I've tried this two different ways (see below), and both times repeated testing gives the correct result about 70% of the time and falsely gives 0 on the X register the other 30% or so. I can't tell any trend about stack contents affecting the results, but it has never failed when stepping through the program with the arrow keys or using R/S.

First version, matching my 50g program:

Code: Select all

LBL '->0'-0"'
ENTER
floor
X<>Y
12.
*
12.
MOD
END
Second attempt:

Code: Select all

LBL '->0'-0"'
ENTER
IP
X<>Y
FP
12.
*
END
So if I have 19.083 on the X register, running the program should return 19 on Y and 0.996 on X but sometimes will return 19 on Y and 0. on X. Am I doing something wrong?
You spotted a bug on the eRPN. And I fixed it already. We are working on an eminent release and this will be included in the release.
In the mean time, a workaround would be to program a "Duplicate X" replacement function using STO/RCL as follows:

Workaround, using register K:

Code: Select all

LBL '->0'-0"'
STO K
RCL K
IP
X<>Y
FP
12.
*
END
Jaco Mostert
Elec Eng, South Africa
https://47calc.com C47 (s/n 03818 & 06199), WP43 (0015). In box: HP42S, HP32Sii, WP34S&C, HP28C, HP35s, EL-506P, EL-W506, PB700; ex: FX702P, 11C, HP67 & HP85; iOS: 42s Byron, Free42+, WP31S/34S, HCalc.
dlachieze
Posts: 613
Joined: Thu May 04, 2017 12:20 pm
Location: France

Re: C43/C47 Bug Reports

Post by dlachieze »

Jaymos wrote:
Sat Jun 17, 2023 7:15 pm
Workaround, using register K:

Code: Select all

LBL '->0'-0"'
STO K
RCL K
IP
X<>Y
FP
12.
*
END
Even simpler with just the LastX register :

Code: Select all

LBL '->0'-0"'
IP
RCL L 
FP
12.
*
END
DM42: 00425 - DM41X: β00066 - WP43: 00042
Post Reply