C47 Bug Reports

This area is for discussion about these families of custom high-end Scientific Calculator applications for SwissMicros devices.
User avatar
pauli
Posts: 251
Joined: Tue May 02, 2017 10:11 am
Location: Australia

Re: C43 Bug Reports

Post by pauli »

J->D should accept either a long integer or a real (truncating any fractional part).
It probably should also accept a short integer.
Doing anything else is crazy IMO.

This should generalise to all functions. If a scalar number in one format is supported, they all should be.
User avatar
pauli
Posts: 251
Joined: Tue May 02, 2017 10:11 am
Location: Australia

Re: C43 Bug Reports

Post by pauli »

Thinking further J->D could accept a real and return the time of day too.
User avatar
Jaymos
Posts: 1633
Joined: Sun Nov 04, 2018 7:03 pm
Location: Cape Town

Re: C43 Bug Reports

Post by Jaymos »

pauli wrote:
Sat Nov 26, 2022 3:00 am
Thinking further J->D could accept a real and return the time of day too.
I like that. Simple solution. Time in Y and date in X.
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 »

Jaymos wrote:
Sat Nov 26, 2022 7:02 am
pauli wrote:
Sat Nov 26, 2022 3:00 am
Thinking further J->D could accept a real and return the time of day too.
I like that. Simple solution. Time in Y and date in X.
The reverse is not so simple. The J->D solution proposed by pauli is good but the symmetrical inverse is bothering me. Currently D->J is easy to operate using only a simple date as input. If it would always require a time in Y, it would be cumbersome as time is not always needed. I propose to rather add two new functions J->DT and DT->J to cover the real case with date and time.
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 »

pauli wrote:
Fri Nov 25, 2022 9:40 pm
J->D should accept either a long integer or a real (truncating any fractional part).
It probably should also accept a short integer.
Doing anything else is crazy IMO.

This should generalise to all functions. If a scalar number in one format is supported, they all should be.
C43 already has multiple occasions where type checking such as this case has been relaxed. Generally (unless there is a reason not to) we aim to have no messages of incorrect type where it may be obvious and legal to truncate a real, or to internally convert a short integer to a long integer.

If the real Real case would be handled by J->DT then J->D should truncate the real and move on without error.
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
RJvM
Posts: 276
Joined: Wed Jun 02, 2021 9:21 am
Location: Gelderland, Netherlands

Re: C43 Bug Reports

Post by RJvM »

gmac42 wrote:
Fri Nov 25, 2022 5:26 pm
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...
Take a look at DENANY and DENMAX settings. These control this behaviour. On C43, there's also EXFRAC to recognise some math constants in fractions display
Robbert Jan, MSEE, RPN user since 1976 and a collector for many years I now own all the important ones: HP-35, 45, 55, 65, 97, 19, 21, 25, 34, 10-16, 41, 42, 71, 48, 50, Prime, DM41, DM42, WP43, C47, R47; Project 47 team member https://47calc.com
User avatar
rudi
Posts: 413
Joined: Wed Nov 03, 2021 9:03 am
Location: Denmark
Contact:

Re: C43 Bug Reports

Post by rudi »

Jaymos wrote:
Sat Nov 26, 2022 7:25 am
Jaymos wrote:
Sat Nov 26, 2022 7:02 am
pauli wrote:
Sat Nov 26, 2022 3:00 am
Thinking further J->D could accept a real and return the time of day too.
I like that. Simple solution. Time in Y and date in X.
The reverse is not so simple. The J->D solution proposed by pauli is good but the symmetrical inverse is bothering me. Currently D->J is easy to operate using only a simple date as input. If it would always require a time in Y, it would be cumbersome as time is not always needed. I propose to rather add two new functions J->DT and DT->J to cover the real case with date and time.
Yes - good idea

X: decimal jd
J->D => date in Y, time in X

Reverse:
Y: Date, X: Time
D->J => a decimal julian date in X

And special case, if there's a DATE in X, then assume time is 00:00:00 and return decimal julian date in X {some number}.5

Also, remember to add to the manual p. 199'ich, that the time is UTC.
/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:
Sat Nov 26, 2022 12:15 pm
Jaymos wrote:
Sat Nov 26, 2022 7:25 am
Jaymos wrote:
Sat Nov 26, 2022 7:02 am


I like that. Simple solution. Time in Y and date in X.
The reverse is not so simple. The J->D solution proposed by pauli is good but the symmetrical inverse is bothering me. Currently D->J is easy to operate using only a simple date as input. If it would always require a time in Y, it would be cumbersome as time is not always needed. I propose to rather add two new functions J->DT and DT->J to cover the real case with date and time.
Yes - good idea

X: decimal jd
J->D => date in Y, time in X

Reverse:
Y: Date, X: Time
D->J => a decimal julian date in X

And special case, if there's a DATE in X, then assume time is 00:00:00 and return decimal julian date in X {some number}.5

Also, remember to add to the manual p. 199'ich, that the time is UTC.
Ok. Sounds good.

I prefer the simplicity of two new commands combining time and date, than gymnastics on whether or not date/time is present in the stack or not.
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
pauli
Posts: 251
Joined: Tue May 02, 2017 10:11 am
Location: Australia

Re: C43 Bug Reports

Post by pauli »

I arrived at the solution of having seperate commands for the time over night. I was thinking of a command taking a fractional real and returning time of day (i.e. multiply the 0-1 value by 24 hours with suitable offset and build a time from there) but J->DT works better.
User avatar
pauli
Posts: 251
Joined: Tue May 02, 2017 10:11 am
Location: Australia

Re: C43 Bug Reports

Post by pauli »

The time won't be UTC. UTC unfortunately includes leap seconds and we'd need a database of these to do the conversion correctly (there is only about thirty so it's not too difficult). Easier and simpler to just use TAI.
Post Reply