If we introduced Covectors and a row slice of a Matrix was a Covector, then
this wouldn't be an issue anymore since we could simply allow sorting both
Vectors and Covectors but not Matrices. There's still the open question of
what taking a slice that looks like T[1,:,1] should produce. That's a
one-dimensional slice, but is it a Vector or a Covector?


On Mon, Jul 21, 2014 at 8:53 AM, Leah Hanson <[email protected]> wrote:

> I hadn't seen that issue; thanks for the link. I'm glad there's a
> discussion going on about that. :)
>
> -- Leah
>
>
> On Mon, Jul 21, 2014 at 10:43 AM, Ivar Nesje <[email protected]> wrote:
>
>> Warning for 2d row vectors used in context where only a 1d column vector
>> is used could definelty be implemented as help when you get a MethodError.
>>
>> See also https://github.com/JuliaLang/julia/issues/7512.
>>
>> Ivar
>>
>> kl. 16:03:46 UTC+2 mandag 21. juli 2014 skrev Leah Hanson følgende:
>>>
>>> I agree that the `["a" "b" "c"]` vs `["a", "b", "c"]` syntax is
>>> something likely to catch new-to-Julia users. I have personally watched
>>> people struggle with that. Programmers familiar with other languages take a
>>> bit to understand the vectors vs row-matrixes thing, when they were just
>>> expecting a list/array type. While you can read `Array{ASCIIString, 2}` in
>>> the REPL response to `["a" "b" "c"]` (and in the `sort` error message), you
>>> have to know that matrixes/row-matrixes exist in Julia and that we've
>>> chosen not to interpret a row-matrix as a list.
>>>
>>> I'm not in favor of make `sort` work for row-matrixes. This distinction
>>> is an important one to learn as a Julia programmer and you will continue to
>>> encounter it. However, maybe our error messages could be a lot better. The
>>> most magical version would be to say something like:
>>>
>>> ~~~
>>> julia> sort(lst)
>>>
>>> sort(lst)
>>>      ~~~
>>> `lst` is an Array{ASCIIString, 2}, which `sort` has no method for.
>>> Did you mean to define `lst` as `lst = ["a", "b", "c"]`?
>>> ~~~
>>>
>>> This is most appropriate in a "I just used a row-matrix literal."
>>> context, but for any (short) row-matrix, it could be helpful. I use C++ at
>>> work, and this is what many of my error messages look like: the line (with
>>> line number/file), with the problem underlined/highlighted, a brief
>>> description of the problem, and (often) a suggestion of what I may have
>>> meant. The suggests are literally copy-paste-able code, not a prose
>>> description.
>>>
>>> I find these to be very useful, especially as a less experienced C++
>>> user. The suggestions appear for things like "->" vs "." (when you've got
>>> the wrong one), when you've mistyped a variable name (there's a variable of
>>> the proper type in-scope, and you used a non-existant/other-type variable),
>>> when you forgot to namespace a variable/function (you used `vector` but
>>> have to use `std::vector`).
>>>
>>> These error messages do a great job of "I'm not going to except your
>>> incorrect input, but I do have a solid guess about what you meant, so I'll
>>> tell you the answer.". They are probably my favorite thing about using C++,
>>> and I think they are the most friendly thing you can do for new users.
>>>
>>> -- Leah
>>>
>>>
>>>
>>> On Mon, Jul 21, 2014 at 6:01 AM, Ivar Nesje <[email protected]> wrote:
>>>
>>>> 1. It clearly isn't.
>>>>
>>>> 2. It will not cause any overhead in the common case (because it would
>>>> be a separate method in Julia). The question is whether this is a case
>>>> where we should guess what the user intended, or force the user to fix a
>>>> potential problem.
>>>>
>>>> Not sure what we could do about this though, because the distinction is
>>>> useful and it becomes much more annoying if you discover such subtle
>>>> differences later rather than earlier.
>>>>
>>>> Ivar
>>>>
>>>> kl. 04:19:53 UTC+2 mandag 21. juli 2014 skrev Abe Schneider følgende:
>>>>
>>>>> It wasn't obvious to me initially why `sort` wasn't working for me
>>>>> (strings and composite types). On further investigation it looks like that
>>>>> it only works for single-dimension arrays -- which makes sense. However, 
>>>>> if
>>>>> I type:
>>>>>
>>>>> lst = ["a" "b" "c"]
>>>>> sort(lst)
>>>>>
>>>>> I get an error. The answer is that it's of type `Array{ASCIIString,
>>>>> 2}`, whereas `sort` wants the type to be `Array{ASCIIString, 1}`. The
>>>>> correct solution is to write this instead:
>>>>>
>>>>> lst = ["a", "b", "c"]
>>>>> sort(lst)
>>>>>
>>>>> The problem seems to derive from two design decisions:
>>>>>
>>>>>    1. It is not obvious to someone new to Julia why one form gives a
>>>>>    two dimensional array whereas the other gives a one dimensional array.
>>>>>    2. `sort` doesn't try to determine if the array passed is actually
>>>>>    jeust one dimensional.
>>>>>
>>>>> I'm not sure there is a simple solution. I assume there's a good
>>>>> reason for (1) and (2) involves some overhead which might be undesirable.
>>>>>
>>>>
>>>
>

Reply via email to