Closed dbsxdbsx closed 3 years ago
Without being able to see your code, I would guess this could be due to fortran-style vs c-style row ordering?
If the matrix produced is a transpose, then it's possible the slice will look different (slice can't take into account strides other than 1).
@davidhewitt , the code is here:https://github.com/spebern/tch-distr-rs/blob/master/tests/against_python.rs.
when change code on line 885 to test_cases.sample = Some(vec![vec![1], vec![3]]);
and test the categorical
block, the issue occurs.
We tested it on ubuntu 20.
I'm afraid I don't have time to try to evaluate all that code; can you add this to your evaluation:
println!("rust pyarray state: {:?} {:?} {:?}", rust_side_array.is_c_contiguous(), rust_side_array.is_fortran_contiguous(), rust_side_array.strides());
println!("python pyarray state: {:?} {:?} {:?}", python_side_array.is_c_contiguous(), python_side_array.is_fortran_contiguous(), python_side_array.strides());
If my guess is correct, you will see that these arrays are laid out differently.
@davidhewitt ,thanks for your advice, I think you are right. Now, before comparison, I force array to be contiguous, and now no error occurs. code like this:
python_side_array.call_method0("contiguous")
.unwrap()
.call_method0("numpy")
.unwrap()
.extract()
.unwrap()
And several days ago I also found that, for some case, if the array is not contiguous, they can not be called with as_cell_slice
.
with system
Ubuntu 20.04.3 LTS
:I am doing some test by checking whether the numpy object from python is the same as the one produced by rust code. Core code like this:
For this code, every assersion is passed until it comes with this matrix (printed by
rust pyarray1
):The matrix from both rust and python are the same, but after
as_cell_slice
, they are of DIFFERENT order.I can not figure out what is wrong there, I've check if this is related to orignal type, seems not.
By the way, I want to know how to compare 2 arrays if there is
NaN
. I want to treatNaN
as equivalence.