Conversation
we could make it an optional dependency, but IMO pytools is very light pragmatically quite unlikely if that turns out to be a point of failure
kaushikcfd
force-pushed
the
operation_pool
branch
from
33b665c to
3fe1aba
Compare
functools.cached_property is not available for py < 3.8
| @dataclass | ||
| class NormalizedISLObj: | ||
| ground_obj: BaseType | ||
| lift_map: Dict[str, str] |
There was a problem hiding this comment.
@inducer: Do you think it would lead to lesser dev errors if we make this a pyrsistent.PDict. I am leaning towards it.
| @dataclass | ||
| class NormalizedISLObj: | ||
| ground_obj: BaseType | ||
| lift_map: Dict[str, str] |
| @@ -0,0 +1,830 @@ | |||
| __copyright__ = "Copyright (C) 2021 Kaushik Kulkarni" | |||
There was a problem hiding this comment.
Not loving the name. The main advance here is that we're "taking over" in terms of naming/labeling things from isl. Better caching (is that what you mean by pooling?) is just a side effect of that. So I'd prefer a name that reflects that. int_names? ext_naming? sep_naming? ...
|
|
||
| @dataclass | ||
| class NormalizedISLObj: | ||
| ground_obj: BaseType |
There was a problem hiding this comment.
| ground_obj: BaseType | |
| base_obj: BaseType |
| ground_obj: BaseType | ||
| lift_map: Dict[str, str] | ||
|
|
||
| def lift(self) -> BaseType: |
There was a problem hiding this comment.
Not loving these names. realize? Or maybe I'm misunderstanding what this does?
| @dataclass | ||
| class NormalizedISLObj: | ||
| ground_obj: BaseType | ||
| lift_map: Dict[str, str] |
There was a problem hiding this comment.
Could you document what keys and values are here? I'm particularly worried about the isl end being a str, because that can't be cheaply turned into what isl talks about. I was expecting a (dim_type, dim) tuple here.
|
Unsubscribing... @-mention or request review once it's ready for a look or needs attention. |
2 participants
No description provided.