Thank you Tim for explaining that more clearly. This morning's reply was ENOCOFFEE :D
Please do file an issue, Nils, and thanks for investigating further. On Wednesday, April 8, 2015 at 10:03:04 AM UTC-5, Tim Holy wrote: > > Sounds like a bug, but I think what Patrick was trying to say is that it > would > help to test it with Arrays first just to make sure there's not some > problem > with your code. Assuming that it works for Arrays but not for > SharedArrays, > then you should probably file an issue. > > Best, > --Tim > > On Wednesday, April 08, 2015 05:57:54 AM Nils Gudat wrote: > > Hi Patrick, > > > > Sorry for the late reply (Easter and all that)! The problem with using > > Arrays in the code above is that they're not available for remote > processes > > to write on, so I'd have to come up with a more complicated structure of > > passing computations and results around. The whole appeal of > SharedArrays > > to me is that they make this unnecessary and therefore lend itself > > perfectly to facilitate easy parallelization of the kind of problems > > economists are often facing (basically filling large Arrays with the > > results of lots and lots of simple maximization problems). One way to > get > > around both problems would be to initialize the Array as > > > > nprocs() > 1 ? result1 = SharedArray(Float64, (3,3,3)) : result1 = > > Array(Float64, (3,3,3)) > > > > The main reason for my original post here was to see whether anyone > could > > explain why SharedArrays behave in this way when used on one process and > > whether this was potentially a bug (or at least something that should be > > mentioned in the docs). > >
