zeros(1e4) -> ERROR: no method Array(DataType,Float64)

[Staross]

I find this a bit annoying, because I'm used to use the exponent notation to declare large numbers. Of course I could do zeros(10^4) but I think it should also work with 1e4.

The problem is that 1e4 is a float and 10^4 an int, and that Array doesn't accept floats for dimensional arguments.

Is there any problems with trying to convert floats to int when declaring arrays ? I think it would simplify things quite a bit, and it seems safe to me, since convert will give an InexactError when trying to declare an array with 10.5 elements.

It would also solve this kind of weird behavior:

julia> zeros(100/10)
ERROR: no method Array(DataType,Float64)
 in zeros at array.jl:205

[JeffBezanson]

This has come up a few times.

These functions in general accept Int.... It is too inefficient to loop over all the arguments converting any floats to ints. There are also lots of functions like this and I don't want to be too arbitrary about where floats are supported.

I think the most I can offer is maybe allowing floats as the first 2 arguments, so there aren't n^m possible calls.

[StefanKarpinski]

What's the performance hit of having a fallback method that converts all dimensions to Int? Is this really such a performance issue?

[nlhepler]

Any integer raised to a non-negative integer power is also an integer. Is it possible, or desirable, to special case such constant, non-overflowing exponent notation to provide an Integer?

[JeffBezanson]

We can't have a situation where every function starts with:

function f(x, dims::Real...)
    dims = convert((Int...), dims)   # or map(int, dims), etc.
    ...
end

because that will kill almost every optimization in the book. We will also decline to generate code for all n^m possible signatures. If I add some custom code generation for tuple conversion, and we merge Keno's tuple optimization branch, then the performance could probably be ok but we'd still have potential exponential blowup. In any case the performance can't be as good as it could be, since there is no way to leave the arguments in place --- e.g. if one is a Float32, then it has to be moved to convert to Int64 even if you are very clever.

I also find it a pain to go through every function that takes integers and consider whether it should take floats too, and if so when and how it should convert them. And library writers will want to follow suit, which adds extra worry about the many very slow ways one can imagine to implement this. Even without any performance problems, it's a nuisance to remember to add this feature to every function that takes sizes.

Should the Dims type be (Real...)? That would probably cost us a fair amount of type precision. Putting f(d::Int...) in the library allows users to write f({crazy...}...) without serious performance problems, and gives us the opportunity to optimize the code even more than we do already.

[StefanKarpinski]

You can express it like this instead:

zeros(T::Type, dims::(Int...)) = #core definition
zeros(T::Type, dims::Int...) = zeros(T, dims)
zeros(T::Type, dims::Real...) = zeros(T, convert((Int...), dims)

Other than the code generation bloat, this doesn't seem all that bad to me. We do already have heuristics that stop specialization – isn't this just another case to figure out that we shouldn't specialize?

[StefanKarpinski]

I'm not entirely against the idea of making 1e10 be an Int either.

[JeffBezanson]

I'm ok with a limited version of this where just a couple functions like zeros have those definitions for convenience. But consistency becomes a problem --- how come some functions allow floats and others don't? And if we allow it everywhere, it really is a large number of definitions.

[Staross]

There are other expressions, like 100/10 or floor(3*log(N)) that generate floats in addition to 1e4. Having a float interface could potentially save a lot of problems and conversions to the users.

I understand that there's a serious consistency problem, having just a few function that accept floats is a bit weird. zeros and ones are a bit special though, as they are used so much.

On the other hand it's maybe better to force as soon as possible new user to thinks about the types of their variables.

[StefanKarpinski]

Arguably expressions like 100/10 or floor(3*log(N)) should be expressed differently – div(100,10) and ifloor(3*log(N)).

[andrioni]

My two cents: 1e4 for me is always a floating point number, but that may be my C origins leaking.

(and for me, using doubles all the time instead of integers is one Matlab's faults, and I'd prefer to avoid it in Julia, but I do recognize that it can be convenient)

[stevengj]

Duplicate of #2293 and #1972.

[nalimilan]

(Continuing the discussion here instead of in #2293 as the interesting comments are here.) This has been raised again on the mailing list. It seems to me that Array constructors can be made to accept Real without any performance penalty for the Int case, just like @StefanKarpinski highlighted above (#4275 (comment)). I've made a very simple PR for that: #9776

@JeffBezanson Any chance you change your mind about this? Most of the time, when a function needs to accept all Integers, not only Int, the definitions are already present (e.g. for Array()). This merely requires relaxing the signature.