ones should call oneunit

[mdavezac]

According to docstring, ones creates an array of T, hence it should call oneunit rather than one. See #16116 and #20268.

This PR requests makes the following call successful:

using Unitful
ones(typeof(1u"m"), 2)

Another option would be to add oneunits to Base?

[stevengj]

Instead of defining your own type here, just use the Furlong type from tests/dimensionful.jl, which is there precisely to add tests for dimension bugs.

fix test

[mdavezac]

Thanks for the pointer to Furlong. The tests are now fixed.

[StefanKarpinski]

I'm not entirely sure about this. What's the algebraic / logical motivation for ones being unitful?

[TotalVerb]

Is there any benefit to having ones(T, x, y) at all, instead of fill(one(T), x, y)?

Conducting a quick search reveals that most uses of ones should really be using fill to avoid intermediate allocations...

[mdavezac]

To meones, zeros, similar, rand are all helper functions to get an array quickly. So, having ones behaved differently w.r.t type seems weird. From an algebraic point of view, for a vectorial space E over a field F, I would expect ones to return an element of E (as defined by the type T), not something composed of elements of F and creating an alternate vectorial space E' of it's own choosing. From F, I expect only scalars (for E), as given by one.

Obviously, there is scope for confusion between one and ones :(, so on that front, it might be better to have ones and oneunits. Or just oneunits, in a ground-zero world.

[TotalVerb]

I'm suspicious of the oneunits(...) behavior because the oneunit is not algebraically meaningful. The matrix of ones is potentially meaningful as the identity for the Hadamard product, and in some other cases. What use case is there for a matrix of one units?

[mdavezac]

In practice, creating a multidimensional array with units is useful in Physics for any number of cases.
So I would be inclined to have ones(Furlong{1, Int64}, 2, 3) give me a matrix of Furlongs.
However, if in other domains the expectation is that ones(Furlong{1, Int64}, 1, 2, 3) returns an array of Int64, then I'm happy to modify this PR that way.

Currently, it fails because we are creating an array of one type and filling it with another:

 julia> ones(Furlong{1, Int64}, 2, 3, 4)
ERROR: MethodError: Cannot `convert` an object of type Int64 to an object of type Furlong{1,Int64}
This may have arisen from a call to the constructor Furlong{1,Int64}(...),
since type constructors fall back to convert methods.
Stacktrace:
 [1] fill!(::Array{Furlong{1,Int64},3}, ::Int64) at ./multidimensional.jl:788
 [2] ones(::Type{T} where T, ::Int64, ::Int64, ::Int64, ::Vararg{Int64,N} where N) at ./array.jl:265

[TotalVerb]

Could you give a specific case you have in mind?

[mdavezac]

It could be a constant potential, for instance.

[TotalVerb]

What advantage is there over fill(1V, dims...) which seems shorter and more flexible, then?

[mdavezac]

Fair enough. But then why not just deprecate ones and zeros?

[TotalVerb]

zeros might reasonably have a faster implementation than fill, by calling for example calloc. For almost all types oneunitswould have to overwrite memory anyway, so I don't think it's that useful as a separate function.

[mdavezac]

Looks to me like the conclusion is this PR is not needed, and that ones should only be used for unitless quantities, if at all. Thanks for the review and comments.