Pass integer valued floats to matrix constructors

[ViralBShah]

Currently, all matrix constructors only accept integer valued inputs. It should be possible, for example, to do the following:

julia> ones(1e3,1e3)

[stevengj]

I ran into this myself, recently....wanted to generate x = rand(1e7) for some benchmarking, and it was really annoying (and hard to read) to have to type x = rand(10000000) (hard to tell at a glance how many zeros there are).

[carlobaldassi]

@stevengj : you can use 10^7, or 10_000_000.

Also, 1e3 is only slightly shorter/easier then 10^3, so do we really need this?

[StefanKarpinski]

There's no reason we can't support this. Just call convert(Int,idx) on the index values and the right things happen.

[JeffBezanson]

I hesitate on this one. We use Int or Integer for dimensions in a very large number of places, and changing most of them and figuring out where to insert conversions is a big chore.

It is also not ideal for our compiler, since it means pushing extra argument polymorphism a couple layers deeper into the library. Example: currently user code can only pass (10,10), but under this change it could pass (10.0,10), (10,10.0), or (10.0,10.0) as well. There would be extra type analysis for each of these signatures, over a couple API layers (e.g. eye->zeros->Array), instead of cutting off the extra diversity at the root.

This also makes it harder to write library functions. Every function accepting a size will have to accept (Real...), which means it has to deal with the possibility of fractional sizes. Imagine a function that checks for a rectangular matrix case with if m > n. If m and n are 5.1 and 5.0, this test will incorrectly pass. You will probably get an inexact error soon after, but it's an extra thing to worry about.

We could consider only allowing floats for a few functions like ones and zeros, but I'd rather be consistent.

[johnmyleswhite]

I'd be completely happy without this capability. As Carlo pointed out, 10^7 and 10_000_000 go a long way.

[ViralBShah]

Even though I opened this, I was hesitant to do the work.

One thought is, why not make 1e3 give an integer, and 1.0e3 give a float?

[JeffBezanson]

That's an interesting idea. One reason not to do it is that 1e3 is the shortest representation of 1000.0, and print_shortest takes advantage of that.

[ViralBShah]

The reason I like 1e3 giving an integer is that it is also consistent of our treatment of 1 itself as an integer. We may have to update some places in the code that rely on the current behaviour, but I think this might just be the right way to go.

[JeffBezanson]

e being part of floating point syntax is quite traditional. I think writing 10^n is a decent solution.

[wlbksy]

How about introduce C's style 1e3L , and we make L an exception of "juxtaposed literal coefficient syntax"