>
> I actually think the plan of [a,b,c] for construction without
> concatenation and [a;b;c] and [a b c] for concatenation is pretty good
I think this should read:
[a,b,c] for construction without concatenation and [a;b;c] and [a b c]
for *construction
*with concatenation.
I mean what you really do here is, in one case you create Array{eltype} and
in the other Array{type}.
Which is both a construction of an array, and the different result is
encoded by some, for me, arbitrary mixture of signs, which rather encode
the shape of the array and not the resulting element type.
The thing that clicked for me is that [a;] isn't really concatenation at
> all anyway
Can you explain this better? I mean I just deduced, that ; results in
concatenation, and [a;] is the current 0.4 syntax for [a...] (which seems
to go under the synonym of concatenation), right?
I'm sorry for my redundant argumentation, I just can't help myself ;)
2015-02-26 0:46 GMT+01:00 Simon Danisch <[email protected]>:
> Yeah it's not I suppose...
> But it sort of mixes concatenating syntax with construction syntax and
> gives you completely different syntax for basically the same process.
> I try to explain, as I can imagine, that people who are more used to this,
> don't really see my point.
> Case 1
> a = SomeType(...)
> [a,a,a] => Vector{SomeType}
> [a;a;a] => Vector{SomeType}
> [a a; a a] => Matrix{SomeType}
> # Okay, obviously these operations construct matrices from arrays, by
> concatenating elements into a list.
> Case 2
> a = Vector{T, 1}(...)
> [a,a,a] => Vector{Vector{T}} # which it doesn't in the current build,
> adding to my confusion
> [a;a;a] => Vector{T}
> [a a; a a] => Matrix{T}
> Whaaat? So without knowing anything about this, I would conclude:
> ',' -> concatenates items into a list
> ';' or ' ' -> concatenating + flattening, as it removes the arrays and
> results in flat array namely Array{eltype(a)}
> So what do I expect from your case?
> [[a,a,a]' ; [a,a,a]']
> b = [a,a,a]' => some array, which looks comparable to Case 2
> [b ; b] -> independent of b's shape, this should result in
> Array{eltype(b)} and not Array{typeof(b)}, from what I learned in Case 2.
> Otherwise this is quite confusing, as concatenating would also depend on
> the shape, which makes it hard to predict, when something concatenates or
> just constructs.
> ...At least for me.
> I really think this is a mix of two concepts, without having a clear and
> obvious differentiation.
> Also it's always nice, if you can use the same pattern for similar things.
> Constructing a matrix with and without concatenating is very similar, but
> with your suggestion(Josh Langsfeld), it'd would be a very different
> process and nothing learned from either case can be transferred to the
> other.
> While this uses the same, transferable construction concept, with the only
> difference being the (now guaranteed) result:
> [| a a; a a|] => Array{T} && T == eltype(a) # note: eltype(Number) ==
> Number
> [a a; a a] => Array{T} && T == typeof(a)
>
> 2015-02-26 0:10 GMT+01:00 Josh Langsfeld <[email protected]>:
>
>> Assuming transposing works, you could do [[a,a,a]' ; [a,a,a]'] which
>> isn't entirely horrible
>>
>> On Wednesday, February 25, 2015 at 5:50:04 PM UTC-5, Simon Danisch wrote:
>>>
>>> Okay... So how do I realize:
>>> a = vec3(...)
>>> [ a a a ; a a a]
>>>
>>> Well, all I think is, that arrays of arrays get treated like second
>>> class citizens, as it is harder to work with them in the same way, as it
>>> would be possible with concatenating ;)
>>> This is especially relevant with FixedSizeArrays coming up, as they
>>> allow for tightly packed array of arrays.
>>> What I mean becomes obvious, if you look at the number of constructors:
>>> [a,b,c] for non concatenating
>>> vs
>>> [a;b;c;], [a b c], [a b c; a b c] (+ some variations) for concatenation
>>>
>>>
>>> 2015-02-25 23:24 GMT+01:00 Jeff Bezanson <[email protected]>:
>>>
>>>> Transposing [vec1, vec2, vec3] will absolutely work. I think the issue
>>>> you saw with it was specific to ImmutableArrays. I don't know why they
>>>> have that behavior.
>>>>
>>>> On Wed, Feb 25, 2015 at 5:21 PM, Simon Danisch <[email protected]>
>>>> wrote:
>>>> > I mean, my whole busyness is about constructing matrices of Vec2/3/4,
>>>> which
>>>> > inherit from DenseArray.
>>>> > So I'm basically forced, if I'm not missing something, to do quite a
>>>> bit of
>>>> > work to get my [vec1 vec2 vec3] going.
>>>> > Especially, as transpose([vec1, vec2, vec3]) doesn't seem to work,
>>>> bug or
>>>> > not isn't known to me.
>>>> >
>>>> > 2015-02-25 23:18 GMT+01:00 Simon Danisch <[email protected]>:
>>>> >>
>>>> >> Well, the issue raised here was, how do you realize non concatening
>>>> [a b
>>>> >> c]? This seems impossible now, even though that there are quite a
>>>> few use
>>>> >> cases for it...
>>>> >>
>>>> >> 2015-02-25 23:13 GMT+01:00 Stefan Karpinski <[email protected]>:
>>>> >>>
>>>> >>> I actually think the plan of [a,b,c] for construction without
>>>> >>> concatenation and [a;b;c] and [a b c] for concatenation is pretty
>>>> good. I no
>>>> >>> longer feel that there's any need for a new bracket like [| |]. The
>>>> thing
>>>> >>> that clicked for me is that [a;] isn't really concatenation at all
>>>> anyway.
>>>> >>>
>>>> >>> On Wed, Feb 25, 2015 at 4:58 PM, Simon Danisch <[email protected]>
>>>>
>>>> >>> wrote:
>>>> >>>>
>>>> >>>> As Julia was the first language to introduce me to this kind of
>>>> >>>> constructs, I'm not sure about your used terms.
>>>> >>>> Concatenate for me would firstly mean, to just connect elements
>>>> (that's
>>>> >>>> at least what the German translation suggests), which I would
>>>> apply to the
>>>> >>>> process of putting the elements together into one array. The
>>>> elements in my
>>>> >>>> case are the Vectors.
>>>> >>>> You seem to use it as synonymous with concatenation + flattening
>>>> >>>> (sticking to the function names I guess).
>>>> >>>> I'd say [a,b] is supposed to concatenate, but shouldn't flatten,
>>>> right?
>>>> >>>> So yes, different syntax for concatenating, and
>>>> concatenating+flattening
>>>> >>>> would make this case much, much clearer.
>>>> >>>> Then it's not this fuzzy magic thing, that sometimes happens and
>>>> >>>> sometimes not and both clearly encapsulates a concept and use the
>>>> same basic
>>>> >>>> syntax.
>>>> >>>> So:
>>>> >>>> [vec, vec] => [vec, vec] # With optional typing, ensuring that you
>>>> don't
>>>> >>>> end up with Any[]
>>>> >>>> [vec vec] => [vec vec] # With optional typing, ensuring that you
>>>> don't
>>>> >>>> end up with Any[]
>>>> >>>>
>>>> >>>> [| vec, vec |] => [el1, el2, el3, el4, ...]# With optional typing,
>>>> >>>> ensuring that you don't end up with Any[]
>>>> >>>> [| vec vec |] => [el el2 ; el3 el4]# With optional typing,
>>>> ensuring
>>>> >>>> that you don't end up with Any[]
>>>> >>>>
>>>> >>>> I do think, that this is very clear and consistent and doesn't
>>>> leave
>>>> >>>> anything in doubt!
>>>> >>>>
>>>> >>>>
>>>> >>>> Am Mittwoch, 25. Februar 2015 19:00:01 UTC+1 schrieb Simon Danisch:
>>>> >>>>>
>>>> >>>>> Hi there,
>>>> >>>>> I thought default concatenation was deprecated, to make it easier
>>>> to
>>>> >>>>> create arrays of arrays... But it became rather impossible and
>>>> confusing in
>>>> >>>>> the horizontal case, from what I see.
>>>> >>>>> Is there really not a single method left from the few ways in
>>>> 0.35 of
>>>> >>>>> creating a horizontal vector of vectors?
>>>> >>>>> 0.4:
>>>> >>>>>
>>>> >>>>> https://gist.github.com/SimonDanisch/6972c1c090c608738e83#file-
>>>> cat0-4-jl
>>>> >>>>> 0.3.5:
>>>> >>>>>
>>>> >>>>> https://gist.github.com/SimonDanisch/058ef76b2583c620b667#file-
>>>> cat3-5-jl
>>>> >>>>>
>>>> >>>>> Am I missing something, or is this a bug?!
>>>> >>>>>
>>>> >>>>> Best,
>>>> >>>>> Simon
>>>> >>>
>>>> >>>
>>>> >>
>>>> >
>>>>
>>>
>>>
>
