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

Add experimental/matrix and vector types #18

Open
coder3101 opened this issue Jul 24, 2020 · 1 comment
Open

Add experimental/matrix and vector types #18

coder3101 opened this issue Jul 24, 2020 · 1 comment
Assignees
Labels
discussion the issue and current state of issue needs to be discussed enhancement New feature or request future-work Deferred to be worked in later stage of GSOC or after GSOC

Comments

@coder3101
Copy link
Collaborator

Add a new experimental subdirectory inside tensor, which provides matrix and vector types that are type aliases for existing tensor types.

Add type traits for the experimental types such as is_matrix, add all functions that existed in ublas::matrix to new types as free functions.

Add examples demonstrating the usage of new experimental types. We can put them in examples/tensor/experimental.

Also add unit tests so code coverage doesn't degrades.

@coder3101 coder3101 added the enhancement New feature or request label Jul 24, 2020
@coder3101 coder3101 self-assigned this Jul 24, 2020
@coder3101 coder3101 added this to the GSOC Phase 2 milestone Jul 24, 2020
@coder3101 coder3101 modified the milestones: GSOC Phase 2, GSOC Phase 3 Aug 8, 2020
@coder3101 coder3101 added the discussion the issue and current state of issue needs to be discussed label Aug 8, 2020
@coder3101
Copy link
Collaborator Author

Should we allow the matrix types and vector types to be creatable from implied or explicit tensor extents.

Case 1: (Implied)
A tensor of extents {1,2,3,1} is convertible into a matrix type if we squeeze the extents (Squeezing means removing extents with value 1). This yields a matrix of extents {2,3}.

Example:

ublas::experimental::dynamic_matrix a<int> = dynamic_tensor<int>({1,2,3,1}); // a's extent is {2,3}
ublas::experimental::static_matrix b<int> = static_tensor<int, 2,3,1,1>{} // b's extent is <2,3>
ublas::experimental::dynamic_matrix c<int> = dynamic_tensor<int>({4,3}); // c's extent is {4,3}
ublas::experimental::static_matrix d<int> = static_tensor<int, 2,3>{} // b's extent is <2,3>

Benefits:

  • Tensor contractions results can be directly assigned to matrices and vectors.
  • More flexible and limited restriction on matrix types

Case 2: (Explicit)
Matrix constructor restricts the tensor to be rank 2. If the above extent tensor is to be assigned to a matrix type, the extents must be squeezed by the user.

Example:

ublas::experimental::dynamic_matrix a<int> = squeeze(dynamic_tensor<int>({1,2,3,1})); // a's extent is {2,3}
ublas::experimental::static_matrix b<int> = squeeze(static_tensor<int, 2,3,1,1>{}) // b's extent is <2,3>
ublas::experimental::dynamic_matrix c<int> = dynamic_tensor<int>({4,3}); // c's extent is {4,3}
ublas::experimental::static_matrix d<int> = static_tensor<int, 2,3>{} // b's extent is <2,3>

@coder3101 coder3101 removed this from the GSOC Phase 3 milestone Aug 25, 2020
@coder3101 coder3101 added the future-work Deferred to be worked in later stage of GSOC or after GSOC label Aug 25, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion the issue and current state of issue needs to be discussed enhancement New feature or request future-work Deferred to be worked in later stage of GSOC or after GSOC
Projects
None yet
Development

No branches or pull requests

1 participant