The nested container resize_as() function misbehaves, in beta 4 and beta 5, Sandy Bridge or Core 2, Debug or Release modes in MSVC 10. Consider this code (pretty print code below):

dense dat = dense::parse("{1.,2.,3.,4.}");
nested idx = nested::parse("{{3},{2},{1,1},{0,0}}");
nested out = reshape_as(dat, idx);

...from which I expected this result, reading the docs:

out: {{4},{3},{2,2},{1,1}}
flat: 4 3 2 2 1 1

...instead the result is:

out: {{1},{2},{3,4},{0,0}}
flat:1 2 3 4

Apparently an improper nested container has been constructed with too little data, without throwing an exception, and operator(i,j)"reads" beyond the available data without complaint.If the data is changed to:

dense dat = dense::parse("{1.,2.,3.,4.,5.,6.,7.,8.}");

...the result is:

out: {{1},{2},{3,4},{5,6}}
flat:1 2 3 4 5 6 7 8

Another apparently improper nested container with too much data.

If reshape_as() merely operates like reshape_nested_lengths(), ~offsets(), and ~flags() there would be no excuse for the reference argument to be nested. It could be any nested type. While not explicitly documented, one suspects reshape_as() is the nested equivalent of the dense's gather() function ...especially since there is no other. In any case, reshape_as() does unexpected things.

- paul

Pretty printing code:

cout << "out: {";
_for(usize i = 0, i < idx.offsets().length(), ++i)
_if(c0) {
cout << "},"; } _end_if;
c0 = true;
cout << "{";
boolean c1 = false;
_for(usize j = 0, j < idx.segment(i).length(), ++j)
_if(c1) {
cout << ","; } _end_if;
c1 = true;
cout << value(out(i,j));
} _end_for;
} _end_for;
cout << "}}" << endl;
dense flat = out.flatten();
cout << "flat:";
const_range r = flat.read_only_range();
for (const_range::const_iterator i = r.begin(); i != r.end(); ++i)
cout << *i << " ";
cout << endl;

3 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.


I think the problem is caused by a misreading of the documentation. The description of reshape_as() for nested containers says:

nestedarbb::reshape_as (const dense< T, 1 > &data, const nested< U > &reference)
Returns a nested container with the same nesting structure as reference, but elements drawn from data.

The second parameter 'reference' is used only as a shape reference. The returned nested container will have the exactly same shape of 'reference'. The actual content of 'reference' has nothing to do with the shape of the returned nested container. So there isn't a problem in your first example. Note when the source doesn't have enough items to be drawn, the uncovered items in the returned container are initialized with the default value.

Also note the data type of 'reference' doesn't have to be usize. It can be any data type because what's important here is its shape not its content. For example, replacing 'idx' in your first example with the following produces the same nested container:

nested idx = nested::parse("{{0},{0},{0,0},{0,0}}");

Your second example does indicate there is a bug in nested::flatten(). It should not return a container with more elements than the source container. Thanks for bringing this to our attention. We will log this issue and fix it in a future release.

Hi Zhang,

I agree the documentationcould be improvedi.e. "elements drawn" could mean "at random," or at least in some unspecified manner that may changein a subsequent release.Please bespecific. The ArBB team knows what thewords mean, but actuallythese wordsareintended for "the rest of us."

My mistake for reading nested as nested. Will make an appointment with my eye doctor.

I disagree with your take of the first example.The result had the right shape, but uncovered items were not initialized with a default value. These were missing entirely i.e. the shape info specifies more data than is held by the container. This can be seen manuallyin Debug mode, as well.

I also disagree with your take of the second example. The problem is not with nested::flatten(). There is actually more data in the container than its shape infospecifies. This can be seen manuallyin Debug mode, as well. It would seemboth problems are with reshape_as().

- paul

Leave a Comment

Please sign in to add a comment. Not a member? Join today