Zeros, ones, array construction redesign


#1

First off, I’d like to say I think that I love the detailed approach that @sacha has taken, laying out different goals, different proposals, and the pros/cons for the different possibilities.

I was surprised that it was decided to keep ones and zeros, though, just for creating Float64 arrays though, since it’s only 2 characters difference between fill(0.,d) zeros(d), and 3 for fill(1.,d) & ones(d).
When I first came to Julia, I was surprised that the default for zeros and ones was Float64 (not coming from any language that had ones or zeros), and it seems that fill is both more consistent and easier to understand for new people coming to Julia, since the type of the elements is explicit (and then one can easily generalize to things like fill(0,d) or fill(d128"1",d))
Another advantage, is that whereas the type is hidden with ones and zeros, only using fill would make it easier for things like the very nice new ChangePrecision package to find and modify those literals (currently, ones, zeros, and eye have to be special cased)

If the reason for keeping those functions is simply for Matlab compatibility, couldn’t those simply be added to a Matlab compatibility package? Julia is so much better than Matlab or R, it would be sad to see any of the warts of those languages carried over for all time into Julia, IMO.


#2

But this violates the style guidelines, so really, it’s

zeros(d)
fill(0.0, d)
ones(d)
fill(1.0, d)

And more generally,

zeros(T, d)
fill(zero(T), d)

By the way, could you point me to where the discussions on array construction is taking place? I’m a bit curious.


#3

https://github.com/JuliaLang/julia/issues/24595 (https://github.com/JuliaLang/julia/issues/24444 and https://github.com/JuliaLang/julia/issues/11557 are also relevant)


#4

@ScottPJones, thanks for the kind words!

@DNF, please see #24595 for detailed analysis of the associated issues. That analysis includes — as a small point dwarfed by greater considerations — a more thorough analysis of the relative length of ones/zeros and fill. (In short, the length differential goes both ways in practice and is usually marginal in any case.)

Best!


#5

Actually, I wasn’t really concerned about whether it was 2, 3, or 4 characters extra in those cases, it seems to me a small price to pay to have the base language have one consistent and generic method, instead of a couple Matlab legacy names (which I don’t want eliminated, just moved, along with some other Matlab functions that don’t have a good Julian name, such as cumsum/cumprod, to a Matlab compatibility package, so the only change for people who want those names would be to add using Matlab or some such, to their code).


GitHub Discussions and JuliaLang teams
#6

I would like to add something (tiny) to the discussion fill vs zeros if that’s ok.
It would bother me (slightly) to use fill(0.0, d) to initialize an array of zeros as I find the name fill suboptimal for that purpose. It describes an action rather than an object and the usecase for zeros is initializing an object, namely an array. I can totally see why we have fill!(A, x) because it does what it says: it fills an existing array with something. But A = fill(0.0, d) seems a bit odd from a users perspective, because it doesn’t really fill anything that has existed before. zeros was different in this regard because it does what it says: it creates a new array of zeros for you. In this spirit, maybe it should rather be A = filled(0.0, d) or similar.

Also, for sparse matrices we will still have spzeros (fill doesn’t make too much sense here I guess) and there would be an inconsistency to be able to do A = spzeros(d) but not A = zeros(d).

(Other example: diagm. It describes an object, not an action.)

I hope you get my (probably unimportant) point and apologies if this is not the right place to comment on this or if this has already been discussed somewhere else (there are quite a number of threads on this or similar issues).