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.

[StefanKarpinski]

Another solution to this problem would be to have conversion of floats to integers do rounding instead of truncation. I know it's not what C does, but it's hard to argue that it's not a better conversion. I've seen quite a few PHP programmers (and other floating point unsavvy types) get really confused by these, deciding that it's actually a PHP bug.

[JeffBezanson]

The main problem I can think of with rounding is that it's slower.

The other problem is that we'd have to loop over index arguments and explicitly convert the endpoints of any ranges. This would have to be done in all ref and assign methods that might take ranges. Only other solution is to change the behavior of 1:2.5, or change the behavior of /.

[StefanKarpinski]

True, rounding is slower. However, it's much more frequently the right conversion — we could head off a lot of future bugs by making it the default conversion for integers from non-integer reals. This especially applies to relatively inexperienced programmers. One could, of course, still use itrunc or div for better performance — which more experienced programmers are likely to know to do. This is actually a completely separate issue from what to do with indexes and ranges. I think we should probably make rounding the default conversion regardless of what we do with indexes and ranges.

[JeffBezanson]

OK, I could go along with that. It also makes it easy to justify having / do rounding division.

I found long(x+0.5) is 5x faster than iround. Too bad rounding towards +Inf is probably not what people want.

[StefanKarpinski]

I think that having / do rounding division is a bad idea — Python made that decision initially and regretted it until 3.0 which make / produce a float, massively breaking backwards compatibility in exchange for much more intuitive behavior. I would much rather make people call the conversion function for indices and ranges than have / do rounding division.