Re: [pypy-dev] Re: [pypy-svn] r20092 - pypy/dist/pypy/rpython
In a message of Mon, 21 Nov 2005 01:31:06 PST, Christian Tismer writes:
arigo@codespeak.net wrote:
Author: arigo Date: Sat Nov 19 20:42:12 2005 New Revision: 20092
Modified: pypy/dist/pypy/rpython/robject.py Log: Bug fix (for Christian :-) to compile code like
d = {} d[x] = y
where x and y are SomeObjects. The reason is that operations manipulat ing PyObjects must not have a 'void' return value, even operations like 'se titem', but a PyObject one.
Thank you very much! I worked around that, but in the end, it is a bug. And btw. I discovereed a bulk of more bugs or inconsistencies, which might be tackled after I'm back from my "mission".
ATM, I need to make a small addition to allow float values as dict keys. There is a lot more considerable, but I can work around all other stuff and don't want to spoil our project without discussion. The need for float comes from the lack of a primitive long type. Alternatively, I'm thinking to map the long type to some internal 64 bit type. This would make some sense, also because we also have file related code that would need this type.
I will start discusions when I'm back. Adding a bit of completeness (hash on float) will probably not hurt anybody.
Btw., I have meanwhile turned all their application into RPython. Although this took many new little classes, and the lack of properties was as painful as the inability to define any __xx__ methods, the result is still rather pythonic and runs at blinding speed- I'm now only 30% slower than their highly optimized Java implementation, and I guess I could get the rest for free by finishing the needed optimizations of refcounting and some other tiny things.
all the best - chris
-- Christian Tismer :^) <mailto:tismer@stackless.com> tismerysoft GmbH : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ _______________________________________________ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Correct me if I am wrong, but if we allow float keys, then we make code that is not portable between machines that have different float representations? Also, given that your new American friends are dealing with money, what is wrong with using the decimal type as keys for them, or possibly better still Facundo's money module? Laura
Laura Creighton wrote:
Correct me if I am wrong, but if we allow float keys, then we make code that is not portable between machines that have different float representations?
CPython does allow float keys and doesn't have portability problems. The only concern here is compatability with equally values integer keys. But that does not apply to RPython, since we there dfon't allow mixing types at all.
Also, given that your new American friends are dealing with money, what is wrong with using the decimal type as keys for them, or possibly better still Facundo's money module?
I needed something that is supported by RPython and that is very fast. I'm not aware of a C implementation of the money type, yet, but maybe I'm missing something. 64 bit long would be perfect, because they use it at a fixed decimal scale and convert into float only for display purposes. So float is ATM a surrogate which is ok, because 53 bits fill the needed range, too. And my primary goal is to show them what PyPy can do, and to convince them that it makes sense to invest into this. Btw. it is not the Salomon Bros/group but an individual, with his roots in Hungary. all the best - chris -- Christian Tismer :^) <mailto:tismer@stackless.com> tismerysoft GmbH : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/
Hi Christian, On Mon, Nov 21, 2005 at 02:04:01AM -0800, Christian Tismer wrote:
CPython does allow float keys and doesn't have portability problems. The only concern here is compatability with equally values integer keys. But that does not apply to RPython, since we there dfon't allow mixing types at all.
Good point. RPython can probably live with a simple hash function for floats, and our W_FloatObject's hash can be more complicated (possibly using the integer as hash when the float has no fractional part, like now, or falling back to the RPython hash if there is a fractional part).
64 bit long would be perfect
That's a possibility. For PyPy we should be more explicit, though, and use a "class r_longlong" or "class r_int64". It should be part of a general design that would allow integers of various precisions. The design decision is to choose if we want classes with explicit sizes (r_int64) or C-like names (longlong)... A bientot, Armin.
participants (3)
-
Armin Rigo -
Christian Tismer -
Laura Creighton