(Rearranged email to order of urgency.)
> type of the object. Another problem is that is specifically requires
> one to declare ahead of time what compile-time assumptions can be
> made, rather than letting the user of the .pxd file specify things
> ahead of time for explicit optimization.
This "problem" was the exact reason I did this, and is a feature!!
Perhaps there's more I don't understand. Tell me then how you prevent
something like this:
cdef timer(seconds=0) t = timer(0)
print t.seconds # prints 0
sleep(10)
print t.seconds # prints 0 (!)
The whole point was to leave what one can safely (!) make assumptions
about up to the class designer (and presumably pxd author). Otherwise
this just becomes some dangerous shoestring feature, not something you
give to engineers using NumPy without deep programming knowledge...
Possible assumptions should be part of the published API of the class!
(Is this something we will simply never agree on? I really hope I am
misunderstanding something, would make all of this much easier.)
(About __assume__:)
> and also that it requires the use of full control flow to do any
> reasoning (e.g. there's the variable before assumption, the variable
> after, and the variable which (depending on branching) may or may not
> have been certified to have a given property. Then further
> __assumes__ would be illegal? Or just ones that contradict?) It just
> gets a lot messier than simply adding the data to the compile-time
You misunderstood me here! I specifically noted that __assume__ only did
the checking part, and does *not* magically constitute the assumptions
themselves (that would be insane :-), probably challenging halting and
NP-completeness and whatnot).
If we want to up the bets from there, I think __assume__ could return a
dict like this:
cdef __assume__(self, len):
...
return { "_len" : len }
in order to provide renames etc. This *does* have the problems you
mention though, but it is somewhat easier to arbitrarily raise errors
for complex expressions. But I'm not advocating it this time around.
> The mapping of __init__ parameters to type parameters (for use with
> type inference) could be arbitrarily complicated, and I don't know
> how to do that without having the compiler actually execute code at
> compile time.
I don't see why. What I meant is simply:
- Take parameters passed to constructor.
- Take intersection of the names of these with __assume__ method signature.
- Pass same parameters (set to same expressions) to __assume__.
OK, I suppose if you have non-trivial expressions as parameters this
fails, so add this rule then:
- However, if the expression of a parameter is not a compile-time-value,
don't pass it to __assume__ anyway.
If we know enough to attempt type inference, we'll know enough to do
this I think.
If this is not accepted, I'm leaning against using the () syntax,
because you'll want to do stuff like (using [] syntax):
x = ndarray[nd=2, dtype=float64](shape=(2,2), dtype=float64)
in a type-inferred environment, to ensure that x has efficient access,
and using () is very ambigous in the expression above.
--
Dag Sverre
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
