[Andrew P. Lentvorski]

Now that C9X is an official standard,

I'm afraid that's irrelevant in practice before "almost all" platform C packages conform to the new standard.

can we either:

1) add rint() back into the math module (removed since 1.6.1?) or

This sounds counfused. According to the CVS logs, rint() was briefly in the codebase, first released in 1.6 beta 1 (rev 2.43 & 2.44 of mathmodule.c), but retracted before 1.6 final was released (revs 2.45.2.1 and 2.53).

2) update round() so that it complies with the default rounding mode

round() has always forced "add a half and chop" (which can be done portably, relying on C89's rounding-mode-independent floor() and ceil()); changing that would be incompatible.

I bumped into a bug today because round() doesn't obey the same rounding semantics as the FP operations do.

round() wasn't intended to.

While there are lots of arguments about whether or not to add other C9X functions, I'd like to try and avoid that tarpit.

It's a non-starter before C9X triumphs, if ever. If it does, there won't be debate -- we'll gladly expose all the spiffy new numeric functions then. It would be great to have them!

The primary argument against rint was the lack of being able to write portable code. In this instance, the *lack* of rint (or its use in round()) prevents writing portable code as I have no means to match the rounding semantics of my FP ops from within Python.

Sorry, but neither does Python. I suggest you write an extension module with your favorite C9X gimmicks (this isn't hard), and offer it for use on C9X platforms. Eventually there may be enough of those that we could fold the new functions into the core. Before then, you may find more people in the NumPy community willing and able to wrestle with reams of platform #ifdefs for numeric gimmicks.