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