# New syntax for slicing

**URL:** <https://discourse.julialang.org/t/new-syntax-for-slicing/91241>\
**Category:** Internals & Design\
**Tags:** proposal, arrays\
**Created:** [December 5, 2022, 2:54am UTC](https://discourse.julialang.org/t/new-syntax-for-slicing/91241 "2022-12-05T02:54:28Z")\
**Posts on this page:** 1\
**Showing post:** 14

<div class="post-metadata">

**Author:** ![mcabbott](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mcabbott/32/6603_2.png) [@mcabbott](https://discourse.julialang.org/u/mcabbott)\
**Post date:** [December 7, 2022, 3:33am UTC](https://discourse.julialang.org/t/new-syntax-for-slicing/91241/14 "2022-12-07T03:33:41Z")

</div>

> [@ParadaCarleton](#):
>
> what I assume the implementation with the `dims` keyword is doing

It leads to [`centralize_sumabs2!`](https://github.com/JuliaStats/Statistics.jl/blob/e9ac70b760dcf87b77affe6c068548a3325d6e2b/src/Statistics.jl#L248-L290), which looks a lot like a re-implementation of reduce. I guess it’s not literally `reduce` as it has to index the array of pre-computed means at the same time as the input & output arrays. Are you suggesting a tidier way to implement that?

The case without dims is literally `mapreduce(centralizedabs2fun(m), +, A)` (just above). And this is what’s called by any map over slices, of course. It pre-computes the mean, whereas [OnlineStats.jl](https://github.com/joshday/OnlineStats.jl/blob/1fca9957372d6120bf80f11bca56356d3a7e3609/src/stats/kahan.jl#L112-L129) does it in one pass, but seems slower.

I’m not sure if we’re talking about a notation for slicing anymore, though, so much as how best to (a) implement various reduction-like things efficiently, and (b) how best to call them.

For (a) it seems clear that the implementation cannot always just work on slices. For (b), one objection to an API which pretends you are working with slices, while actually doing something different, is that this seems a little fragile. It’s a magic fast path a little like the `reduce(vcat, xs)` one – which has [surprising](https://discourse.julialang.org/t/how-can-i-do-list-comprehension-for-vcat/84178/11) ways to step off the fast path accidentally. With the “ugly design” of having a `dims` method _if and only if_ there exists a faster-than-slices implementation, at least you know what you’re getting.

I assume that’s the implicit rule in Base/std.lib. But might be wrong; are there examples of things with `dims` methods which do just always call `mapslices` or something? (Is seems that [`median`](https://github.com/JuliaStats/Statistics.jl/blob/e9ac70b760dcf87b77affe6c068548a3325d6e2b/src/Statistics.jl#L866) does call mapslices, but uses mutation to do a bit better than `mapslices(median, x; dims)`.)

> [@ParadaCarleton](#):
>
> implement the optimizations we currently do case-by-case for `sum`, `var`, etc. in a more general way

Quite a few do share the same implementation as `sum`. Maybe it would help to list others you include in “etc”?

---

_[View the full topic](https://discourse.julialang.org/t/new-syntax-for-slicing/91241)._
