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] 
> <javascript:>> 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