On 7/14/2012 11:07 PM, Mathias Gaunard wrote:
> On 07/15/2012 08:04 AM, Mathias Gaunard wrote:
>
>> Assuming your expressions are CopyConstructible
For the record, in proto-11 no rvalues are stored by reference within
expressions by default.
> You'd also need them to be EqualityComparable or to
On 07/15/2012 10:25 AM, Bart Janssens wrote:
OK, thanks for the comments. It's similar to what I had in mind, but
(unless I'm missing something) all product terms in our expressions
should have a distinct type if they represent different values, so I
could get away with just using a fusion map a
On Sun, Jul 15, 2012 at 8:04 AM, Mathias Gaunard
wrote:
> Of course Proto expressions are not safely CopyConstructible by default, so
> you'd have to be careful to make it work.
>
> This is a global approach, so you'll end up committing to memory all your
> past results. This is probably not desir
On Friday, July 13, 2012 21:51:40 Bart Janssens wrote:
> Hi guys,
>
> I've been thinking about a feature for our DSEL, where lots of matrix
> products can occur in an expression. Part of an expression might be:
> nu_eff * transpose(nabla(u)) * nabla(u) + transpose(N(u) +
> coeffs.tau_su*u_adv*nabl
On 07/15/2012 08:04 AM, Mathias Gaunard wrote:
Assuming your expressions are CopyConstructible
You'd also need them to be EqualityComparable or to use a comparator to
use them as keys. A recursive call to fusion::equal_to would probably be
a good definition.
On 07/14/2012 08:46 AM, Joel Falcou wrote:
In NT2, we use a schedule transform that iterate the expression tree and
evaluate expression tagged as being needed to be evaluated once and
store them in some shared_ptr like terminal. This allow us to "schedule"
our loop nests in the proper order.
Th
Le 13/07/2012 23:55, Eric Niebler a écrit :
This is an instance of the larger "common subexpression elimination"
problem. The problem is complicated by the fact that it can't be solved
with type information alone. u_adv*nable(u) might have the same type as
u_adv*nable(v) but different values. A h
On Fri, Jul 13, 2012 at 11:55 PM, Eric Niebler wrote:
> On 7/13/2012 12:51 PM, Bart Janssens wrote:
> This is an instance of the larger "common subexpression elimination"
> problem. The problem is complicated by the fact that it can't be solved
> with type information alone. u_adv*nable(u) might h
On 7/13/2012 12:51 PM, Bart Janssens wrote:
> Hi guys,
>
> I've been thinking about a feature for our DSEL, where lots of matrix
> products can occur in an expression. Part of an expression might be:
> nu_eff * transpose(nabla(u)) * nabla(u) + transpose(N(u) +
> coeffs.tau_su*u_adv*nabla(u)) * u_a
Hi guys,
I've been thinking about a feature for our DSEL, where lots of matrix
products can occur in an expression. Part of an expression might be:
nu_eff * transpose(nabla(u)) * nabla(u) + transpose(N(u) +
coeffs.tau_su*u_adv*nabla(u)) * u_adv*nabla(u)
Here, u_adv*nabla(u) is a vector-matrix pro
10 matches
Mail list logo
