LWN: Comments on "What's coming in glibc 2.10"

Why the vehement objections to decimal floating-point?

stevenj — Mon, 18 Apr 2011 22:37:11 +0000

Your example makes no sense; the result would be computed exactly in decimal floating point.

More generally, in essentially any case where decimal fixed point with N digits would produce exact results, decimal floating point with an N-digit significand would also produce exact results. The only sacrifice in going from fixed to (decimal) floating point is that you lose a few bits of precision to store the exponent, and in exchange you get vastly bigger dynamic range and much more sensible roundoff characteristics.

You're certainly right that many people don't have a correct mental model of floating point, however.

wchar_t

pixelpapst — Thu, 30 Apr 2009 17:27:53 +0000

> I expect one day the idea of choosing a font based on national context will be abandoned, and the code point count will finally explode, defining one Unicode character per glyph.

I agree. And I think when this happens, we just *might* see a revival of UTF-16 in Asia - in a modal form. So you wouldn't repeat the high-order surrogate when it is the same as that of the previous non-BMP character.

This would pack these texts a bit tighter than UTF-8 or UCS-4 (can encode 10 bits per low-order surrogate), while being a bit easier to parse than all the Escape-Sequence modal encodings.

IMHO, let's see.

Why the vehement objections to decimal floating-point?

dmag — Sat, 25 Apr 2009 12:29:56 +0000

Fixed-point won't loose information on simple calculations, but there is a possibility some intermediate results will saturate your representation. For example, if you square a number, add 1 and take the square root. For large numbers, the square isn't likely to be representable.

Floating point has the opposite problem. The intermediate calculations won't blow up, but you can lose precision even in simple cases.

Most people don't have a correct mental model of floating point. Floating point has a reputation for being 'lossy' because it can loose information in non-obvious ways.

$ irb
>> 0.1 * 0.1 - 0.01
=> 1.73472347597681e-18

Sometimes the answer is to store in fixed point, but calculate in floating point (and do appropriate rounding during conversion back to fixed).

What's coming in glibc 2.10: XML

jordanb — Wed, 22 Apr 2009 18:56:14 +0000

Heh. I was cringing when I submitted that because I was sure I'd make a mistake. I thinking too hard about making sure there were commas were all in order. :P

What's coming in glibc 2.10: XML

bronson — Wed, 22 Apr 2009 18:51:44 +0000

This is actually invalid JSON. You need to quote the key names:

"hlt_bug" : false,
"f00f_bug" : false,
"coma_bug" : false,

Even so, I'd still much rather work with JSON than XML!

What's coming in glibc 2.10: XML

jordanb — Wed, 22 Apr 2009 16:11:09 +0000

Of course that looked nicer before lwn nuked my whitespace but you get the idea.

What's coming in glibc 2.10: XML

jordanb — Wed, 22 Apr 2009 16:09:58 +0000

JSON was designed to be a pure subset of Javascript so they could
market it for web development as a way to send data out to your
client-side JS by simply serializing JSON objects into <script>
tags in the webpage. That's the only reason for the focus on
Javascript -- not to rely on the ECMAScript standard. In fact the
only reference to ECMAScript is informational:

"JavaScript Object Notation (JSON) is a text format for the
serialization of structured data. It is derived from the object
literals of JavaScript, as defined in the ECMAScript Programming
Language Standard, Third Edition [ECMA]."

The standard is so small because it only has six data
types ('object' (essentially associative array), list, number,
boolean, string, and 'null'). It has no ability to do node
attributes and is only tree-based to the extent that objects and
arrays can contain more of them. It is certianly not a rival to
XML for dealing with large scale or very complicated or nuanced
data. But it is an excellent alternative when you have small
amounts of structured data that you wish to serialize.

Another advantage of JSON is that if you have simple mostly
tabular datasets they can be serialized (with judicious use of
whitespace) in a manner that's both machine and
human-readable. For fun and as an example I decided to 'encode'
my /proc/cpuinfo in JSON:

[{
processor : 0,
vendor_id : "GenuineIntel",
cpu_family : "6",
model : "8",
model_name : "Pentium III (Coppermine)",
stepping : 1,
cpu_MHz : 498.283,
cache_size : [ 262144, "256 KB" ],
fdiv_bug : false,
hlt_bug : false,
f00f_bug : false,
coma_bug : false,
fpu : true,
fpu_exception : true,
cpuid_level : 2,
wp : true,
flags : [ "fpu", "vme", "de", "pse", "tsc", "msr", "pae", "mce", "cx8",
"sep", "mtrr", "pge", "mca", "cmov", "pat", "pse36", "mmx", "fxsr", "sse", "up" ],
bogomips : 997.69,
clflush_size : 32
}]

