mclow on boost-1.80.0
bassoy on develop
chore: bump macos runner versio… (compare)
mclow on boost-1.80.0.beta1
@amitsingh19975
Yes, there are two things that missing:
- Vector implementation
A Vector would just be a column or row of a matrix right? I.e. a matrix of {R, 1} or {1, C} dimensions, or should I update my implementation to create a new Vector class based off an array?
That's true and there are a few reasons because of which we need a specialized version of vector:
I have one questions for you why use the vector of vector?
I was comfortable with vectors. Upon deeper thought, a multidimentional-array based implementation would have worked better. I'll update my code to use the same!
why do you even need multidimensional arrays? Please look at the tensor_core
, Eigen
or any other high quilty library and see how it handles the matrix or tensor.
@amitsingh19975
why do you even need multidimensional arrays? Please look at the
tensor_core
,Eigen
or any other high quilty library and see how it handles the matrix or tensor.
Oh I understand, but what added benefits does A[i + C*j] give over something like A[i][j]?
I'll create a layout parameter too then, and go for a 1D array with A[i + x*j] where x = R or C according to the user wanting row major or column major.
@amitsingh19975
Yes, there are two things that missing:
- Vector implementation
A Vector would just be a column or row of a matrix right? I.e. a matrix of {R, 1} or {1, C} dimensions, or should I update my implementation to create a new Vector class based off an array?
That's true and there are a few reasons because of which we need a specialized version of vector:
- we are trying to replace the previous implementation
- it gives more control over the construction
- the normal user expects to find a vector class.
I have one questions for you why use the vector of vector?
I was comfortable with vectors. Upon deeper thought, a multidimentional-array based implementation would have worked better. I'll update my code to use the same!
why do you even need multidimensional arrays? Please look at the
tensor_core
,Eigen
or any other high quilty library and see how it handles the matrix or tensor.
Can there be two types for row vector and column vector? have the user customize the vector class via template arguments. It would give the user a much more explicit notation.
@amitsingh19975
why do you even need multidimensional arrays? Please look at the
tensor_core
,Eigen
or any other high quilty library and see how it handles the matrix or tensor.Oh I understand, but what added benefits does A[i + C*j] give over something like A[i][j]
A[i][j]
you restricted with a particular layout and in C++
you will be stuck with row-major.A[i + C*j]
you know they are contiguous in memory and pointed by a single pointer, not the pointer of pointers, you can pass them around without incurring performance loss.@abakfja
Can there be two types for row vector and column vector? have the user customize the vector class via template arguments. It would give the user a much more explicit notation.
No need for two different types, we can use layout for example
auto row_vector = Vector<float, layout::row_major>(...);
auto col_vector = Vector<float, layout::col_major>(...);
you could something like this.
@amitsingh19975
why do you even need multidimensional arrays? Please look at the
tensor_core
,Eigen
or any other high quilty library and see how it handles the matrix or tensor.Oh I understand, but what added benefits does A[i + C*j] give over something like A[i][j]
- with the
A[i][j]
you restricted with a particular layout and inC++
you will be stuck with row-major.- if you need to extend for more dimensions, you will need to specify the dimension in advance, which is impossible for higher dimensions like a tensor.
- with the
A[i + C*j]
you know they are contiguous in memory and pointed by a single pointer, not the pointer of pointers, you can pass them around without incurring performance loss.- and also compiler can help optimize the code.
Sure, can we use the existing layouts(boost::numeric::ublas::column_major and boost::numeric::ublas::row_major) in the competency test? In the implementation we would be specializing tensor_core which already has layout defined.
tensor_core
, but you can use the layouts defined by the boost because most of the operations are defined for the tensor, and there won't be much left to show your knowledge. If @bassoy beg to differ, then you can use it as he is the guy who has given the test.
For me, in a competency test, you shouldn't use
tensor_core
, but you can use the layouts defined by the boost because most of the operations are defined for the tensor, and there won't be much left to show your knowledge. If @bassoy beg to differ, then you can use it as he is the guy who has given the test.
I will not use tensor_core
in the competency test, by implementation I meant the actual project period.
Boost.uBLAS
, is there a reason for it? Once you have forked the project and implemented the matrix, write the unit test using the boost unit test library in the test folder. After you are done with it, revert to me then I have a few questions for you.
tensor_core
.
I implemented the given competency test. So, I request the mentors to review it. @bassoy @amitsingh19975
@shadymohamedamin, please go through the competency test again and follow the instructions. You need to create classes for matrix and vector, not hard-coding them.
Dear Mentor correct me if I wrong,
tensor
is a mathematics topic and The code oftensor
is written insidetensor_core.hpp
and many other header files .
Yes, isn't the matrix and vectors, though? I see matrix and vectors as the tensor's specialisation, and some will say the tensor is the extensions of vectors and the matrix into higher dimensions.
@amitsingh19975 @bassoy I had a few doubts while drafting the proposal for the GSoC Application.
matrix
and vector
types, i.e submatrix
and subvector
is dependent on the first project. Can I draft a proposal to work on the combination of these two projects into one. matrix
and vector
based as an extension of tensor
would not be that time consuming so beginning with that I can move towards working on the subtensor
and come back to implement submatrix
and subvector
. Although doing subtensor
first and then doing the complete matrix
and vector
along with their "sub" counterparts can also be a choice.Thanks in Advance.
@bassoy, I've created a new branch "fix/extents" to fix the existing problem with the ambiguous extents. My approach would be making the extents to be at least of 2nd order. Therefore, we can discern between static tensor and static rank tensor.
auto e0 = extents<1>{}; // [static rank extents] invalid because of 1st order static rank extents
auto e1 = extents<1,2>{}; // [static extents] valid because of 2st order static extents
auto e2 = extents<2>{}; // [static rank extents] valid because of 2st order static rank extents
auto e3 = extents<>{4}; // [dynamic extents] invalid because of 1st order dynamic extents
auto e4 = extents<>{4,4}; // [dynamic extents] valid because of 2st order dynamic extents
Order(Static Extents|Dynamic Extents) > 1 and Order(Static Rank Extents) == 1. Therefore, there is no ambiguity.
@bassoy, there's one problem here, and I don't know which solution is better.
There's one downside of alias on clang right now: they haven't implemented the type deduction for alias type. This makes it impossible to deduce the template types from the constructor.