Some details about unintuitive behavior

Here are some "gotchas", places where the DAPPLE semantics lead to surprising results:

• Mixing scalars and vectors of different types in an expression is sometimes surprising. In C, multiplying an int and a float promotes the int to a float before doing a floating-point multiply. In DAPPLE, however, multiplying an intVector and a float scalar will cast the scalar to an int before doing the intVector/int multiply, which is not intuitive. The same happens for comparisons, etc. Fortunately, g++ with the -Wall option will warn you when this happens.
• Both branches of ifp() always execute. This is typical data-parallel semantics, but can be surprising to the new data-parallel programmer. For example: boolean zero; intVector X(N); ... ifp (x == 0) zero = true; else zero = false; This will always set zero to true, then to false, leaving it at false. The programmer probably wanted a reduction: zero = all(x == 0);
• break or goto inside of an ifp() does not do what you expect: intVector X(N); ... while (...) ifp (x == 0) break; else ... Typical data-parallel semantics, which say that both the "then" and "else" clauses get executed, make branching out of those clauses hard to define. Unfortunately, I can't prevent it in DAPPLE. If you try it, chaos results.

• Next: What are you missing?
• Back to the "DAPPLE introduction" menu