The Range method is producing some unexpected results

[CatchemAL]

vec1 and vec3 look funny to me. Is this a feature or a bug?

double[] vec1 = Vector.Range(0d, 5d, 1d);                       // { 0, 1, 2, 3, 5 }
double[] vec2 = Vector.EnumerableRange(0d, 5d).ToArray();       // { 0, 1, 2, 3, 4 }
double[] vec3 = Vector.EnumerableRange(0d, 5d, 1d).ToArray();   // { 0, 1, 2, 3, 4, 5 }

Thanks,
Alex

[cesarsouza]

Hi @AlexJCross,

Thanks a lot for catching that. The Range method is supposed to behave exactly like Python's range(x), and EnumerableRange as Python's xrange(x). So all of those should have produced (0, 1, 2, 3, 4) as an answer.

[CatchemAL]

Yep agree with that 100% (there was a typo in my initial message). I am looking at a few other things in Accord right now so won't be able to look at this for a while. If you have time to look at it, that would be great. If not - no worries - I will look at it in a few week's time.

Thanks,
Alex

[cesarsouza]

Cool! I will try to take a look at this issue as soon as I finish #890.

[cesarsouza]

I've just committed a complete review of the Interval and Range methods, making sure they follow NumPy's linspace and arange methods as close as possible, as they were intended to do anyways. The problem is that this should actually introduce a large breaking change for anyone currently depending on the previous, incorrect behavior.

[CatchemAL]

Oh brilliant. I'll try to have a look at this when back tonight. IMHO, the Python functions are so ubiquitous I don't think many people will be knowingly using the current 'incorrect behaviour'. Perhaps this will fix a few bugs downstream :)

[cesarsouza]

Fixed in 3.8.0.