Add me to the list of people excited about slicing changes.
Is there any way '|' could be distinguished from the boolean operation? As
in, a|1,:,:| ?
What about a[k,.,.]? The dots would remind me that it handles singleton
dimensions in a special way.
Ooh, what about a[k,\cdot,\cdot]? ;-) That looks pretty cool in my REPL.
I realize it is bound to Base.dot. But damn it looks cool.
Also, why don't we have a squeeze(A::AbstractArray{T,N}) method that
eliminates all singleton dimensions? If we had that, indexing returning
singleton dimensions wouldn't be as bad. Currently, having to write
squeeze(a[k,:,:],1) is terrible. That is something where Matlab wins.
On Wednesday, September 3, 2014 12:39:54 PM UTC-5, Stefan Karpinski wrote:
>
> "Indexing" with curly braces already means something – that's how you
> specify type parameters. Unfortunately, there are not very many ASCII
> paired brackets.
>
>
> On Wed, Sep 3, 2014 at 1:11 PM, Bob Nnamtrop <bob.nn...@gmail.com
> <javascript:>> wrote:
>
>> I think using curly braces to denote indexing with dropped singleton
>> dimensions would be nice:
>>
>> eg
>> a[1,:,:] works as now, returns an Array with 3 dimensions
>> a{1,:,:} returns an Array with 2 dimensions
>>
>> I realize this has syntax conflicts at this point but it seems it could
>> be made to work.
>>
>> Bob
>>
>>
>>
>> On Wed, Sep 3, 2014 at 10:05 AM, ggggg <galen...@gmail.com <javascript:>>
>> wrote:
>>
>>> Would it be possible and/or worthwhile to allow indexing with dropped
>>> singleton dimensions with a period modified.
>>>
>>> eg
>>> a[1,:,:] works as now, returns an Array with 3 dimensions
>>> a.[1,:,:] returns an Array with 2 dimensions
>>>
>>> It sort of fits into the use of . as a modifier to represent
>>> broadcasting.
>>>
>>> On Wednesday, September 3, 2014 6:31:31 AM UTC-6, Stefan Karpinski wrote:
>>>
>>>> It depends on what you mean. If you mean non-copying slices, then yes.
>>>> If you mean that all singleton slices are dropped, then that seems less
>>>> likely.
>>>>
>>>>
>>>> On Wed, Sep 3, 2014 at 7:20 AM, Neal Becker <ndbe...@gmail.com> wrote:
>>>>
>>>>> I hope the goal is for slicing to work like numpy.
>>>>>
>>>>> Stefan Karpinski wrote:
>>>>>
>>>>> > No, this is a pretty contentious issue. A lot of the relevant
>>>>> discussion is
>>>>> > in #4774 <https://github.com/JuliaLang/julia/issues/4774>. The one
>>>>> thing
>>>>> > everyone agrees on which is going to happen in 0.4 for sure is that
>>>>> slicing
>>>>> > will generally create views into the original array rather than
>>>>> copying the
>>>>> > data.
>>>>> >
>>>>> >
>>>>> > On Tue, Sep 2, 2014 at 2:24 PM, Christoph Ortner
>>>>> > <christop...@gmail.com
>>>>>
>>>>> >> wrote:
>>>>> >
>>>>> >>
>>>>> >>
>>>>> >> On Tuesday, 2 September 2014 19:12:01 UTC+1, Stefan Karpinski wrote:
>>>>> >>>
>>>>> >>> Are slices in Julia any worse than in Matlab? If so, what does
>>>>> Matlab do
>>>>> >>> that's better? I agree that our current slicing needs improvements
>>>>> (they
>>>>> >>> are planned), but it is largely due to its Matlab heritage.
>>>>> >>>
>>>>> >>
>>>>> >> I did not mean to apply that Julia is worse in this respect. Off
>>>>> the cuff,
>>>>> >> I would say slicing is no better or worse than in matlab. And, for
>>>>> the
>>>>> >> record, slicing multi-dimensional arrays in Matlab has been driving
>>>>> me mad
>>>>> >> for some quite some time.
>>>>> >>
>>>>> >> I've skimmed the discussions in the "issues" lists on github, and I
>>>>> very
>>>>> >> much liked the idea of distinguishing
>>>>> >> a[i:i, :, :]
>>>>> >> from
>>>>> >> a[i, :, :]
>>>>> >> until I remembered that I want
>>>>> >> a[i,:]
>>>>> >> to be a row-vector. But I can't have the cake and eat it too.
>>>>> >>
>>>>> >> Is there a consensus yet what the final slicing behaviour will be?
>>>>> >>
>>>>> >> --Christoph
>>>>> >>
>>>>> >>
>>>>> --
>>>>> -- Those who don't understand recursion are doomed to repeat it
>>>>>
>>>>>
>>>>
>>
>