What's coming in glibc 2.10: XML

dlang — Wed, 22 Apr 2009 04:15:55 +0000

the JSON spec is defining a subset of javascript. does it really fully define everything in it? or does it refer you to the main javascript definitions for the gory details and corner cases?

What's coming in glibc 2.10: XML

jordanb — Tue, 21 Apr 2009 21:56:43 +0000

I haven't read it in its entirety. It does seem to be well written, I'll agree to that.

The JSON spec is terse but it also rigorously defines the syntax of a very simple data serialization format. There are no omissions that make it incomplete. This is the advantage of JSON for simple data serialization tasks.

What's coming in glibc 2.10: XML

bvdm — Tue, 21 Apr 2009 04:24:16 +0000

Have you read it? It is wonderfully complete and quite educational. If the JSON spec was as well written it would probably be about 3/4 the length.

wchar_t

xoddam — Tue, 21 Apr 2009 01:19:52 +0000

On the other hand, pinyin is pretty much universal on the mainland, often as a way of specifying regional or personal pronunciation.

Vietnam has successfully switched (almost) entirely from han tu to the Latin alphabet, albeit with a forest of diacritics. Chinese might one day do the same, but it's unlikely since there is such a variety of Chinese speech and usage. Unlike Vietnamese, Chinese national identity has never been a matter of shared pronunciation.

Both pinyin and bopomofo have some chance of evolving to make it possible to write both pronunciation and semantics reproducibly in the same representation, but neither is likely to become a universal replacement for hanzi, since they lose the advantage (not meaningfully damaged by the Simplified/Traditional split) that the several very different Chinese languages become mutually intelligible when written down.

Universal alphabetisation of Chinese won't be possible until the regional differences become better acknowledged, so people learn literacy both in their first dialect and in the "standard" language(s).

As for the relatively low count of "unique" symbols -- the whole idea of unifying hanzi and the Japanese and Korean versions using the common semantics to reduce the required code space and "assist" translations and text searches has met great resistance, especially in Japan, and despite it there are now nearly 100,000 distinct characters defined in Unicode. 16 bits was always a pipe dream.

It is ultimately necessary (ie. required by users) to represent distinct glyphs uniquely; Unicode still doesn't satisfy many users precisely because it tries not to have too many distinct code points; probably it never will.

I expect one day the idea of choosing a font based on national context will be abandoned, and the code point count will finally explode, defining one Unicode character per glyph.

wchar_t

xoddam — Tue, 21 Apr 2009 00:25:57 +0000

wchar_t is 32-bit by default in g++ and in the stddef.h usually used by gcc.

There is a g++ compiler option -fshort-wchart to change the intrinsic type in C++, and you can use alternative headers or pre-define "-D__WCHAR_T__=uint16_t" for C, but this is pretty unusual on Linux except when cross-compiling for another platform (or building WINE).

corbet trolling

xoddam — Tue, 21 Apr 2009 00:01:45 +0000

Corbet is indeed trolling and he's got us all going ...

But when is Drepper going to come down amongst us in person and tell us IT ISN'T SO?

What's coming in glibc 2.10: XML

nix — Mon, 20 Apr 2009 22:42:31 +0000

Of *course* it's going to produce XML by concatenating strings, but I see
no reason why it has to be 'broken'. It's not as if it's going to be doing
fully general-purpose data->XML transformation: its emitting *one
structure* with contents fully controlled by the libc.

What's coming in glibc 2.10

nix — Mon, 20 Apr 2009 22:25:46 +0000

