[Python-Dev] Google Summer of Code proposal: improvement of long int and adding new types/modules.

Mateusz Rukowicz mateusz.rukowicz at vp.pl
Sat Apr 22 10:07:15 CEST 2006


Alex Martelli wrote:

>I see "redo Decimal in C" (possibly with the addition of some fast
>elementary transcendentals) and "enhance operations on longs"
>(multiplication first and foremost, and base-conversions probably
>next, as you suggested -- possibly with the addition of some fast
>number-theoretical functions) as two separate projects, each of just
>about the right magnitude for an SoC project. I would be glad to
>mentor either (not both); my preference would be for the former -- it
>appears to me that attempting to do both together might negatively
>impact both.  Remember, it isn't just the coding...: thorough testing,
>good docs, accurate performance measurements on a variety of
>platforms, ..., are all important part of a project that, assuming
>success, it's scheduled to become a core part of Python 2.6, after
>all.
>
>
>Alex
>
>  
>
If it's enough, that's ok for me - I would concentrate on one thing and 
very likely do it better. My main reason of doing these both at the same 
time, was that, these would share many code, and since I did quite a bit 
research in this area (comparing algorithms with diffirent complexity, 
comparing diffirent cache-friendly implementations, timing on machines 
starting at p200 ending at dual Xeon 3GHz), I have quite a experience in 
that stuff. But anyway, conforming to Tim Peters mail, It's not likely 
something will change in long int ;) - I understand that, and don't want 
to change you developing python policy (actually, I was expecting that, 
when I realized that multiply is karatsuba-only).
Here is a little comparsion made by my friend python vs my 
implementation of multiplying (coded in C, without any assembly - I have 
also assembly version ;P)
http://parkour.pl/mat.png
It computes product of k*l log(k) = log(l), X axis is sqrt(n), where 
O(n) = O(logk), in other words, n is 'length' of numbers.
I think, that decimal coded in C by me would achieve quite similiar time 
(also I would eliminate 'staircase' effect), if you wish.
I am quite efficiency concerned, in my opinion, efficiency is third most 
important thing after easy-to-use-code and functionality, and should not 
be forgetten. Also I state that efficient code/algorithms isn't 
necessary hard to maintain. And all in all, these algorithms are not so 
complicated, (in my opinion, fft multiply - which is assymptoticly the 
best - is less complicated than karatsuba, but that's my opinion).

I am now quite sure, what I would like to do, and is possible by you to 
accept - code decimal in C, most important things about that would:
1.Compatibility with old decimal
1.easy to maintain and expand code
1.don't broke python portability, nor adding new depedencies
2.Efficiency (if and only if 1. isn't broke)
I am quite confident I can achieve this points.
But everything is open for discussion ;) I'd like to know as much as 
possible what do you think about this idea. (But already i know quite much)

Best regards,
Mateusz Rukowicz.


More information about the Python-Dev mailing list