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.
C47 Bug Reports
Re: C43 Bug Reports
Thinking further J->D could accept a real and return the time of day too.
Re: C43 Bug Reports
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.
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
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.
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
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.pauli wrote: ↑Fri Nov 25, 2022 9:40 pmJ->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.
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.
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
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 displaygmac42 wrote: ↑Fri Nov 25, 2022 5:26 pmNot 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...
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
Re: C43 Bug Reports
Yes - good ideaJaymos wrote: ↑Sat Nov 26, 2022 7:25 amThe 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.
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
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
Ok. Sounds good.rudi wrote: ↑Sat Nov 26, 2022 12:15 pmYes - good ideaJaymos wrote: ↑Sat Nov 26, 2022 7:25 amThe 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.
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.
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.
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 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.
Re: C43 Bug Reports
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.