Matrix constructors should be able to take floating point value for size

[ViralBShah]

This should work:

julia> a = rand(1e6)
no method rand(Float64,)
in method_missing, boot.j:250
in run_repl, /home/stephan/julia/j/client.j:23
in _start, /home/stephan/julia/j/client.j:153

[JeffBezanson]

I'm not sure about this. This is a context that requires an integer semantically, since it is an element count. So I think code should have to explicitly convert floats, which will also remind you to think about whether you want floor or ceil.

[StefanKarpinski]

I dunno. Being forced to pass ints is pretty annoying.

[ViralBShah]

I'd go with round, rather than floor or ceil. Another possibility is only accepting values that are integers, but happen to be stored as floats.

[StefanKarpinski]

Another possibility is only accepting values that are integers, but happen to be stored as floats.

That occurred to me as well. Seems a bit iffy, but might be pragmatic.

[JeffBezanson]

I don't see why being forced to pass ints is that annoying. I don't think it's ever come up before.

[ViralBShah]

It would be nice to also allow any int to be passed. I discovered that only 64-bit ints work now (presumably because I am on a 64-bit platform). Array should allow any Int for its sizes.

[JeffBezanson]

Allowing any Int will happen.

[JeffBezanson]

I also wish we would disallow floats as indexes. Yesterday Giuseppe noticed that while A[end/2] works, A[1:end/2] doesn't because we don't have a case for float ranges. But to me allowing float indexes is just hiding bugs. C programmers will assume A[end/2] does truncation, but it actually rounds, and who remembers which way 2.5 gets rounded? This is a common source of off-by-1 errors and trying to sweep it under the rug is just unwise.

[StefanKarpinski]

Not being able to do A[end/2] is annoying. Choosing round for conversion is done for a couple of reasons:

1. It picks the right element for end/2 with an even number of elements [1,2][round(end/2)] => 1.
2. It picks the right element for end/2 with an odd number of elements: [1,2,3][round(end/2)] => 2.

It's hard to argue that any other behavior is right in either of these cases. For different end/k expressions it also does the right thing, which I'm fairly sure no other choice does. So the round is not arbitrary at all.

[JeffBezanson]

It's not that round is wrong or arbitrary; the only thing I prefer to round is giving an error.
Another concern is that we'd be generating extra code (internally) for all the indexing code for float arguments, when all that's really needed is to add a call to iround in the user code.

[StefanKarpinski]

We should call iround instead of round but I don't see how automatically inserting the iround call is worse than having the user do it.

[JeffBezanson]

Yes a[end/2] is nice, but in more obscure cases having an explicit iround call helps document that an index needed to be rounded.

Implementing ref, assign, and functions like it is also trickier since you have to be careful to round before any index computations happen. It's not always enough to rely on simpler cases of ref to handle rounding for you.

This feature creates an expectation that floats generally work everywhere, so as library code is added ::Int declarations will gradually give way to ::Real and starting functions with i = iround(i); j = iround(j) will become an idiom. There is also a danger of code generation bloat as we encounter A[Int64,Float64], A[Float64,Int64], A[Range1{Float64},Float64], A[Int64,Range1{Float64}], and all the many other combinations that become possible.

[StefanKarpinski]

Ok, well, in that case, we should get rid of all of these. Makes me wonder about automatic conversion on assignment to object fields. Seems inconsistent to allow one but not the other.

[JeffBezanson]

It is consistent. Julia has a concept of a "typed location", which includes struct and array elements, and variables with declared types. Values are converted when assigned to typed locations. Function arguments are not typed locations. If you have foo(x::Int64) you couldn't automatically convert a Float64 argument, because that wouldn't match this method in the first place. Also, conversion to integer uses truncation, not rounding.

Matlab allows float indexes because in the beginning every number was a float64. For us it seems to make sense to have things that should be integers actually be integers.

Maybe we should revisit the behavior of / on integers, though I don't have a problem with it now. One issue is that the elementwise version can't be implemented like other operators, because the return type is neither the argument type(s) nor their promotion type.

[JeffBezanson]

Just noticed something else that should have been obvious: the range 1:2.5 only visits 1 and 2, so a[1:end/2] would not automatically reach the same index as a[end/2]. Having / do rounding division would fix this without allowing float indexes in general. And FWIW, that's what matlab does.