C47 Bug Reports
Re: C43/C47 Bug Reports
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”?
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”?
Re: C43/C47 Bug Reports
Thank you for the detailed report. Such detail helps.chris185 wrote: ↑Fri Jun 02, 2023 3:37 pmNot 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”?
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:
. 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:
. 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.
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.
Re: C43/C47 Bug Reports
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.
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.
Re: C43/C47 Bug Reports
Ah, thanks for the explanations!
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]
Yes. That was a typo. Should be ‘tm’. th stays at 60.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.
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]
Re: C43/C47 Bug Reports
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?
Could it be interpreting my mouse clicks as a long press or something?
Re: C43/C47 Bug Reports
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.ijabbott wrote: ↑Sat Jun 10, 2023 9:30 pmI 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?
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.
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.
Re: C43/C47 Bug Reports
I was indeed using a trackpad (built in to my Logitech wireless keyboard). I'll investigate further!Jaymos wrote: ↑Sun Jun 11, 2023 12:46 amIt 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.ijabbott wrote: ↑Sat Jun 10, 2023 9:30 pmI 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?
viewtopic.php?f=2&t=3452&p=26136&hilit=mouse#p26136
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 ------------
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 ------------
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.
Re: C43/C47 Bug Reports
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:
Second attempt:
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?
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
Code: Select all
LBL '->0'-0"'
ENTER
IP
X<>Y
FP
12.
*
END
Re: C43/C47 Bug Reports
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.avosough wrote: ↑Sat Jun 17, 2023 4:53 pmI'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:Second attempt:Code: Select all
LBL '->0'-0"' ENTER floor X<>Y 12. * 12. MOD 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?Code: Select all
LBL '->0'-0"' ENTER IP X<>Y FP 12. * END
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.
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.
Re: C43/C47 Bug Reports
Even simpler with just the LastX register :Jaymos wrote: ↑Sat Jun 17, 2023 7:15 pmWorkaround, using register K:Code: Select all
LBL '->0'-0"' STO K RCL K IP X<>Y FP 12. * END
Code: Select all
LBL '->0'-0"'
IP
RCL L
FP
12.
*
END
DM42: 00425 - DM41X: β00066 - WP43: 00042