Open mtfishman opened 3 months ago
I think the current behaviour is correct...
Yeah I think you are right, I just found it surprising. I think ultimately what I wanted was a function that implemented findblock(only(axes(r)), k)
, which I think is a more useful concept/functionality.
It seems like for it to be well defined beyond sorted collections with unique elements (like unit ranges), it should be called findfirstblock
, but that is another issue.
Call it findaxesblock? For matrices would also support findaxesblock(A, k, j) returning a Block{2}
findaxesblock
seems fine. I'm still not a huge fan of using the naming convention find*
for this kind of operation, which is ultimately a conversion from a cartesian index to a block index, which is what inspired my proposal of BlockIndices(a)[k]
in #346. Also findaxesblockindex(A, k)
gets a bit long, but I suppose so is the interface proposed in #346, where the best I can come up with for the equivalent of findaxesblock(a, k)
would be block(BlockIndices(a)[k])
, or maybe a slight shorthand block(BlockIndices(a), k)
which could skip some of the extra operations needed to get the offset within the block.
Perhaps I am misunderstanding how
findblock[index]
is supposed to work, but this behavior is confusing to me:I expected it to return:
i.e. in a call to
findblock(r, k)
, I was interpretingk
as an index, and thoughtfindblock
would output the block that index is in, but it seems to be interpretingk
as a value, and is outputting the block that value is in.Maybe the giveaway is that
find*
functions inBase
find the index of a value, so the current behavior offindblock
is consistent with that convention, and really I was just hoping for a different function with a different functionality.