Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement the Default trait for VecStorage, CsMatrix, CscMatrix, etc. #1206

Closed
wants to merge 1 commit into from

Conversation

SoutrikBandyopadhyay
Copy link

This commit solves #1204 and implements the Default trait for CsMatrix, CscMatrix, SparsityPattern, VecStorage.

This commit solves dimforge#1204 and implements the Default trait for CsMatrix,
CscMatrix, SparsityPattern, VecStorage.
Copy link
Collaborator

@Andlon Andlon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this PR, I agree that having more Default impls would make life easier, and I regularly run into the lack of these myself.

I'd prefer to have some sanity tests for the Default impls where you use the "try_from..." constructors to validate the output against what you expected. The current impl of CsMatrix is unsound and would be caught by such a test, see comments.

For the VecStorage impl I have an alternative suggestion that I think would be more practically useful, please see comment there as well.

@@ -22,6 +22,16 @@ pub struct CsMatrix<T> {
values: Vec<T>,
}

///The default implementation for the CsMatrix
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would suggest to just remove this doc comment, since it doesn't add anything of value and might get outdated in the future (say if we rename CsMatrix or something like that).

Same for the other default impls.

Self {
sparsity_pattern: Default::default(),
values: Default::default(),
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd prefer to be more explicit here, i.e. vec![] instead.

}
}
}

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think any dimensions actually implement Default at the moment 🤔

I think an alternative implementation could divide this into several cases:

  • R: DimName, C: DimName. In this case we need to require T: Default
  • R: DimName, C = Dynamic. In this case we can avoid requiring T: Default and create an "empty" matrix.
  • R = Dynamic, C: DimName. Same as the previous.
  • R = Dynamic, C = Dynamic. Same, we don't need T: Default.

This makes it possible to do

#[derive(Default)]
struct Wrapper<T> {
   vector: DVector<T>,
   matrix: DMatrix<T>,
}

without requiring T: Default. This is a common problem I'm frequently running into, at least.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note also that the proposed impl is unsound, because it always generates an empty vector regardless of whatever the dimensions are. This would lead to unsoundness whenever the dimensions are non-zero and any operation in nalgebra would try to index into the matrix.

major_offsets: Default::default(),
minor_indices: Default::default(),
minor_dim: Default::default(),
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is incorrect since major_offsets should have length major_dim + 1. An "empty" pattern would look like:

Self {
  major_offsets: vec![0],
  minor_indices: vec![],
  minor_dim: 0
}

@tpdickso
Copy link
Collaborator

It looks as if these changes with Andlon's recommendations were implemented in #1312 , so I'll close this pull request.

@tpdickso tpdickso closed this Dec 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants