The template parameter T3 is not used anywhere in the template, so I guess it can be removed. Also, from what I understand the return type will always be an RVec of floating point type. I personally do not see the reason to not always just have RVec<double>.

I think the benefit could be if the user wants float or some other floating point type, they have some options on how they call these functions (Linspace, Logspace, Arange) to yield the desired floating point type. For example (after the changes from the most recent commit to this PR), to illustrate some of this flexibility below:

root [1] Linspace(1, 10, 10)
(ROOT::VecOps::RVec<double>) { 1.0000000, 2.0000000, 3.0000000, 4.0000000, 5.0000000, 6.0000000, 7.0000000, 8.0000000, 9.0000000, 10.000000 }
root [2] Linspace(1.0f, 10.0f, 10)
(ROOT::VecOps::RVec<float>) { 1.00000f, 2.00000f, 3.00000f, 4.00000f, 5.00000f, 6.00000f, 7.00000f, 8.00000f, 9.00000f, 10.0000f }
root [3] Linspace<float, float>(1, 10, 10)
(ROOT::VecOps::RVec<float>) { 1.00000f, 2.00000f, 3.00000f, 4.00000f, 5.00000f, 6.00000f, 7.00000f, 8.00000f, 9.00000f, 10.0000f }
root [4] Linspace<long double, long double>(1, 10, 10)
(ROOT::VecOps::RVec<long double>) { 1.0000000L, 2.0000000L, 3.0000000L, 4.0000000L, 5.0000000L, 6.0000000L, 7.0000000L, 8.0000000L, 9.0000000L, 10.000000L }
root [5] Logspace(1.0f, 5.0f, 5, 10.0f)
(ROOT::VecOps::RVec<float>) { 10.0000f, 100.000f, 1000.00f, 10000.0f, 100000.f }
root [6] Logspace<float, float, float>(1, 5, 20)
(ROOT::VecOps::RVec<float>) { 10.0000f, 16.2378f, 26.3665f, 42.8133f, 69.5193f, 112.884f, 183.298f, 297.635f, 483.293f, 784.760f, 1274.28f, 2069.14f, 3359.82f, 5455.60f, 8858.67f, 14384.5f, 23357.2f, 37926.9f, 61584.8f, 100000.f }
root [7] Arange<float, float, float>(1, 10, 3)
(ROOT::VecOps::RVec<float>) { 1.00000f, 4.00000f, 7.00000f }
root [8] Arange<long double, long double, long double>(3, 15, 3.1)
(ROOT::VecOps::RVec<long double>) { 3.0000000L, 6.1000000L, 9.2000000L, 12.300000L }

I think we could get the desired functionality by simplifying this as follows:

template <typename T, typename Ret = double> Ret Linspace(T start, T end, unsigned long long n = 50, const bool endpoint=true) {
   const long double step = static_cast<long double>(end - start) / (n - endpoint);
   tmp.push_back(std::is_floating_point_v<Ret> ? start + i * step : std::floor(start + i * step));
}

Throughout the ROOT codebase, the Doxygen token used as sequence beginner is \ rather than @. See for example the docs of Construct from above: \begin, \tparam, \p etc. Please move all the @ instances to \ instead.

Similar comments that I made for LinSpace also apply here

My biggest concern for this PR are the complications added for the templates of all the three newly introduced functions. IMHO, I don't see why we should allow something like

auto arr = [Linspace/Logspace](1.f, 33,...);

I guess it should be more than enough to always have only one T parameter for all functions, and then change the return type to simply be

• RVec<T> if T is a floating point type
• RVec<double> otherwise
  Thoughts @dpiparo ?

In my opinion, we should also allow to return RVec as numpy does if you specify dtype=int.
So two template parameters:

• T for start/end
• Ret = double (by default), but can be changed to int.

Maybe having the same T for start and end would be a very useful simplification.
For what concerns returning RVec<int>: what would be the use case? Can this be covered by casting a RVec<double>?

For what concerns returning RVec<int>: what would be the use case? Can this be covered by casting a RVec<double>?

double myVector[100];
double myDecimatedVector[10];
for (auto const [idx, val] : std::views::enumerate(ROOT::VecOps::Linspace<auto, int>(0, 90, 10)))
   myDecimatedVector[idx] = myVector[val];

Yes, one could cast val to an int instead, true. But I just thought it's more convenient to follow the same conventions as numpy that allows you to specify dtype=int. And working with integers is safer than working with floating points wrt precision issues.

