here is your chance to recycle a few select quotes from The Incredibles.


I do not recall having a graduation ceremony after my own time in

More Burgers

Robert, I am not at all
disputing the claim that electricity costs are slow to adapt. I will
take your word for that.

But the claim you proxied was different, namely that slowness in
adaption was somehow related to lack of international trading. Yet,
the slowest adapting price you mention is for a perfectly fine,
internationally traded commodity, complete with a futures market. The scientific solution here is to discard or at least
amend the hypothesis that slow adaption is related to whether there is
international trading. Wearing my mathematician’s hat, I do not
accept proof by “widely considered”.

For the record, and without thinking too deeply about it, I would
guess that electricity prices adopt slowly is mainly because the
building of power plants and distribution network starts with a
huge initial capital expense which has to be earned back (or not,
depending on your economical system, :-) over a long time.

I do recall you implying that without a minimum wage there would be no unemployment. That is pure reaganomics aka nonsense. Do a fact check, i.e., look for times
or places with no minimum wage and see if unemployment occurs. For
example, during the great depression there was widespread unemployment
but no minimum wage. (You could find newer examples, but then you would have to find them abroad.) Science: hypothesis has been
proven wrong and
gets discarded. Politics: let’s hope no-one notices and draw a cat.

Totally unrelated, I agree that seizing people’s property, even with economic
compensation, really ought to be based on something a bit more
essential than the love of strip malls.


To The Economist’s credit, The Big Mac Index is for a large part a
joke. Just think of how many RMB you would have to pay to get a
Big Mac on the moon. It is incredible how much the RMB is overvalued
by that measure. Think about that the next time some clown tells you
that the RMB exchange rate is the cause of all US budget problems.

Robert, my bogus-meter is blinking. Why did you forward an obviously-wrong claim like electricity not being internationally traded?
Remember Enron?
(And check out DoE and this list of electricity exporting countries.)

OpenDocument for Spreadsheets

From time to time I am asked if Gnumeric supports or will support the OpenDocument standard. I am sad to report that the question is meaningless. The purpose of a standard ought to be interoperability; this standard is not a step in that direction.

Executive summary: The OpenDocument Standard v1.0 completely ignores semantics of spreadsheets, thus virtually ensuring that if two implementations of the standard existed then they could not use each other’s spreadsheets. That, in turn, renders the alleged standard pointless for spreadsheets.

The OpenDocument standard v1.0 is 708 pages long. You would think that in such an elephant they could find the space to hammer out a usable spec for spreadsheets. But no, they do not.

Formulas (or formulae if you are feeling learned) is an important part of what goes into spreadsheets. What does the alleged standard have to say about those? Basically you go to page 184-186 and find the two (equivalent) formula examples that it has:


Pedantics — that would be me — would point out that both these fail to comply with the formula requirement “Every formula should begin with a namespace prefix specifying the syntax and semantics used within the formula.” Hmmm… Or maybe “=” is that prefix and anyone seeing it will magically understand the syntax and semantics.

Regardless, we learn

  • the existence of a function named sum. I hope you can make good use of it, because it is the only function we get to know about. (There is a handful more in contexts unrelated to formulas.)
  • that there exists operators. Which ones seems to be a secret, apart from the fact that some of them are logical.
  • that numbers can be part of formulas. We will have to assume that regular C-like syntax for them is used.
  • that strings can be part of formulas. There is no clue about how to write them; I will guess that you put them in quotes, but what about embedded quotes, then?

There is what appears to be the beginning of a value system on pages 184-185. You get numbers, dates, times, booleans, and strings. Notice the absence of error values and “empty”, let alone arrays. Excel has those, Gnumeric has them, and OOo-calc has at least error values. Thus there is no chance that someone following the OpenDocument standard can approximate Excel semantics, nor for that matter is there any chance that OOo-calc can implement the standard with its current value system.

It gets worse. Let us assume that a proper value system was in place. If you wanted to have any hope of achieving interoperability you would them have to define function (and operator) semantics for a set of functions large enough to be useful. Details matter. For example, for our friend sum above, Excel will completely ignore strings like “42” (with the quotes) in referenced cells, but it will convert them to numbers and include them in the sum when given as direct arguments to SUM. (Yes, that is sick.) In technical terms, Excel does not have referential integrity. OOo-calc lacks referential integrity too and in the direct-argument case produces an error, i.e., it is sick in a different way. (For completeness, Gnumeric ignores all strings for SUM; this might change.) As a cuter example, OOo-calc manages to evaluate “1”+1 to TRUE!

