Problem with padding in digits function

[daviddelaat]

In Julia 0.6 I get:

julia> digits(0,2,0)
0-element Array{Int64,1}

julia> digits(0,3,0)
1-element Array{Int64,1}:
 0

I think both should return a vector of length 0. This is the behavior in Julia 0.5 for all bases and in Julia 0.6 for the special cases where the base is 2, 8, 10, and 16. The source code for the digits function did not change between Julia 0.5 and 0.6, but the code for the ndigits0z function did change.

[rfourquet]

Funny, I was exactly working on fixing this one now ;-)

[mcognetta]

Maybe this has been addressed elsewhere but why should they return 0 element vectors and not 1 element vectors? "0" is the base T representation of "0" in any base (poorly worded but you get the idea) and that has length 1.

[rfourquet]

0" is the base T representation of "0" in any base

Then you are free to use digits(0, 3) without specifying a padding. When the pad is 0, an empty array is based on the idea that an empty sum is equal to 0.

[daviddelaat]

Yes, it's nice if 'digits(k, b, p)' gives a vector of length p for all '0<=k<=b^p-1'

Thank you for looking into this @rfourquet

[mcognetta]

I don't mean to be pedantic but does padding not imply superfluous zeros? See python's zfill or string formatting for an example.

>>> print("%00d" % 0,)
0
>>> print('0'.zfill(0))
0

It seems like having it return an empty array would break some cases where one would want to construct this array and then call some element from it. This seems like confusing behavior since all other cases will return a strictly non-empty array.

[rfourquet]

If it breaks some cases, then those case were relying on a bug; this is unfortunate but I don't think it's worth it now to go through deprecation just for fixing a bug. The default, when pad==1, does what you want. If digits(0, b, 0) returned a non-empty array, then there would be no way to get an empty array on input 0, which can be useful in some cases. With pad==0, a number strictly less than b^p requires at most p digits to be written in base b: take p=0. So it's sound mathematically that 0 requires no digits to be specified; of course in practice (in books, etc) we write at least one digit to distinguish 0 from nothing, so in practice with use pad==1. But in programs, pad == 0 can be useful.

[mcognetta]

(My first comment attempt isn't showing up so maybe this will be a near duplicate).

Mathematically, "emptiness/nothing" is not the same as "zero", so I really still think that all integers should return some non-empty array (but I guess I don't really have much say haha). NaN would be the only case that I think an empty array should be returned but it is a float.

About the cases of relying on a bug, from reading the documentation

Returns an array with element type T (default Int) of the digits of n in the given base

I would have expected the behavior to always return something that is non-empty so it would seem like relying on it being empty would be relying on a bug since that is sort of confusing behavior (as 0 is a number and has one digit).

[rfourquet]

A last attempt: with pad==0, the most significant digit of the array is never 0 (this is a nice invariant); to have this invariant true on input 0, the array must remain empty. Well, if you still disagree, I will leave someone else comment on that ;-) You are right though that some precision in the documentation could help.

[StefanKarpinski]

Zero is a zero-digit number in any base. Why? How many powers of the base do you add together to get zero? None of them – i.e. zero digits. The fact that we represent zero as a string with a single0 digit is just because writing no digits would be super confusing. This function does default to the behavior you want since the default value of pad is 1. If someone requests pad == 0 then this is exactly the behavior they are asking for.