Fernando José

We do a small trick. Look at the end of SGVector.cpp. There, we have defined the classes for which SGVector can be templated (which are basically primitive data types).

If they are not used anywhere, I'd say we can drop them. We can for sure drop the ones in SGVector. The CMath one can stay.

In my opinion, `void CMath::qsort(SGVector)`, `SGVector CMath::argsort(SGVector)`, and `bool CMath::is_sorted(SGVector)` make sense.

@curiousguy13, it sounds good to me, both range_fill and range_fill_vector should go out of SGVector. Do something nice with them (perhaps, simplifying to only one method) and move to CMath....

It sounds good! On 18 Feb 2015 10:26, "Soumyajit De" [email protected] wrote: > @iglesias https://github.com/iglesias I think range_fill, zeros, these > are perfect to be shifted to linalg instead. >...

> @karlnapf so this works now, a minimal example looks like this: > > ```c++ > #include > #include > #include > #include > #include > > using namespace shogun;...

Any preference to organize merging this and the other PR that triggered this experiment, @saatvikshah1994? I am guessing it may make sense to merge the other one first and then...

All CI tasks good. @saatvikshah1994, I can't merge from here due to the conflicts marked above. Would you mind doing the manual job to fix the conflicts? I will merge...

That is a point. However, I think that for rather common operations (like the sine) which are included in the C++ standard, we can just go along using the C++...

> ``` > case S1: CHECKRANGE(S1,char); break; > case U1: CHECKRANGE(U1,unsigned char); break; > case S2: CHECKRANGE(S2,short); break; > case U2: CHECKRANGE(U2,unsigned short); break; > case S4: CHECKRANGE(S4,int); break; >...