Talk:Getting the number of decimal places: Difference between revisions
Talk:Getting the number of decimal places (view source)
Revision as of 06:55, 21 March 2023
, 1 year ago→C/C++ marked incorrect
| (2 intermediate revisions by 2 users not shown) | |||
Line 61:
: The task description gives 2 examples, one of which is " for num = 12.3450 decimals = 4" so for 12.0 and 12.345000 how many decimals do you think should be reported? How does this compare with the C output?--[[User:Nigel Galloway|Nigel Galloway]] ([[User talk:Nigel Galloway|talk]]) 15:40, 20 March 2023 (UTC)
:: Oh yes indeed, by that definition I'd have to say the FreeBASIC, Haskell, Java, Kotlin, Ring, RPL (probably), Sidef entries are all equally "wrong". Personally I want to say that 12.3450 should have 3 decimal places, even though my own entry shows 4 for "12.3450", but in reality 12.345 is held as ~12.3450000000000006 in a 64-bit IEE754 float, and as ~12.34500000000000000024 in an 80-bit float, so that would be 16 and 20 decimals, at least in some "sense". Stupid task. Anyway, you (by which I mean Peak) either have to be consistent and badger everyone, or no-one, or better yet fix the stupid task description (after discussing it here first). --[[User:Petelomax|Petelomax]] ([[User talk:Petelomax|talk]]) 16:08, 20 March 2023 (UTC)
:::Well, stupid or not, the task is what it is. As the original author hasn't been around lately, I've fixed the C/C++ entries using strings rather than doubles as there's no way those languages can distinguish between 12.345 and 12.3450 otherwise. --[[User:PureFox|PureFox]] ([[User talk:PureFox|talk]]) 17:56, 20 March 2023 (UTC)
:::: Good-oh. My main concern was that C/C++ were being unfairly picked on and "incorrect" was just as imprecise as the tesk description. --[[User:Petelomax|Petelomax]] ([[User talk:Petelomax|talk]]) 06:55, 21 March 2023 (UTC)
| |||