See silly reproducer below, the result is not the same with floats as with ints.

#include "ROOT/RVec.hxx"
#include <iostream>

template <typename T, typename Ret = double> ROOT::VecOps::RVec<Ret> Linspace(const T start, const T end, const unsigned long long n = 128, const bool endpoint = true, long double *const retstep = nullptr)
{
   ROOT::VecOps::RVec<Ret> temp;
   long double step = std::is_floating_point_v<T> ? (end - start) / (n - endpoint) : static_cast<long double>(end - start) / (n - endpoint);
   if (retstep)
      *retstep = step;
   temp.reserve(n);
   temp.push_back(static_cast<Ret>(start));
   for (unsigned long long i = 1; i < n; i++)
      temp.push_back(std::is_floating_point_v<T> ? static_cast<Ret>(start + i * step) : std::floor(start + i * step));
   return temp;
}

void linspace()
{
   double myVector[100000000];
   double myDecimatedVector[10];
   // with C++23: for (auto const [idx, val] : std::views::enumerate(Linspace<auto, int>(0, 90, 10)))
   auto idx = 0;
   for (auto val : Linspace<int, int>(100000000-100, 100000000-10, 10)) {
      myDecimatedVector[idx++] = myVector[val];
      std::cout << val << std::endl;
   }
   idx = 0;
   for (auto val : Linspace<int, float>(100000000-100, 100000000-10, 10)) {
      myDecimatedVector[idx++] = myVector[int(val)];
      std::cout << int(val) << std::endl;
   }
}

The same might happen if I use doubles, just at a later index (much bigger arrays). Giving the user the security to use unsigned long ints if they want to is useful.

fyi @edfink234

From my understanding this signature is still going against the documentation. It is clearly stated that

 * The function is templated to allow for different arithmetic types. The deduced type \c Common_t is
 * determined as follows: if \p T is a floating point type, that type is used;
 * otherwise, the arithmetic is performed using \c double.

But that is not all, the user can still specify LinSpace<float, int>. Now suddenly the common type is not the common type at all!

I still do not understand why the template needs to be anything more complicated than template <typename T>

Thanks Vincenzo for the feedback!

Now suddenly the common type is not the common type at all!

From my point of view:

• Common_t should be renamed to Output (or Ret_t return type) as I wrote in my suggested snippet. (and fixing step Adding LinSpace, LogSpace, and Arange prototypes #18200 (comment))
• The doxygen comment is wrong and should be fixed accordingly

I still do not understand why the template needs to be anything more complicated than template <typename T>

In my opinion, it's essential that the user can separately specify the auto-deduced input type and the (if-not-default) output type.

Example with your suggestion:

<typename Input> RVec<Input> Linspace(Input start, Input end, ...)

I write Linspace(3,5, 64)

So it's clear that I want double as returned values. But auto-deduction in this case will cast the return value to int's, hence returning nonsense. Of course, you could say it's the user fault, it should have specified Linspace(3.,5., 64), but that's not super-user-friendly. And it would go against the default behavior of np.linspace, so translatability of scripts to/from Python would be risked. Since

np.linspace(3,5, 64) == [3. , 3.03174603, 3.06349206, ... unless you force it to be ints via dtype=int.

Now you would argue, ok, let's always force that the return values are doubles even if inputs arguments are passed as ints.

<typename Input> RVec<double> Linspace(Input start, Input end, ...)

But that strategy would invalidate this other valid use case:

Linspace(1,10,10) where here I really want integers returned, not doubles, so that I can do for-range based loops using integers. And that would be a mismatch: some users could say why can I do in python dtype=int and not in C++?

So to me, the best compromise is really:
<typename Input, typename Output = double> RVec<Output> Linspace(Input start, Input end, ...)

Similar comment about the template here

Again similar comment about the template. Why should a user be able to do Arange<float, int>?

Otherwise floating point division is not ensured if user sets Ret=int

Needed for consistency, since static_cast rounds towards zero whereas std::floor rounds towards negative.

Or move this line inside the if-else clause and start at i=0 the loop.

Same as above. Or start loop at i=0

Same as above, or move inside loop.

This is needed to avoid an underflow if user calls Linspace(5UL, 1UL);

Same change needed below.

maybe it can be simplified as follows?

same in all below.

I would suggest casting to Ret_t only in the final result, not in the intermediate variables.

Maybe just cast to ret when you store things in temp vector, not the intermediate variables.

no need for Ret cast of intermediate variables?