On May 15, 2009, at 12:44 PM, Dag Sverre Seljebotn wrote: > Robert wrote: >> On May 15, 2009, at 11:41 AM, Lisandro Dalcin wrote: >> >>> On Fri, May 15, 2009 at 2:03 PM, Dag Sverre Seljebotn >>> <[email protected]> wrote: >>>> Lisandro wrote: >>>> >>>> I tried proposing something similar (unknown size) some time ago >>>> and it >>>> was voted down; perhaps the climate has changed now. >>> >>> I voted it down perhaps because I misunderstood your proposal. I >>> understood you were proposing this for the whole type system. >>> >>> If this is done for external ctypedefs, I would no oppose it. >> >> I just don't see how such a construct would be useful. For everything >> that can be deferred to using sizeof (e.g. conversion to/from Python) >> we are moving to using just this, not using the ranking information >> at all, so there's no gain. Now for the stuff where we do use ranking >> information (only temps and type inference come to mind) we either >> use the ranking the user gave (and blame them if they gave it wrong >> enough that it messed them up) or disallow, e.g., all arithmetic >> between unranked and ranked types. Thus > > What you are missing here is mixing external typedefs (for which a > coherent ranking can be assigned as a closed system, sure) with pure > builtin types. > > cdef np.int32_t a = ... > cdef long b = ... > b = a / b
I think your intent here is to have a/b being done in the longest type of int32_t and long, as determined at C compile time, right? > NOTE: This is also relevant for Cython itself without any external > typedefs, as it would be nice to support C99 int32_t, int64_t etc., > but we > have no idea how to rank them relative to existing integer types. I would probably put these in a shipped .pxd file, but the point remains that the user isn't determining the rankings. My resistance is that I would really like to avoid a combinatorial explosion of types, especially if every statement using the resulting variables has to be written many times surrounded by various if statements. For now, we only use type inference for temps and intermediate expressions, so it's relatively local, but we should come up with a solution that works for variable type inference as well. If we don't want to explicitly code every possibility we need to query the C compiler, which either breaks shipping .c files or creating ./configure like scripts. > For the overview, here's three solutions: 0) Remove any unnecessary dependance on the ranking (this has already mostly happened). It will only be used for widest-type style inference. > A) Document, document, document; the behaviour is difficult to > understand > but at least we are clear about it This should be done regardless. > B) Accept that Cython becomes part of the final compilation stage > with > #ifdefs and exact types; this will happen anyway if Cython parses .h > files!! I'm not sure exactly what you mean here, but it sounds like this would break just being able to ship a single set of generated .c files for a variety of platforms. > C) Trick around the temps as well with some ugly kludge to make > ranking > information unecessarry (though nice to have if available because > nicer > code is generated). > > (I'm feeling up one more but it's still very hazy.) > > There's lots of options for C). In addition to what has been > mentioned; if > one accept a small ./configure-style prestep, one could e.g. write a > program to output a header file containing > > #define sizeof_IntA 4 > > ...and so on. That would do wonders, as you could get > widest_IntA_IntB as > a typedef. The widest_IntA_IntB idea certainly sounds like the cleanest solution, but as above breaks being able to ship .c files (or requires a configuration script on the other end). D) (Not really new) Users can declare their types as a long long, and all arithmetic will coerce to it no matter what its size (if we break ties by choosing the extern type, or have a new modifier that means "wider than anything". Summing two such extern type would be unspecified (take the left?) - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
