|Joerg Arndt on Sat, 20 Oct 2012 17:12:24 +0200|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
* Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr> [Oct 19. 2012 20:02]: > On Fri, Oct 19, 2012 at 05:36:04PM +0200, Karim Belabas wrote: > > > > 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 =  > > (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 should return the digits in the other order, so that the relation > between the indices in the vector and the weight in the number is more > straightforward. Make that an *option*. Similarly with Vec(poly), one should have the choice to get falling or rising powers (and another option to set the range of powers would be useful). While we are at it, the omission of leading zero coefficients with Vec(powseries) should also be avoidable IMHO (this ugly-fies much of my code for OEIS sequences). Best, jj > > Cheers, > Bill.