Broadcasted rand.(::Int64), similar to rand(::Int64), but errs with .<

[ThoAppelsin]

Julia Version: 1.1.0

rand(10) returns a 10-element Array{Float64, 1}.
rand.(10) returns the same thing, but of course with different numbers.

rand(10) .< 0.3 works, returning a 10-element BitArray{1}.
rand.(10) .< 0.3 screams:

julia> rand.(10) .< 0.3
ERROR: MethodError: no method matching isless(::Array{Float64,1}, ::Float64)
Closest candidates are:
  isless(::Float64, ::Float64) at float.jl:459
  isless(::Missing, ::Any) at missing.jl:70
  isless(::AbstractFloat, ::AbstractFloat) at operators.jl:148
  ...
Stacktrace:
 [1] <(::Array{Float64,1}, ::Float64) at .\operators.jl:260
 [2] _broadcast_getindex at .\broadcast.jl:578 [inlined]
 [3] getindex at .\broadcast.jl:511 [inlined]
 [4] copy at .\broadcast.jl:763 [inlined]
 [5] materialize(::Base.Broadcast.Broadcasted{Base.Broadcast.DefaultArrayStyle{0},Nothing,typeof(<),Tuple{Base.Broadcast.Broadcasted{Base.Broadcast.DefaultArrayStyle{0},Nothing,typeof(rand),Tuple{Int64}},Float64}}) at .\broadcast.jl:753
 [6] top-level scope at none:0

It doesn't seem right.

I encountered the issue on a more complex line, where I had been using @. at the beginning for convenience. It also does not work like that either.

[KristofferC]

Why doesn't it seem right? The broadcast is over scalars so this would be equivalent of writing rand(10) < 0.3 which errors in the same way.

[ThoAppelsin]

My reason to find this weird is already in the description, at the first paragraph, not counting the version info.

If you are telling me that you have never meant it to be not-weird in such ways, then fine. But really and I would say, logically, under the premise of the first two expressions yielding the same result, and the third one running without an error; the fourth one also running similarly without an error, should have been implied. Were you asking for a "why" on that, perhaps? Then:

The first two expressions yield the same result. Their apparent equivalence should allow me to replace one another. The third expression runs without an error and produces a result.

A part of that third expression is one of the two aforementioned apparently-equivalent expressions. However, replacement of that part with the other raises an error and does not give a result, let alone similar. A premise, then, should have been wrong, and I guess that is the first two expressions being apprently-equivalent. This was not apparent, hence, weird.

[KristofferC]

The first two expressions yield the same result. Their apparent equivalence should allow me to replace one another. The third expression runs without an error and produces a result.

You might miss the "fusing" part of the dot notation. For example

a .+ b .+ c

is not equivalent to

tmp = a .+ b
tmp .+ c

because all consecutive dot calls are fused into one "kernel".

Here you are broadcasting over something that yields a vector and something that gives a scalar and you cannot compare those.

Closing since this is not a bug.

[ThoAppelsin]

The issue is present, regardless of whether I was missing the fusing part. The first time I have encountered it, I indeed was overlooking the fusing aspects; and then after experimenting with it, I then realized its existence.

Even then, I still am finding this weird. Before it was surprisingly weird, and now it is clearly weird. I have explained you in as much detail as I can, why I find it weird. Don't you @KristofferC also find it weird?

Not all issues are bugs, so I find it also weird that you close this for not being a bug. Sure, I agree, this might be a side-effect of whatever is intended. Moreover, it might even be working perfectly fine according to what the designers initially had in mind.

Now, I present you this example of weirdness, with which I expect everybody familiar with some basic math and logic to agree. If the designers already had thought of this before, and had let it be, then also fine, keep it closed as a duplicate.

Otherwise, I expect it to remain open for a little longer with the broadcast and design tags maybe. After enough discussion, it may then be closed after a fix, or with a wontfix tag.

[jgoldfar]

