Sometimes you want to make it easy for programmers to see quickly =P That and avoids the arguments about the exact format to use (pragmatic vs ideal vs let's overengineer it because enterprise say so), if you store a floating point number as text, then the binary format is up to the parser. (also for some kinds of data heavy on numbers it turns out they can compress better)Brendan wrote:If it's meant for computers it becomes easy - use binary instead of text. If you must use text, then go "concise and precise" with hexadecimal (e.g. maybe "0x1234567 >> 16").
Still better than nothing, if you're going to complain about failing something as simple as grouping (which the standard library does handle). So in that sense there's no excuse, other than most programmers likely not even being aware or outright not caring (in fact I have never bothered to look into it yet - come kill me =P).Brendan wrote:I'm not sure that it's possible for someone to care enough about Internationalisation to be willing to use what C provides, while also caring so little about Internationalisation that they're willing to use what C provides.
Maybe the biggest problem is precisely that it's not blatantly easy to use, would have been nice if it was a parameter to printf-style arguments (then everybody would learn it exists when they're taught the list of modifiers). Similar deal for whatever else any other language prefers to use.
In any case, going back on topic, that probably should be seen as an enhancement to the base algorithm =P (if you can get the number as a string in the most simple way possible, you can start tacking on whatever else is needed on top of it)
It's related! (and that most keyboard layouts make it too hard to type ×... I have it mapped on an AltGr key and none of those other than @ and € are labeled on the keyboard at all, nor do many people know that AltGr gives more shift levels)Brendan wrote:I'd be tempted to blame ASCII for "lower case x" (e.g. "1920x1200") too.