> Had a little time to cook up Brad's suggestion as a full program (pasted in
> [code][/code]). It is much better with respect to communication (not
> unsurprisingly based on the comments above). Also, it looks a LOT cleaner.
Good!
> 1. Stylistically, camelCase everywhere? I noticed sometimes with domains,
> spaces, and locales you use CamelCase (there is probably a name for this,
> but I don't want to look it up). Is there a suggestion from you guys?
Most of us on the project use camelCase, but not exclusively --
underscores_still_appear at times. I'm probably an outlier, but I tend to
use InitialCapsCamelCase for distributed domains and arrays because, in my
mind, they are the big-ticket items from a cost/weight perspective and
deserve being distinguished in some way. Sometimes that bleeds over to
using initial caps for my "main" domains/arrays that define the overall
problem size/space as well in non-distributed programs. But again, I'd
say use personal preference -- I'm not a big one for imposing
naming/stylistic conventions on others (for better or worse) and to date
there is no Chapel style guide.
> 1. In this line `for (j, a) in zip({0..#dimension}, A(i(1), ..)) {`: I use
> 0 indexing everywhere, but I have to use i(1) in the for loop. It feels and
> looks awkward to me. Maybe it is unavoidable, but it will be hard to
> remember for me.
We tried to make Chapel as index-neutral as possible (i.e., arrays can
start at 0 or 1 or -3 or lo or whatever), but in a few places we had to
make a choice, where tuple indexing (what you're doing here) is one of the
main ones. I've tried to concoct ways of making tuple indexing either
index-neutral or at least user-configurable, but haven't yet come up with
anything appealing -- if you have ideas, send them in.
In the meantime, one way to avoid relying on tuple indexing is to detuple,
so:
const D = {1..n, 1..n};
forall (i,j) in D ... // i and j are integers
rather than:
forall ij in D ... // ij is a 2-tuple
This stacks with zippering as well:
forall ((i,j), a) in zip(D, A) ...
But shoot, in your code, vectorCyclic should really be yielding integers,
not tuples since it's 1D. This looks like a regression that has been
introduced since 1.14 to me (I assume you're working on master?) and is
likely something that I broke... 1D arrays can be indexed using either
1-tuples or integers, so I'm guessing that all of our existing tests just
feed the indices yielded by the loop back into array accesses and are none
the wiser... :( I'm going to see whether we can get a fix in before next
week's release to avoid this unintended change in behavior...
Bottom line, you _ought_ to be able to write the inner loop as:
for (j, a) in zip({0..#dimension}, A(i, ..)) {
and as a means of working around the regression and avoiding the tuple
indexing, for the time being, you can write the outer loop as:
forall ((i,), c) in zip(vectorCyclic, C) {
and once the regression is fixed can change back to simply:
forall (i, c) in zip(vectorCyclic, C) {
for (j, a) in zip({0..#dimension}, A(i, ..)) {
> I still want to produce some timing results, but it will take me a little
> bit of time. Then, on to the matrix-matrix product :)
Be sure to use the --fast flag before doing any timing experiments...
-Brad
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Chapel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-users
