Georg Brandl <g.brandl at gmx.net> wrote: > > > Even then, we need to drop the concept of having the flags as counters > > rather than booleans. > > Yes. Given that even Tim couldn't imagine a use case for counting the > exceptions, I think it's sensible. Well, I can. There is a traditional, important use - tuning. When such arithmetic is implemented in hardware, it is normal for exceptional cases to be handled by interrupt, and that is VERY expensive - often 100-1,000 times the cost of a single operation, occasionally 10,000 times. It then becomes important to know how many of the things you got, to know whether it is worth putting code in to avoid them or even using a different algorithm. Now, it is perfectly correct to say that this does not apply to emulated arithmetic and that there is no justification for such ghastly implementations. But, regrettably, almost all exception handling on modern systems IS ghastly - at least by the standards of the 1960s. Whether you regard the use of Python for tuning code that is to be run using hardware, where the arithmetic will be performance- critical as important, is a matter of taste. I don't :-) Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: nmm1 at cam.ac.uk Tel.: +44 1223 334761 Fax: +44 1223 334679
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4