@amitsingh19975 @bassoy I had a few doubts while drafting the proposal for the GSoC Application.
- Since the second part of the implementation of
matrixandvectortypes, i.esubmatrixandsubvectoris dependent on the first project. Can I draft a proposal to work on the combination of these two projects into one. - If so what would the ideal order be like? For me it seems a preliminary implementation of
matrixandvectorbased as an extension oftensorwould not be that time consuming so beginning with that I can move towards working on thesubtensorand come back to implementsubmatrixandsubvector. Although doingsubtensorfirst and then doing the completematrixandvectoralong with their "sub" counterparts can also be a choice. - Another part I am not sure is the allocation of timeline. How much accurate should the timeline for the project be? in case of unexpected roadblocks etc.?
Thanks in Advance.
I am happy to announce that our GSoC students have successfully passed GSoC.
Both had an impactful contribution and showed great efforts to finalize their projects.
Congrats @exclowd and @shikharvashistha!
If you are interested in their projects, this is their wiki with project description.
@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 extentsOrder(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.
- should we put an invariant on static rank extents where the minimum order should be greater than one and lose the ability to alias the tensor into vector.
- should we make an exception for static rank extents and keep the aliasing ability.
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.
I tried to use the example given in https://github.com/boostorg/ublas#simple-example and I'm getting bugs on my system. The keywords 'index','tenson_dynamics' and 'ones' are unrecognized. Is it a bug or anything else?
@amitsingh19975 thanks for pointing this out. boostorg/ublas#150
Maybe you're using master branch of ublas. This feature is in develop branch right now.
Sir, how to use the develop branch?
https://github.com/boostorg/ublas/wiki/Guidelines-for-Contributors
5 replies
This is my user-config.jam.
using clang : : clang++ : <cxxflags>"-std=c++20" <linkflags>"" <link>"-lboost_unit_test_framework" ;I think you need to check your binary see the name of the GCC binary there, and then put it in here, or check the b2 document on how to set gcc toolset.
