-1

From the docs - v1.14 the second rule is

  • if indices[i] >= indices[i + 1], the i-th generalized “row” is simply a[indices[i]].

So how will this being used? Is there any real example?

I meant, there must(?) be some real situations that fit what this rule is doing, then we defined the rule to fit them, so what's that situation?

NeoZoom.lua
  • 2,269
  • 4
  • 30
  • 64
  • Take `np.add.reduceat([1, 2, 3], [2, 1])`. 2 is greater than 1, so the first reduction is just whatever is at index 2. – miradulo May 24 '18 at 04:10
  • @miradulo: Is there any reason why it's designed like this? I meant when someone designed this function, there must be a situation need this rule? Nice to see you again btw :) – NeoZoom.lua May 24 '18 at 04:20
  • 1
    There is some interesting discussion about `np.ufunc.reduceat` in [this](https://github.com/numpy/numpy/issues/834) GitHub issue. I don't think you're going to get any kind of satisfying general answer for this behavior - it is what it is. A number of NumPy devs actually want to deprecate `reduceat` altogether. – miradulo May 24 '18 at 04:21
  • The code needs to deal with the situation in one way or other. You or I could give it indices like that. It can try to return some 'reasonable' value, or it can raise an error. – hpaulj May 24 '18 at 04:22
  • @miradulo: Thank you for the link, I'm reading it. So should I delete this question? Sorry for my bad question... – NeoZoom.lua May 24 '18 at 04:25
  • @Niing IMO I'm not sure how answerable your question is, so you can if you'd like. But your call, and no need to apologize! – miradulo May 24 '18 at 04:27

1 Answers1

1

The first 2 examples make use of this rule.

In the 2nd example, the 2d array, it shows explicitly what [0, 3, 1, 2, 0] produces

# [row1 + row2 + row3]          0:3
# [row4]                        3
# [row2]                        1:2
# [row3]                        2 
# [row1 + row2 + row3 + row4]   0:end

In the first example, this rule is partly hidden by the [::2] indexing.

Without that:

In [183]: np.add.reduceat(np.arange(8),[0,4, 1,5, 2,6, 3,7])
Out[183]: array([ 6,  4, 10,  5, 14,  6, 18,  7])

There's [0:4]sum, [4], [1,5]sum, [5], [2:6]sum, [6], [3:7]sum, 7

Selecting just the odd results, we get 4 range sums:

In [184]: _[::2]
Out[184]: array([ 6, 10, 14, 18])

In [187]: [np.arange(0,4).sum(),np.arange(1,5).sum(),np.arange(2,6).sum()]
Out[187]: [6, 10, 14]
hpaulj
  • 221,503
  • 14
  • 230
  • 353
  • So the 4, 5, 6, 7 in your first example is just for separation? I when I for example one know 4 is at [i] then he knows (accumulative) result of the range ends at 4 is at [i-1]? – NeoZoom.lua May 24 '18 at 04:56
  • 1
    Separation isn't quite the right term, but they are surplus values when the goal is the sequence of overlapping sums. The spaces in `[0,4, 1,5, ...]` are for our convenience, not the code's. Otherwise we are stuck with contiguous, non-overlapping groupings. – hpaulj May 24 '18 at 05:33