DickJC123 edited a comment on issue #14954: broadcast_to() behavior change after new 0D and uninitialized shape support added? URL: https://github.com/apache/incubator-mxnet/issues/14954#issuecomment-492867737 The 5 tests that fail do so because the test is trying to save and restore a 2D NDArray with a 0 size for one of the dimensions. I have not played with numpy compatibility modes for the tests, but in each case the last 3 of the following code lines is causing problems by converting for example (0,1) -> (-1,1): https://github.com/apache/incubator-mxnet/blob/c5265fbf635965b5124df2d7dcea1b57c6508b73/src/ndarray/ndarray.cc#L1713-L1718 So you might say 'put the 5 tests in numpy_compatibility_mode.' However, I started thinking about the notion of TShape serialization. Ideally, the representation (and what it means) should not depend on the mode of the writer. Why not always save TShapes in the expanded 'numpy_compatibility mode' representation (unknown = -1, known-0 = 0, known-non-zero = N), regardless of the mode of the writer? The code in ndarray.cc might then be: ``` void NDArray::Save(dmlc::Stream *strm) const { ... // save shape auto stored_shape = shape_; if (!Imperative::Get()->is_np_comp()) { common::ConvertToNumpyShape(&stored_shape); } stored_shape.Save(strm); ... } bool NDArray::Load(dmlc::Stream *strm) { ... // load shape mxnet::TShape shape; if (!shape.Load(strm)) return false; if (!Imperative::Get()->is_np_comp()) { common::ConvertToLegacyShape(&shape); } ... }
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services