Mark Dickinson wrote: >On 10/16/07, Fredrik Johansson <fredrik.johansson at gmail.com> wrote: > > >>A more radical proposal would be to change Python's long type to use a >>radix-10**n representation (Python 3000 or beyond?). >> >> > >Mightn't this produce significant (constant factor) slowdowns for long >performance? As I understand it, the main problem with a base 10**n >representation is that, for example, extracting the high and low limbs >of the 2-limb result of a 1-limb by 1-limb multiplication requires a >division, whereas for integers stored in binary that division can be >replaced by bit operations. > > > >>An implementation >>of decimal floating-point arithmetic on top of it, whether written in >>C or pure Python (if some utility C functions such as for counting the >>number of digits an integer were available), would be both >>light-weight and efficient at high precision. >> >> > >Agreed. But it might be hard to sell a more efficient decimal module >at the expense of slower integer arithmetic in core Python. > > > My 2 cents -- integer division and modulo (needed for 10**n radix) is so slow, that in some extremal cases algorithm may slow down by a factor of 4-5, so I guess it's not an option. Not to mention binary logical operations.
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