[pypy-dev] Re: [pypy-svn] r20092 - pypy/dist/pypy/rpython

[Christian Tismer]

Bengt Richter wrote:

> At 12:55 2005-11-21 +0100, Armin Rigo wrote:

...

>>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.).

Yes, I think at a certain primitive level I'd prefer to have an explicit
way to spell the size of my numbers. I don't know yet if this should be
done via names, or if there are better ways.

For my application during the US trip for instance, I made a little data
description language, a very tiny set of Python classes which allow to
build record descriptions for data.
I didn't use type names at all, but used notations like

Char        = StrDataDef("X", 1)
Str16       = StrDataDef("some stuff", 16)
Numeric     = StrDataDef(123, 9)
Price       = StrDataDef(99999999999999, 14)
Num1        = StrDataDef(9, 1)
StrVar      = StrDataDef("varying", 1, 255)

The idea is to give an example value instead of a data type.
See for instance the Price field. The maximum possible value
is intentionally not written as a long. It just says how many
digits I need.
This will be a long in most cases, but on a 64 bit machine,
it would be a simple integer, and my application would
produce faster code.

> 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 ?

I would like to have two things:
- a way to express what precision I need for something
- a way to ask which precisions are native data types

This is because depending on whether there is a native type or
if it must be emulated, I might want to choose different
implementations.

 From my work on the long integer implementation, I know that
explicit types are quite error-prone and make the code
less readable. The nicest thing I could imagine was a way
to track the necessary bit sizes automatically in the
annotator.
But that's a difficult thing, because our current assumption
is that overflows are ignored. In order to do explicit bit
tracking, we would probably need an extra r_someint, which
is handled specially to track the needed preceision?

> 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.

Interesting, too!

We also could go further and produce an implementation for every
small fixed bit size that is needed, even if it is not that efficient.
This would be done in situations where there is no choice, like
the 64 bit long file pointers.
For things like the general long implementation, I would ask the
systtem for the most efficient native types and build upon them.

cheers - chris

-- 
Christian Tismer             :^)   <mailto:tismer at 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/