I think we should move to having scalar+scalar, scalar+array and
array+array promotions behave the same. We started out having scalar*scalar
operations promote quite liberally. For example, Int8+Int8 promoted to Int
rather than giving an Int8 result even though both arguments are of that
type, based on the reasoning that we could give a correct value more often
that way, and the promotion is generally free or cheap on modern CPUs. And
IIRC, way back in the day Array{Int8}.+Array{Int8} followed this behavior.
But of course, that's bad for large arrays since the result is then 8x
larger than either of the arguments. So now we've moved to letting the
desirable behavior for *array* dictate the behavior for scalars instead of
the other way around; it's not immediately obvious that it should go in
this direction, but for a language where arrays are so important, I think
it's the right way to go. The old scalar behavior was also annoying when
trying to write type-stable code for scalars. To that end, I would be
interested in a PR making all scalar+scalar, scalar+array and array+array
ops behave the same in terms of element types.
On Thu, Dec 3, 2015 at 11:36 AM, Stephan Buchert <stephanb...@gmail.com>
wrote:
> Yes, certainly one can argue here back and forth:
>
> julia> Int32[5730]*86400e3
> 1-element Array{Float64,1}:
> 4.95072e11
>
> julia> Int32[5730]*86400f3
> 1-element Array{Float32,1}:
> 4.95072e11
>
> i.e. promotion also here the same as for scalar*scalar. My data are from
> hardware sensors or counters, which deliver 8, 16 or 32 bit, memory
> consumption in the computer is normally not an issue.
>
> What's wrong with these solutions?
>> julia> Array{Int64}(Int32[5730])
>> 1-element Array{Int64,1}:
>> 5730
>>
>> julia> convert(Array{Int64}, Int32[5730])
>> 1-element Array{Int64,1}:
>> 5730
>>
>> julia> map(Int64, Int32[5730])
>> 1-element Array{Int64,1}:
>> 5730
>
>
> Good comprehensive set of solutions, thanks. Still,
>
> julia> Int32[5730]*1
>
> would be shorter and nevertheless easily readable, according to my taste.
>
> Regards,
> Stephan
>