So there. As far as spreadsheets are concerned, the OpenDocument Standard v1.0 is the equivalent of giving precise punctuation rules for sentences without telling if it is for English, German, French, or something else.

Only vaguely related is the question of whether Gnumeric should be able to read OOo-calc files. The answer is yes, and we do have some support for it. In practice it is probably easier to interoperate via the xls format.

[Formatting updated 2015]

Gnumeric 1.5.2

The weekend saw the release of Gnumeric version 1.5.2.
It should probably have a catchy name, but it does not.

This is a lots-of-little-things release that ought to make for a smoother ride.

Dependencies Re-Redux

I finally did manage to hack the dependency tracking code into a
state where invalidation of a sheet (done because the user performed the
undo-able removal of the sheet) is distinct from the destruction of
the sheet.

That sounds technical but the nice results are: (1) we no longer
have to clear the undo/redo queues when someone deletes a sheet;
(2) we now track and undo changes to other sheets’ cells when a
sheet is removed; (3) we track and undo changes to global names’
definitions when a sheet is removed.

These are not things you notice when they work, but you do when they
do not work. Chalk one up for user experience.

Tofu with Sprinkles

We sometimes go to a buffet place on weekends and _A_ has
managed to talk herself into being allowed to have ice cream for

Enter _L_. He was only about one year old at the time, but he very
quickly figured out that the white soft stuff was desireable and
made it clear that the building would come down if he did not get
some. Pronto. That was a bit of a problem since ice cream does
not figure prominently in the recommended diet for a one-year old.

Solution: soft tofu, with sprinkles.

Therefore, according to _L_, ice cream is something that is served warm and
with sprinkles. He has figured out the difference in the meantime,
but he still seems to prefer the tofu. Fine with me.

Libc is Broken, Part 1a

Robert, I said “int”, not “long”.
The code you presented does not work for platforms where the two are
different. There is no strtoi so you get to use strtol and do the
extra range checking.

It also does not work because there is no
requirement that strtol set errno for any condition
but overflow and underflow. In particular for the empty string.

It also does not work because libc functions may
set errno when no error is detected. And, in fact, they
often do.

And, finally, it also does not work for strings like “010”.
You get 8, but you should get 10 when someone mumbles “decimal”.

Update: And while I am picking at you, it seems I
have to point you at the ctype man pages too. isdigit
is defined on the special value EOF and an integers within the range
of unsigned char.

In practice, what libc implementations do is something like

  #define EOF (-1)
  #define isdigit(_c) ((__somearray+1)[(_c)] & SOME_BIT)

That can and will core dump if you send a random signed character.

(Glibc has a misguided attempt at making things work for signed
characters also. They essentially add 128 and duplicate half the
table. That works fine unless you want the right answer.)

Libc is Broken, Part 1

It is time for a gripe.

Libc contains a lot of quite APIs. You probably know about the
gets dissaster, but there is a whole lot more.

  • String-to-value conversions. Here is how you
    convert from a string s containing a decimal integer
    into an int i:

      char *end;
    int i;
    long l;
    errno = 0;
    l = strtol (s, &end, 10);
    if (s != end && *end == 0 &&
    errno != ERANGE &&
    l >= INT_MIN && l
    And that is before considering locales (which typically do not
    affect integers, mind you).
  • Time zones. The localtime function
    is great, but having $TZ as as implicit and not explicit argument
    makes it really, really hard to use for anything but the default
    time zone.
  • ctype functions. At least two things are wrong:
    (1) the encoding used is an implicit argument; and (2) they are defined obscurely such that char c = 'a'; isdigit(c) may or may not
    be valid, depending on the platform. Most commonly it is not valid,
    i.e., it may core dump. The right way to do that is,
    for reference, isdigit((unsigned char)c) which is enough to make a sane man crazy. (Alternatively one
    could define c as unsigned char but in
    more practical code the type is often constrained by a parameter type.)

I have the feeling I might return to this subject later.