Steven D'Aprano writes:
On 12/10/12 03:05, Stephen J. Turnbull wrote:
Steven D'Aprano writes:
I would gladly give up a small amount of speed for better control over floats, such as whether 1/0.0 raised an exception or returned infinity.
Isn't that what the fpectl module is supposed to buy, albeit much less pleasantly than Decimal contexts do?
I can't test it, because I don't have that module installed, but I would think not.
Reading the docs:
http://docs.python.org/library/fpectl.html
I would say that fpectl exists to turn on floating point exceptions where Python currently returns an inf or NaN, not to turn on special values where Python currently raises an exception, e.g. 1/0.0.
OK. But if Python does that, it must be checking the value of the operand as well as the type. Surely that could be delegated to the hardware easily by commenting out one line. (Of course that would need to be a build-time option, and requires care in initialization.)
Because it depends on a build-time option, using it is even less convenient that most other non-standard libraries.
That is neither here nor there. I think the people who would use such facilities are a very small minority; imposing a slight extra burden on them is not a huge cost to Python. Eg, I'm perfectly happy with Python's current behavior because I only write toy examples/classroom demos in pure Python. If I were going to try to write statistical code in Python (vaguely plausible but not likely :-), I'd surely use SciPy.
It only has a single exception type for any of Division by Zero, Overflow and Invalid, and doesn't appear to trap Underflow or Inexact at all. It's not just less pleasant than Decimal contexts, but much less powerful as well.
Now you're really picking nits. Nobody said fpectl is perfect for all uses, just that you could get *better* control over floats. If you're going to insist that nothing less than Decimal contexts will do, you're right for you -- but that's not what you said.