Triangle Classification Problem (2002)

russcon.org

9 points·gaul··9 comments

A shame that this is so C-specific; most of the bugs seem to be trivialities around C integer behaviour that simply wouldn't be an issue in e.g. Python. So it would be good to see comparisons to other languages.

Agreed.

Why don't we have any languages where small bignums are as fast as fixnums? Is it a hardware problem (difficult to have an overflow trap with zero cost in case of no overflow), or is it a programming problem?

We do: Python.

Whoops, I guess I asked the wrong question. Are small integers in Python as fast as integers in C?

Theoretically they're supposed to be (in practice it's hard to tell given how slow the rest of the language is and so I wouldn't be surprised if there were undiscovered implementation issues, but they should be). The case where you do trap an overflow and redo the calculation with bignums is of course a bit slower than doing it with bignums in the first place so it's not a completely free lunch (though AIUI the bignum calculation takes substantially longer than the trapped attempt at doing it with fixnums so it doesn't really matter).

How so? Does not python add some checks to see if an operation will overflow or not? Or something like that?

AIUI trapping on overflow is usually supported at the hardware level, so it's no overhead unless an overflow actually happens. (This is outside my area of expertise though - it's possible I'm wrong and they have to explicitly check the carry flag or some such, at least on some platforms)

I thought Python integers were PyObject's? That should slow things down a lot.

Of course, in Python this is also pretty trivial to write. You just do the two illegality checks, then if you get through those "return len(set((a, b, c)))" will be the correct result.

Reply on news.ycombinator.com