C47 Bug Reports

This area is for discussion about these families of custom high-end Scientific Calculator applications for SwissMicros devices.
Post Reply
User avatar
Jaymos
Posts: 1633
Joined: Sun Nov 04, 2018 7:03 pm
Location: Cape Town

C47 Bug Reports

Post by Jaymos »

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.
User avatar
Jaymos
Posts: 1633
Joined: Sun Nov 04, 2018 7:03 pm
Location: Cape Town

Re: C43 Bug Reports

Post by Jaymos »

rudi wrote:
Thu Nov 24, 2022 9:21 pm
Where 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 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.

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.
User avatar
rudi
Posts: 413
Joined: Wed Nov 03, 2021 9:03 am
Location: Denmark
Contact:

Re: C43 Bug Reports

Post by rudi »

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?
/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
User avatar
Jaymos
Posts: 1633
Joined: Sun Nov 04, 2018 7:03 pm
Location: Cape Town

Re: C43 Bug Reports

Post by Jaymos »

rudi wrote:
Fri Nov 25, 2022 4:34 am
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?
Definitely a bug. It is listed as such and will be fixed.
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
Walter
Posts: 3070
Joined: Tue May 02, 2017 11:13 am
Location: On a mission close to DRS, Germany

Re: C43 Bug Reports

Post by Walter »

rudi wrote:
Fri Nov 25, 2022 4:34 am
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.
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. :o 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
User avatar
rudi
Posts: 413
Joined: Wed Nov 03, 2021 9:03 am
Location: Denmark
Contact:

Re: C43 Bug Reports

Post by rudi »

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
User avatar
Walter
Posts: 3070
Joined: Tue May 02, 2017 11:13 am
Location: On a mission close to DRS, Germany

Re: C43 Bug Reports

Post by Walter »

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
User avatar
rudi
Posts: 413
Joined: Wed Nov 03, 2021 9:03 am
Location: Denmark
Contact:

Re: C43 Bug Reports

Post by rudi »

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
gmac42
Posts: 103
Joined: Fri Jun 01, 2018 11:30 am

Re: C43 Bug Reports

Post by gmac42 »

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...
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
gmac42
Posts: 103
Joined: Fri Jun 01, 2018 11:30 am

Re: C43 Bug Reports

Post by gmac42 »

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
Post Reply