As a Julia user (as opposed to a core developer) I would still agree with the above point, that this behavior isn’t surprising or weird when you consider what broadcasting is as an operation. It’s not simply about using scalar operations with vectors (which is well defined in some cases without broadcasting) but instead allowing a mix of vector and scalar operations in a way that has to be sensible as well. I much prefer an error to ambiguity in my algorithms. Just my 2c
PS I have also observed that these kinds of discussions are much better had in slack or discourse, rather than keeping the issue open as suggested

[yuyichao]

The first two expressions yield the same result. Their apparent equivalence should allow me to replace one another. The third expression runs without an error and produces a result.

This is only a property for an expression that uses the result as a whole. Broadcast fusion isn't so you should not expect such a property to hold. The fusing semantics necessarily implies this so there's nothing left to be discussed, unless you are arguing the fusing should be completely removed since any fusion will cause the "subexpression" result to not be used in the evaluation of the whole expression. After all, the "subexpression" isn't even part of the whole expression in this case.

Note that this is nothing unique to broadcast fusion. It's simply a effect of context dependent parsing. A few examples,

julia> a = 1 + 2; a * 3
9

julia> 1 + 2 * 3
7

julia> a = @show 1; a, 2
1 = 1
(1, 2)

julia> @show 1, 2
(1, 2) = (1, 2)
(1, 2)

In the two cases above, even though 1 + 2 and @show 1 might seem like expressions that could be evaluated on it's own, that is not how it's evaluated. The broadcast fusion case is probably less familiar to you and it happens in lowering rather than parsing but there's nothing fundamentally different between them.

Edit: And I agree it is a little wierd, but I do want to point out that you have taken similar cases for granted and this is not something that can be fixed without throwing the useful function out completely. For exactly this reason, introducing such features should be done with extreme care and it's definitely a breaking change. The fusion breaks the property you mentioned for expression splicing so it is indeed worse from the meta programming perspective and it is indeed unfortunate. However, the feature is determined to be useful enough and the corner case where this can happen is easy enough to catch (must be using broadcast syntax in the expression that is being spliced in) so we should have it.

[ThoAppelsin]

julia> (1 + 2) * 3
9

julia> (@show 1), 2
1 = 1
(1, 2)

julia> (rand.(10)) .< 0.3
ERROR: MethodError: no method matching isless(::Array{Float64,1}, ::Float64)
Closest candidates are:
  isless(::Float64, ::Float64) at float.jl:459
  # and so on...

@yuyichao At least we agree that it is (at least) a little weird, and also hopefully that it is (at least) a little more weird than the examples you've given. Indeed, I had tried using such superfluous parenthesis when I had first encountered the issue, before having realized the underlying cause.

[...] and this is not something that can be fixed without throwing the useful function out completely. [...]

At this stage, I can only guess what can be done to fix this issue, without inflicting any damage to what already can be done. I will not have the time to check and learn what is going on underneath, so I will just believe you when you say it cannot be fixed, for now and with a slight doubt.

[yuyichao]

The fact that parenthesis affect the result is not fundamental, it's simply a syntax affect parsing that doesn't apply to broadcast fusion. If you want the same effect, you can always assign to an variable. That, not adding parenthesis, is the more general syntax level transformation you are looking for and that should always work short of some special syntax that doesn't follow local evaluation rules at all (ccall).

Parenthesis is only the tool for the class of issues you are familiar with enough to not even think of it as context dependency normally. We don't have a corresponding syntax (it's not Ref) for the fusion syntax. I doubt we need one since the general solution of assigning to a variable already works.

hopefully that it is (at least) a little more weird than the examples you've given

Only because the rules are less farmiliar, since you are not doing metaprogramming. So I agree in the sense that this is something that's fairly unique to julia so people need to learn it and get familiar with it but I believe for people that haven't seen either, there shouldn't be any more strange. (Granted it's hard to find someone that have not learnt operator procedence but the parenthesisless macrocall and generator/comprehension syntax indeed causes similar confusions from time to time.)

In the end, the invariance you expect is not one that should hold at syntax level.