freepooma-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [pooma-dev] Bug in field dependencies?


From: Stephen Smith
Subject: RE: [pooma-dev] Bug in field dependencies?
Date: Fri, 7 Jun 2002 10:18:25 -0600

This is the intended behavior.  The semantics you suggest
would be much better for the usability of Pooma, but we
forced this issue on the user for efficiency reasons.
Consider:

rh.all() = 1.0;
for (i = 0;...) for (j=0;...)
  rh(i, j) = 10.0;

At every step in the loop, we would have to call the
evaluator to check if there are outstanding expressions.
Actually, this might not be so bad, but we implement our
inner loops for _expression_ evaluation with the same array
operator()(int, int) so we would have to rethink the
implementation of _expression_ evaluation.

We have the command-line option --pooma-blocking-expressions
(and a function call, Pooma::blockingExpressions(true) I think...)
that force evaluation after every statement.  Turning this option
on enforces correctness at the expense of some parallelism.  For
example:

a = b;
c = d;
Pooma::blockAndEvaluate();
cout << a(5) << c(5) << endl;

In this example, we can evaluate parts of the two expressions
concurrently since they are independent of each other.  With
blocking expressions turned on, all of the first statement must
be evaluated before the second.

With blocking expressions turned off, the user if forced to
act like a compiler and determine where the blockAndEvaluate()
calls are necessary.  (Any time you assign to or read from an
array which may have outstanding evaluation work.)  I agree that
this is a bad interface choice.

    Stephen Smith

-----Original Message-----
From: Richard Guenther [mailto:address@hidden]
Sent: Friday, June 07, 2002 3:28 AM
To: address@hidden
Subject: [pooma-dev] Bug in field dependencies?

Hi!

If I have a 2d Field and do something like

 rh.all() = 1.0;
 rh(0, 0) = 10.0;

I'll end up with rh set to 1.0 everywhere - if I insert a
Pooma::blockAndEvaluate() inbetween the two assignments, it works
as expected.

Is this intended behavior or is it a bug? I'd think assigning to
rh(0, 0) should trigger the assignment to rh.all() to complete.

Thanks, Richard.

--
Richard Guenther <address@hidden>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/


reply via email to

[Prev in Thread] Current Thread [Next in Thread]