OK, I have a situation in which proto domain/subdomain could help me but i can't wrap my head around a proper solution. Here is the deal, i have various sub EDSL that goes like: - constants EDSL provides named consatnts (like zero_, one_, pi_ etc) that are meant to be terminal usable in any other EDSL en provide a type based way to know which constant is beging used and provide optimization in came it helps (e.g detecting x < zero_ in SIMD EDSL to replace with the SSSE3 corresponding fused operation) - a SIMD vector EDSL - various container based EDSL : table (multidim array), vector, matrix and tensor, polynom and rigid_transform. The rules I want to have is : - constant can mix with any other EDSL - SIMD don't mix with anybody - table mix with every other container and make them evaluates as table (e.g matrix * table == elementwise product and not matrix product) - vector, matrix, tensor can mix - polynom can mix with table but not with vector, matrix, tensor - rigid_transform van mix with table and matrix However i can't find any combination of domain definition that satisfy all. Is there some systematic methodologies to not fail at that ?
On 10/13/2010 11:38 AM, joel falcou wrote:
OK, I have a situation in which proto domain/subdomain could help me but i can't wrap my head around a proper solution. Here is the deal, i have various sub EDSL that goes like:
- constants EDSL provides named consatnts (like zero_, one_, pi_ etc) that are meant to be terminal usable in any other EDSL en provide a type based way to know which constant is beging used and provide optimization in came it helps (e.g detecting x < zero_ in SIMD EDSL to replace with the SSSE3 corresponding fused operation)
- a SIMD vector EDSL
- various container based EDSL : table (multidim array), vector, matrix and tensor, polynom and rigid_transform.
The rules I want to have is :
- constant can mix with any other EDSL
Make them terminals in no particular domain (proto::default_domain).
- SIMD don't mix with anybody
Define a SIMD domain with no super-domain.
- table mix with every other container and make them evaluates as table (e.g matrix * table == elementwise product and not matrix product) - vector, matrix, tensor can mix - polynom can mix with table but not with vector, matrix, tensor - rigid_transform van mix with table and matrix
This sounds like you want a type system for an EDSL. Proto can't do that in its current incarnation. The hackish solution is to let everything combine with everything, capture the above rules in a Proto grammar and assert at the point of expression evaluation that the expression conforms to the grammar. Type-checking sub-expressions sometimes requires writing transforms. It's tricky. Does that help? -- Eric Niebler BoostPro Computing http://www.boostpro.com
On 13/10/10 22:54, Eric Niebler wrote:
- constant can mix with any other EDSL
Make them terminals in no particular domain (proto::default_domain).
Check
Define a SIMD domain with no super-domain.
I thought domain with no super-domain ended up in default_domain ?
This sounds like you want a type system for an EDSL. Proto can't do that in its current incarnation. The hackish solution is to let everything combine with everything, capture the above rules in a Proto grammar and assert at the point of expression evaluation that the expression conforms to the grammar. Type-checking sub-expressions sometimes requires writing transforms. It's tricky.
hmmm ok. I'll play and tinker with this.
On 10/13/2010 2:11 PM, joel falcou wrote:
On 13/10/10 22:54, Eric Niebler wrote:
Define a SIMD domain with no super-domain.
I thought domain with no super-domain ended up in default_domain ?
Expressions in such a domain can only interoperate with other expressions of the same domain or with those of the default_domain (or sub-domains thereof). It's all described in excruciating detail here: http://www.boost.org/doc/libs/1_44_0/doc/html/boost/proto/deduce_domain.html HTH, -- Eric Niebler BoostPro Computing http://www.boostpro.com
participants (2)
-
Eric Niebler -
joel falcou