C47 Bug Reports
C47 Bug Reports
Bugs can be reported here
Last edited by Jaymos on Sun Sep 24, 2023 9:33 pm, edited 3 times 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 Bug Reports
I followed the exact steps on Sim as well as on my C43 and it works in the sense that it does not stop with that message.rudi wrote: ↑Thu Nov 24, 2022 9:21 pmWhere do we report bugs in the C43?
Will not spam the WP43 bug thread.
I’ve found one:
UNIT
DATE
D->J
1
+
J->D
results in “Invalid input data type for this operation”
As an enthusiastic amateur astronomer, I am very happy, that Julian Day is implemented, but I would expect to do arithmetic operations on a JD and then convert back to a date.
Same error if I enter a JD manually and execute J->D
I note however that on mine the date is not displayed correctly and this could be part of the reason it does not work (on yours). Either way I can see there is a bug of some kind and I will list a bug - lets fix the bug I can consistently see, then see if your bug is still present.
BTW, I assumed you meant CLK not UNIT.
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 Bug Reports
Yes, from the CLK menu..
When I press DATE in the CLK menu, I get "Friday 0000-2022-00".
I also tried entering yesterdays (24/11-2022 00:00:00.0) JD, which is 2459907.5 and execute J->D, which gives the same error message.
So I guess there's something fischy with both the DATE and J->D functions?
When I press DATE in the CLK menu, I get "Friday 0000-2022-00".
I also tried entering yesterdays (24/11-2022 00:00:00.0) JD, which is 2459907.5 and execute J->D, which gives the same error message.
So I guess there's something fischy with both the DATE and J->D functions?
/Rudi
DM-42 (s/n 06999), HP-42S, HP-35s, HP-11c, HP-32SII (ex HP-41CV, ex HP-75C, ex HP-48G + a lot, really lot of a accessories)
Denmark
DM-42 (s/n 06999), HP-42S, HP-35s, HP-11c, HP-32SII (ex HP-41CV, ex HP-75C, ex HP-48G + a lot, really lot of a accessories)
Denmark
Re: C43 Bug Reports
Definitely a bug. It is listed as such and will be fixed.rudi wrote: ↑Fri Nov 25, 2022 4:34 amYes, from the CLK menu..
When I press DATE in the CLK menu, I get "Friday 0000-2022-00".
I also tried entering yesterdays (24/11-2022 00:00:00.0) JD, which is 2459907.5 and execute J->D, which gives the same error message.
So I guess there's something fischy with both the DATE and J->D functions?
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 Bug Reports
Almost confirmed: if I try 2459907.5 and execute J->D then "Invalid input data type..." is thrown. If, however, I look up J->D in the ReM, I learn that this command operates on long integers only. And now I know why it didn't work, don't I?
Last edited by Walter on Fri Nov 25, 2022 9:26 am, edited 1 time in total.
WP43 SN00000, 34S, and 31S for obvious reasons; HP-35, 45, ..., 35S, 15CE, DM16L S/N# 00093, DM42β SN:00041
Re: C43 Bug Reports
Thanks for the info Walter. Julian date must definetly be able to handle decimal numbers, if you're using it for astronomy.
/Rudi
DM-42 (s/n 06999), HP-42S, HP-35s, HP-11c, HP-32SII (ex HP-41CV, ex HP-75C, ex HP-48G + a lot, really lot of a accessories)
Denmark
DM-42 (s/n 06999), HP-42S, HP-35s, HP-11c, HP-32SII (ex HP-41CV, ex HP-75C, ex HP-48G + a lot, really lot of a accessories)
Denmark
Re: C43 Bug Reports
Yes in principle but D->J operates on dates and returns long integers only and vice versa J->D operates on long integers and returns dates only. We support just dates but not date-times (combinations of date and time) so far.
WP43 SN00000, 34S, and 31S for obvious reasons; HP-35, 45, ..., 35S, 15CE, DM16L S/N# 00093, DM42β SN:00041
Re: C43 Bug Reports
Ah ok, then I'll just need to divide the decimal time with 24 and do the decimal math. It would be extremely useful with date/time to JD.
/Rudi
DM-42 (s/n 06999), HP-42S, HP-35s, HP-11c, HP-32SII (ex HP-41CV, ex HP-75C, ex HP-48G + a lot, really lot of a accessories)
Denmark
DM-42 (s/n 06999), HP-42S, HP-35s, HP-11c, HP-32SII (ex HP-41CV, ex HP-75C, ex HP-48G + a lot, really lot of a accessories)
Denmark
Re: C43 Bug Reports
Not sure if this is a bug, but it's at least unexpected behavior:
Sometimes fractions are not displayed as entered, but instead as an approximation. for example:
2/3 -> "<0 43/64"
1 [ENTER] 7 [/] -> ">0 9/64"
but on the other hand:
1/2 -> "1/2"
0.75 -> "0 3/4"
3 [ENTER] 8 [/] -> "0 3/8"
So I'm guessing it affects only fractions whose decimal representation has too many (i.e. infinite) digits.
I understand why the approximated display is useful, especially when it comes to results of calculations, but I don't see why you would use 43/64 as an approximation of 2/3, when 2/3 is a much better (and more concise) approximation of 2/3, and I even gave a pretty obvious hint about that by entering [.]2[.]3.
EDIT: Okay, it's obviously trying to display everything as /2, /4, ... /64.
Looking at the "a b/64" in the status bar, I feel like I am missing something obvious here - time to read the fine manual...
Sometimes fractions are not displayed as entered, but instead as an approximation. for example:
2/3 -> "<0 43/64"
1 [ENTER] 7 [/] -> ">0 9/64"
but on the other hand:
1/2 -> "1/2"
0.75 -> "0 3/4"
3 [ENTER] 8 [/] -> "0 3/8"
So I'm guessing it affects only fractions whose decimal representation has too many (i.e. infinite) digits.
I understand why the approximated display is useful, especially when it comes to results of calculations, but I don't see why you would use 43/64 as an approximation of 2/3, when 2/3 is a much better (and more concise) approximation of 2/3, and I even gave a pretty obvious hint about that by entering [.]2[.]3.
EDIT: Okay, it's obviously trying to display everything as /2, /4, ... /64.
Looking at the "a b/64" in the status bar, I feel like I am missing something obvious here - time to read the fine manual...
Last edited by gmac42 on Fri Nov 25, 2022 5:40 pm, edited 1 time in total.
DM41X #542, DM42 #650, DM41L #801, HP 41CX, HP 41CV, HP 50G, HP11C, TI 89
Re: C43 Bug Reports
On a semi-related note, when I tried to enter 2.333333333333333333333333333333333333333333333333 to see if I would get "2 1/3", I noticed that the input was getting noticeably slower the longer the number got, up to the point where it took about a second per digit. Jaco already wrote in an earlier post that there is still stuff to be optimized, so I guess this will be among those things; I just wanted to mention it in case you weren't aware.
DM41X #542, DM42 #650, DM41L #801, HP 41CX, HP 41CV, HP 50G, HP11C, TI 89