Are there *any* libraries or protocols with similar binary compatibility
guarantees? (Other than X, whicih is having similar problems: there's no
way *it* can use XML over the wire, but it's recently had to
introduce 'generic events' because it's run out of spare events...)

Who is going to read this information anyway?

jkohen — Mon, 20 Apr 2009 19:41:43 +0000

In this case there is really no excuse to go with XML. Even something like /proc/meminfo is more readable to a human than structured markup.

If you want structured data ready for human consumption, you probably need to write a user-space tool, in which case using XML is no better than protocol buffers, JSON and so on; it just has a more complicated spec.

What's coming in glibc 2.10

jkohen — Mon, 20 Apr 2009 19:36:22 +0000

Any library intended to write data in XML form, naturally. You can however find much more creative uses of XML at the TheDailyWTF.com. Sadly, now I wouldn't be surprised to see glibc popping up there soon.

What's coming in glibc 2.10: XML

jordanb — Mon, 20 Apr 2009 19:26:19 +0000

You must live in a different universe than me if you think this is a small spec.

Do you work in aerospace perhaps?

Compare that to the JSON spec, weighing in at all of eight pages. I doubt it'd take more than 100 lines of code for a fully compliant recursive descent parser. And writing an encoder would be just about as easy.

Which makes me wonder if they're *really* including a fully compliant XML encoder into the libc just to spit out a few lines of structured data, or if glibc is going to be joining the long line of shitty systems that produce broken XML by concatenating strings.

wchar_t

proski — Mon, 20 Apr 2009 18:55:52 +0000

It's already happening in Taiwan: http://en.wikipedia.org/wiki/Bopomofo

Why the vehement objections to decimal floating-point?

stevenj — Mon, 20 Apr 2009 16:34:11 +0000

(By "result of each calculation is exactly representable" I am of course including intermediate calculations. Note that this is equally true in fixed-point and integer arithmetic.)

Why the vehement objections to decimal floating-point?

stevenj — Mon, 20 Apr 2009 16:31:59 +0000

A lot of people here are proposing that decimal fixed point is just as good or better than decimal floats.

I'm a little skeptical of this, based on my experience with scientific computation: there are many, many circumstances when both the input and output of the computation appear to be in a range suitable for fixed-point representation, but the intermediate calculations will have vastly greater rounding errors in fixed point than in floating point. And fixed-point error analysis in the presence of rounding and overflow is a nightmare compared to floating point.

Decimal floating point gives you the best of both worlds. If the result of each calculation is exactly representable, it will give you the exact result. (Please don't raise the old myth that floating-point calculations add some mysterious random noise to each calculation!) There is no rounding when decimal inputs are entered, so human input is preserved exactly. And if the result is not exactly representable, its rounding characteristics will be much, much better than fixed point. (And don't try to claim that financial calculations never have to round.)

Note that the IEEE double-precision (64-bit) decimal-float format has a 16 decimal-digit significand (and there is also a quad-precision decimal float with a 34 decimal-digit significand). I would take this over 64-bit fixed point any day: only nine bits of this are sacrificed in IEEE to give you a floating decimal point and fixed relative precision over a wide dynamic range.

What's coming in glibc 2.10: XML

iabervon — Mon, 20 Apr 2009 15:33:06 +0000

I think it's weirder that glibc will be outputting a big string than that the string will be XML. What I think would be more sensible is if it output a data structure that looked like something you might get by parsing XML (ignoring comments, irrelevant whitespace, details of how characters were written, etc). That is, it would be a struct with a name, an array of attribute keys and values, an array of children, and a string for character data.

This would have the same extensibility benefits as XML, but avoid most of the parsing overhead. (Of course, the main practical extensibility benefit comes from using ASCII decimal strings of arbitrary length for numbers, which then requires a bit of parsing.)

What's coming in glibc 2.10: XML

drag — Mon, 20 Apr 2009 15:07:06 +0000

Well ya.. XML is simple. Angle-y brackets and a few other small things then your done.

I don't know why people are getting excited about this. Mallocinfo seems to me to be a very poorly designed part of the POSIX spec and, like the blog entry said, is dependent on the specifics of a particular malloc implimentation.

The particular Mallocinfo in the spec is so widly useless for any sort of modern system that there is just no 'right' way to do it.

So since it's returning statistica data that are dependent on a particular internal inplimentation then the sort of statistics that are relevent to anybody are going to change based on the changes of Malloc.

So instead of requiring application designers to use some sort of custom parser or try to read data whose relevence and meaning, at any point in the future, can and will change he has decided to go with a very commonly used, standard, self-describing format... which is XML.

Makes sense to me.

wchar_t

mrshiny — Mon, 20 Apr 2009 13:33:02 +0000

Chinese has only about 410 unique syllables (2050 if you include tones). There are thousands of words and many sentences which, even if tones are properly conveyed, are ambiguous. I would be surprised if the current romanizations replaced Chinese characters. I would be less surprised to see an alphabet arise instead, much like what the Japanese have.

What's coming in glibc 2.10

oseemann — Mon, 20 Apr 2009 12:13:18 +0000

Are there any other libraries that return a buffer with XML data to the caller instead of a C struct?

What's coming in glibc 2.10: XML

alankila — Mon, 20 Apr 2009 10:43:56 +0000

Don't overlook the possibility that this decision is a harbinger for using less binary structs in glibc's API, and more XML. Could happen.

I think it's quite safe to assume that Ulrich means "text with angle brackets" rather than the entirety of XML specification. In other words, even a crude parser is likely to work...

wchar_t

tialaramex — Mon, 20 Apr 2009 08:37:29 +0000

You don't need a Unicode string type in C, and it's probably a mistake to ask for one to be built into C++ (but I can't tell, maybe C++ standardisation is about trying to /collect/ mistakes at this point).

wchar_t is a legacy of the mistaken belief that Unicode was (as some documents from a decade or more ago declared) the encoding of all world symbols into a 16-bit value. Once UCS-2 was obsolete, wchar_t was obsolete too, don't use it. Use UTF-8 on the wire, on disk and even in memory except when you're doing heavyweight character processing, and then use UTF-32, ie uint32_t or at a pinch (since the tops bits are unused anyway) int.

The only real non-legacy argument for UTF-16 was that it's less bytes than UTF-8 for texts in some writing systems, notably Chinese. But the evidence of the last couple of decades is that the alphabetic and syllabic writing systems will eat the others alive, the majority of the world's population may yet be speaking Chinese in our lifetimes, but if so they'll write it mostly in Roman script destroying UTF-16's size advantage.

Why the vehement objections to decimal floating-point?

epa — Mon, 20 Apr 2009 08:25:45 +0000

64-bit integers are adequate to deal with most banking and financial calculations today.

Not all numbers used in finance are integers. Consider exchange rates and interest rates, for a start. If you were particularly perverse you could decide to use 64-bit ints for everything, with some way of encoding the number of decimal places (or binary places), but in that case you have effectively reinvented a floating point math library.

Decimal floats are symptomatic of poor design.

Not at all. They are often the best match to what the user and the rest of the world requires. It is accepted that 1/3 gives a recurring decimal .333... but no accountant wants their computer system to introduce rounding errors, no matter how minute, when calculating 1/5 (which is .0011... in binary). Or do you mean that *floating* point decimal is a bad idea, and it's better to use fixed point with a certain fixed number of digits precision? There is certainly a case for that.

What's coming in glibc 2.10

bvdm — Mon, 20 Apr 2009 07:37:43 +0000

No, I think a REST-style Web 2.0 enabled solution will work better..

LOL

What's coming in glibc 2.10

xorbe — Mon, 20 Apr 2009 04:31:08 +0000

I was hoping that glibc would upload the data to the localhost MySQL server at runtime, and then my program could query the results back...

Why the vehement objections to decimal floating-point?

ringerc — Mon, 20 Apr 2009 01:47:42 +0000

Generic rationals can be a screaming nightmare to work with. Rationals are OK if you use a fixed denominator for the type and are really careful about the sorts of calculations you perform and the ordering of those calculations. They're still a pain, just not as bad as variable-denominator rationals.

It seems to generally be quite sufficient to use double precision floating-point for this sort of thing. You just have to ensure you're running in strict IEEE floating point mode, trap floating point exceptions, and allow enough precision that you have at least a couple of significant figures of breathing room.

I've been fairly happy with PostgreSQL's `DECIMAL' type. It's a fixed-precision base-10 decimal that's REALLY nice to work with:

test=# SELECT (DECIMAL '100000000000000000000.0' + DECIMAL '0.0000000000100000000000000001') * DECIMAL '4.0' AS result; 
                       result                        
-----------------------------------------------------
 400000000000000000000.00000000004000000000000000040

test=# SELECT DECIMAL '400000000000000000000.0000000000000000000000000000000000000000000000000000040' / DECIMAL '1.1' AS result2;
                                    result2                                    
-------------------------------------------------------------------------------
 363636363636363636363.6363636363636363636363636363636363636363636363636363673
(1 row)

Having something like this in the core C language specification would be quite delightful.

(Of course, on a random and unrelated rant: a proper unicode string type would be a HUGE improvement to C/C++. The poorly-specified, painful to work with wchar_t with its variation across platforms and implementations, and its total lack of associated encoding conversion functions doesn't really do the job. Let's not even talk about std::wstring .)

Anyway ... I'd actually be really interested in some good references on numeric type choice and proper calculation methods in financial applications.

Why the vehement objections to decimal floating-point?

mgb — Mon, 20 Apr 2009 01:01:34 +0000

64-bit integers are adequate to deal with most banking and financial calculations today. Currencies are generally denoted in cents or mills, although the Zimbabwean dollar might more appropriately be denoted in billions.

128-bit floats can be used to store very large integers today and pure 128-bit integers are waiting in the wings.

Decimal floats are symptomatic of poor design.

Why the vehement objections to decimal floating-point?

tbrownaw — Mon, 20 Apr 2009 00:43:30 +0000

My understanding was that decimal floating point is actually extraordinarily useful in circumstances like banking and accounting where human inputs (which are invariably in decimal) have to be preserved exactly, but the range of fixed-point representations is too narrow.

I thought that with money you always wanted high-precision fixed-point with hard errors on numeric overflow, such as "15 digits with two of them after the decimal point". Floating point anything would mean that when you got enough dollars your cents would start getting rounded off, so what I understand is typically done is to use rationals with a fixed denominator of 100 (or whatever your money system uses).

What's coming in glibc 2.10: XML

bvdm — Mon, 20 Apr 2009 00:33:21 +0000

Wowa! Hold on already...

The XML world is a huge alphabet soap, but the XML spec itself (which does *not* include namespaces) is pretty small. Why require a JSON parser if most applications already have an XML dependency?

Who is going to read this information anyway?

xoddam — Mon, 20 Apr 2009 00:27:47 +0000

Heap implementation and performance details are not the sort of thing an application can hope to comprehend and adapt to on the fly. I would expect this information to be examined only by developers (often after the fact eg. in logs depicting memory pressure in a production system experiencing performance problems or horrible OOM events), who might prefer a more human-readable representation but shouldn't be afraid of XML in the case of a complex hierarchical heap structure.

Why the vehement objections to decimal floating-point?

stevenj — Mon, 20 Apr 2009 00:25:47 +0000

Certain special interest groups subverted the standardization process (again) and pressed through changes to introduce in the C programming language extensions to support decimal floating point computations. 99.99% of all the people will never use this stuff and still we have to live with it.

My understanding was that decimal floating point is actually extraordinarily useful in circumstances like banking and accounting where human inputs (which are invariably in decimal) have to be preserved exactly, but the range of fixed-point representations is too narrow. (And good arguments have been made by various people with long experience in floating-point arithmetic, such as Kahan, that decimal floating point's elimination of rounding in binary-decimal conversion will eliminate a lot of silly errors in other fields too, and hence should become the norm as long as the speed is adequate.) And the latest revision of IEEE-754 describes an efficient way to encode decimal floating point into binary, with the possibility of future hardware support as well, so C is being revised to support this capability.

So why is Drepper digging in his heels?

What's coming in glibc 2.10

foom — Sun, 19 Apr 2009 23:50:27 +0000

Indeed, it seems to me that a sysctl-like API would make more sense.

What's coming in glibc 2.10

jreiser — Sun, 19 Apr 2009 22:55:37 +0000

... a function pointer to a function that takes no argument and returns the real function pointer to use ...

It would be useful to have some parameters: a pointer to the symbol table entry for the symbol in question (and the string table, ...), and a pointer to the dynamic linker context (search path: chain of struct link_map *) that applies. Then the same intercepting function could handle multiple names (there are many str* and mem* functions, for instance) and might be able to handle better some special cases such as compatibility matching, etc.

What's coming in glibc 2.10

oak — Sun, 19 Apr 2009 22:30:37 +0000

Both are needed. Mallinfo tells whether the process is fragmenting its
heap. Checking that may be a performance issue, so needing to parse XML
sounds strange. And if Glibc does allocs for the XML output, it would be
even stranger...

What's coming in glibc 2.10

nix — Sun, 19 Apr 2009 22:15:58 +0000

It isn't a separate context. It's more like injecting code into the
implicit first call into the dynamic linker that happens the first time
any given symbol is referenced[1]. The security context is unchanged: all
the dynamic linker normally does is relocate that PLT entry. It's just
that now you can have it pick *what* to relocate first. It's no more done
in a different context than is calling a function through a function
pointer: that's all it really is.

(hm, and it looks like it might become STT_IFUNC in time and not be
GNU-specific after all. Even better.)

[1] an oversimplification: actually that implicit call happens the first
time a PLT entry is jumped to, but that's nearly the same thing...