Zip and azip! behavior related to inputted NdProducers

Open
#453 7 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
25/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Stale
Tech stack
rust
Domain
data

Research direction

Start by compiling the two azip! examples from the issue and compare the inferred dimensions of lanes(Axis(0)) with axis_iter(Axis(0)). Then inspect Zip, azip!, and IntoNdProducer behavior to determine whether the mismatch is an implementation bug or an intentional constraint; done means establishing and documenting the expected behavior, with a regression test if a bug is confirmed.

Written by the indexing model from the issue text.

Description

good first issue

Based on trying to help in Issue #452 , I found some interesting behavior regarding either Zip or azip!. I've given examples down below

    let a = arr3(&[[[ 0,  1,  2],
                [ 3,  4,  5]],
               [[ 6,  7,  8],
                [ 9, 10, 11]]]);
    let inner0 = a.lanes(Axis(0));

    let trial = arr1(&[0,0,0,0,0,0]);
    let tr_iter = trial.axis_iter(Axis(0));

    //The below will error out when compiling.
    azip!(ref output (inner0), ref trial (tr_iter) in {println!("{:?}, {:?}",output, trial); });

The compiler returns the following error:

error[E0271]: type mismatch resolving `<ndarray::iter::AxisIter<'_, {integer}, ndarray::Dim<[usize; 0]>> as ndarray::IntoNdProducer>::Dim == ndarray::Dim<[usize; 2]>`
   --> src/main.rs:141:5
    |
141 |     azip!(ref output (inner0), ref trial (tr_iter) in {println!("{:?}, {:?}",output, trial); });
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected an array with a fixed size of 1 elements, found one with 2 elements
    |
    = note: expected type `ndarray::Dim<[usize; 1]>`
               found type `ndarray::Dim<[usize; 2]>`
    = note: this error originates in a macro outside of the current crate

error[E0599]: no method named `apply` found for type `ndarray::Zip<(ndarray::iter::Lanes<'_, {integer}, ndarray::Dim<[usize; 2]>>, ndarray::iter::AxisIter<'_, {integer}, ndarray::Dim<[usize; 0]>>), ndarray::Dim<[usize; 2]>>` in the current scope
   --> src/main.rs:141:5
    |
141 |     azip!(ref output (inner0), ref trial (tr_iter) in {println!("{:?}, {:?}",output, trial); });
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = note: this error originates in a macro outside of the current crate

However, if I were to roll what inner0 outputs directly, I can get it to work no problem as seen below:

    let trial = arr1(&[0,0,0,0,0,0]);
    let tr_iter = trial.axis_iter(Axis(0));

    let b = arr2(&[[0,1,2,3,4,5],[6,7,8,9,10,11]]);
    let b_iter = b.axis_iter(Axis(1));
    //The compiler is perfectly okay with this code.
    azip!(ref output (b_iter), ref trial (tr_iter) in {println!("{:?}, {:?}",output, trial); });

I feel that either method should work, since we contain the same number of "items" to iterate over in each version. So, I was curious if this is simply an error/bug in the code or is there a design choice behind one method failing to compile and the other one working.

Dominant language
Rust
Stars
4.3k
Forks
391
PR merge metrics
No merged PRs in 30d

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from rust-ndarray/ndarray

All issues in rust-ndarray/ndarray

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.