Re: digits(0)

[Mathieu Carbou <mathieu.carbou@gmail.com>]

No it's ok: I think I better understand ;-) It's quite different from
other language where all is 0-based but it makes better sense in PARI !

Thank you all for your fast response !


On 19-Oct-2012 11:36, Karim Belabas wrote:
> * Mathieu Carbou [2012-10-19 16:46]:
>> Hello,
>>
>> I was coding something relative to digits in base 2 and my code crashed
>> when the number reached 0 because
>>
>> digits(0, 2) = []
>> digits(0, 10) = []
>>
>> Whereas digits(1,2) = [1]
>>
>> I was expecting
>>
>> digits(0, 2) = [0]
>> digits(0, 10) = [0]
>>
>> Why 0 does not deserve to be a digit ? In base 2, or b the first
>> bit/digit is 1*b^0 or 0*b^0 so why it is not in the resulting vector  ?
>>
>> Thank you :-)
> In our normalization, the "0" numeral has no digit. We already have
> similar behaviour for polynomials : the 0 polynomial has no
> coefficients.
>
>   (17:25) gp > Vec(x + 2)    \\ Vec(t_POL) returns the polynomial's coeffs
>   %1 = [1, 2]
>   (17:25) gp > Vec(Pol(1,'x))
>   %2 = [1]
>   (17:26) gp > Vec(Pol(0,'x))
>   %3 = []
>
> So the current definition of digits() is consistent with what we already do.
> On the other hand, it is sometimes convenient to consider polynomials
> with respect to a fixed basis, and "degree drops" are inconvenient.
> So Vec() has an optional argument to fix the vector length:
>   (17:25) gp > Vec(Pol(1,'x), 5)
>   %4 = [1, 0, 0, 0, 0]   \\ 0*x^4 + 0*x^3 + 0*x^2 + 0*x + 1
>
>
> Maybe we could provide an optional 3rd argument to digits() to add any number
> of leading zeros ?
>
>   (17:26) gp > digits(3, 2, 5)   \\ we want exactly 5 digits
>   %5 = [0, 0, 0, 1, 1]
>
> It's rather less natural than for polynomials (which can quickly lead to
> linear algebra formulations), but it's easy to add :-)
>
> I'm neutral.
>
> Cheers,
>
>     K.B.


-- 

Mathieu Carbou
Cell: 514-660-4287