[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pypy-dev
Subject:    [Fwd: Re: [pypy-dev] Re: [pypy-svn] r20092 - pypy/dist/pypy/rpython]
From:       Christian Tismer <tismer () stackless ! com>
Date:       2005-11-27 13:41:08
Message-ID: 4389B774.2060302 () stackless ! com
[Download RAW message or body]

[this message^did not appear on pypy-dev]

["Re: [pypy-dev] Re: [pypy-svn] r20092 - pypy/dist/pypy/rpython" (message/rfc822)]

Return-path: <bokr@oz.net>
Envelope-to: tismer@stackless.com
Received: from server018.dfw.nationwide.net ([206.123.129.81])
	by centera.de with smtp (Exim 3.35 #1 (Debian)) id 1EgA4L-0001qB-00
	for <tismer@stackless.com>; Sun, 27 Nov 2005 01:07:01 +0100
Received: (qmail 21352 invoked from network); 27 Nov 2005 01:45:21 -0000
Received: from sense-sea-megasub-2-122.oz.net (HELO gazelle.oz.net)
	(216.39.172.122)
	by 206.123.129.9 with SMTP; Sun, 27 Nov 2005 01:45:21 +0000
Message-Id: <5.0.2.1.1.20051126174206.01ba5670@mail.oz.net>
X-Sender: bokr@mail.oz.net (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Sat, 26 Nov 2005 17:48:14 -0800
To: Armin Rigo <arigo@tunes.org>,Christian Tismer <tismer@stackless.com>
From: Bengt Richter <bokr@oz.net>
Subject: Re: [pypy-dev] Re: [pypy-svn] r20092 - pypy/dist/pypy/rpython
Cc: pypy-dev@codespeak.net
In-Reply-To: <20051121115556.GB4921@code1.codespeak.net>
References: <43819B91.9070401@stackless.com>
	<20051119194213.0862F27B9E@code1.codespeak.net>
	<438193DA.6030908@stackless.com>
	<200511210951.jAL9pTWU013620@theraft.strakt.com>
	<43819B91.9070401@stackless.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 12:55 2005-11-21 +0100, Armin Rigo wrote:
>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)...

Please pardon my jumping in, but IMO a collection of _unambigous_ names like r_int32
is in one sense just a small notch better than a collection of _ambiguous_ names
for various integer implementations (like int, long, etc.).

If you want a "general design that would allow integers of various precisions,"
perhaps one could think about some way of parameterizing the precision info (e.g.,
exact or min bit widths) rather than just cleaning up the ambiguity in C's way
of defining an evolving series of increasingly ridiculous (what next, extralonglong?)
platform-dependent names. I.e., when would it be time to introduce r_int128 ?

If various integer subtypes are being generated, perhaps one could specify
minimum or exact bitwidths etc as parameters seen by a metaclass, like __SLOTS__
only relevant to integer representation, or have an integer class factory function
that takes specs as parameters and raises an exception if the required class
can't be generated implementing the specs a particular platform.

Just a thought.

Regards,
Bengt Richter




[prev in list] [next in list] [prev in thread] [next in thread]