Fábio Beirão (May 26 2023 at 10:53): Fábio Beirão (May 26 2023 at 10:53):Hello. For some context, my background is c#/dotnet. I am reading the docs for Num.toStr and I see "Only [Frac] values will include a decimal point, and they will always include one". This has rung a past nightmare bell in my head where we had some software that would behave differently on dev machines versus production because of Windows regional settings. On two different machines, the same pseudo-operation "Num.toStr 5.0" would either produce 5.0 or 5,0 depending on regional settings. Same thing for larger numbers, where you could get outputs such as 1.234,00.
I don't know enough about Roc to know if this will be a problem or not, but I haven't (yet!) encountered an explicit indication in the docs that the formatting would behave as such or such. I'll keep reading of course, but just wanted to drop this message here in case this was overlooked, or perhaps not even a problem at all.
Hannes (May 26 2023 at 12:09):I guess because Roc is a pure language, that kind of region information is external state that the Roc won't have access to, so it should always be consistent.
Fábio Beirão (May 26 2023 at 12:13):That would be great, as it would reduce the number of gotchas. If the user wishes for fancier formatting, then Num.format would be the place for that.
If there is indeed a fixed and stable output format for Num.toStr then it could be stated more explicitly in the docs.
Sky Rose (May 26 2023 at 12:14):Should there be "Num.toLocaleStr" that takes in a locale? Some people might want that in their app and have a way to get the locale from the platform. But I guess that's pretty complicated and would belong in a separate localization package that's not in the standard library.
Richard Feldman (May 26 2023 at 12:47):yeah that's what I'd like to do
Richard Feldman (May 26 2023 at 12:47):is have a separate locale package which takes care of that
Richard Feldman (May 26 2023 at 12:47):I think there may need to be a primitive in the standard library which that package can use though
Richard Feldman (May 26 2023 at 12:48):(e.g. a way to get the number before the decimal point, and the number after the decimal point, as integers perhaps?)
Brendan Hansknecht (May 26 2023 at 13:15):Is that possible to do in a reasonable way with floats?
Brendan Hansknecht (May 26 2023 at 13:16):Cause i think there are different options for the numbers after a decimal point with floats
Richard Feldman (May 26 2023 at 16:20):yeah I'm not sure exactly what the best API is there
Richard Feldman (May 26 2023 at 16:21):e.g. could try to produce a U64 of all the digits after the decimal point, but maybe that's not what people really want
Richard Feldman (May 26 2023 at 16:22):I could see something like Num.walkFracDigits or something that just gives you one digit at a time as a U8, so you can stringify them, add punctuation, etc. I think any "rendering numbers to a string" function would need to do that work anyway probably
Brendan Hansknecht (May 26 2023 at 16:24):What do you do for infinitely repeating numbers and such?
Richard Feldman (May 26 2023 at 16:25):those are truncated in the in-memory representation of the number anyway
Brendan Hansknecht (May 26 2023 at 16:31):true, but: 1.40129846432481707092372958328991613128026194187651577175706828388979108268586060148663818836212158203125E-45 is the exact digits of an F32. Just imagine an F64.
Richard Feldman (May 26 2023 at 16:33):sure - but is that a problem? :big_smile:
Brendan Hansknecht (May 26 2023 at 16:37):kinda:
Brendan Hansknecht (May 26 2023 at 16:42):From https://www.h-schmidt.net/FloatConverter/IEEE754.html an online f32 converter:
I've converted a number to floating point by hand/some other method, and I get a different result. Your converter is wrong!
Possible, but unlikely. The conversion routines are pretty accurate (see above). Until now, checking the results always proved the other conversion less accurate. First, consider what "correct" means in this context - unless the conversion has no rounding error, there are two reasonable results, one slightly smaller the entered value and one slightly bigger. The best result is usually the one closer to the value that was entered, so you should check for that. Please check the actual represented value (second text line) and compare the difference to the expected decimal value while toggling the last bits.
Richard Feldman (May 26 2023 at 16:49):People may accidentally write really slow code
maybe, but is that preventable if we want to give them access to enough digits to decide how they want to format them based on locale etc? :big_smile:
Brendan Hansknecht (May 26 2023 at 17:09)::shrug:
Fábio Beirão (May 26 2023 at 17:28):I haven't yet found the docs for Num.format
Naively speaking I would be okay with Num.toStr using some kind of sane but fixed standard (whatever that means, dot as decimal, two decimals, truncated..ouch so many decisions). As long as it would be explicit in the docs and always fixed. For fancier formatting, Num. format to the rescue
Honestly what I'm trying to avoid is the wtfs I found in dotnet (due to my own ignorance about global implicit localization)
Brendan Hansknecht (May 26 2023 at 17:33):It doesn't exist yet. Just an idea
Brendan Hansknecht (May 26 2023 at 17:35):Fundamentally, I think it is wise to keep localization out of the standard library and enable it in ecosystem libraries.
Richard Feldman (May 26 2023 at 18:25):Fundamentally, I think it is wise to keep localization out of the standard library and enable it in ecosystem libraries.
yeah I strongly agree - especially for a purely functional language; to the extent possible, I very much want to avoid "the same pure function called with the same arguments returns a different answer on one system vs another"
Richard Feldman (May 26 2023 at 18:26):either it should give the same answer or else it should crash due to system resource limitations (e.g. available memory) that existed on one system but not the other
Richard Feldman (May 26 2023 at 18:28):(which is part of the motivation for #ideas > replace Nat)
Last updated: Jul 06 2025 at 12:14 UTC