MaplePrimes - comments on Post, Sparse Polynomial Arithmetic 2: Packed Arrays

MaplePrimes - comments on Post, Sparse Polynomial Arithmetic 2: Packed Arrays http://www.mapleprimes.com/posts/36220-Sparse-Polynomial-Arithmetic-2-Packed-Arrays en-us 2026 Maplesoft, A Division of Waterloo Maple Inc. Maplesoft Document System Wed, 10 Jun 2026 16:25:45 GMT Wed, 10 Jun 2026 16:25:45 GMT The latest comments added to the Post, Sparse Polynomial Arithmetic 2: Packed Arrays http://www.mapleprimes.com/images/mapleprimeswhite.jpg MaplePrimes - comments on Post, Sparse Polynomial Arithmetic 2: Packed Arrays http://www.mapleprimes.com/posts/36220-Sparse-Polynomial-Arithmetic-2-Packed-Arrays generic? http://www.mapleprimes.com/posts/36220-Sparse-Polynomial-Arithmetic-2-Packed-Arrays?ref=Feed:MaplePrimes:Sparse Polynomial Arithmetic 2: Packed Arrays:Comments#comment61249 As I have understood from your <a href="http://www.mapleprimes.com/blog/romanpearce/sparsepolynomialarithmetic1maplesdatastructure">blog 1</a>, the design of the current DAG structure for polynomials is generic in that it allows for objects like function calls, other sums, etc.  Now, when you say "variables" for this new "linear" structure, you mean just names as in your example? The latest comments added to the Post, Sparse Polynomial Arithmetic 2: Packed Arrays 61249 Sat, 05 Dec 2009 00:36:45 Z jakubi jakubi generic? http://www.mapleprimes.com/posts/36220-Sparse-Polynomial-Arithmetic-2-Packed-Arrays?ref=Feed:MaplePrimes:Sparse Polynomial Arithmetic 2: Packed Arrays:Comments#comment61250 It will be limited to names initially. It might be nice to support functions, but that will greatly complicate the coding of algorithms. For example, expand(f) where one of the variables is sin(2*x). I don't think it makes sense to support more general Maple structures like sums. One other restriction that I forgot to mention is that the coefficients must be integers. Rational arithmetic is hopelessly slow so there's no reason to support it. Programmers will be encouraged to clear denominators, while ordinary Maple users who don't know or care will be well served by routines which clear denominators, compute, and then restore them. Double precision coefficients may be worth supporting if there are industrial applications. The latest comments added to the Post, Sparse Polynomial Arithmetic 2: Packed Arrays 61250 Sat, 05 Dec 2009 09:27:53 Z roman_pearce roman_pearce default? http://www.mapleprimes.com/posts/36220-Sparse-Polynomial-Arithmetic-2-Packed-Arrays?ref=Feed:MaplePrimes:Sparse Polynomial Arithmetic 2: Packed Arrays:Comments#comment61251 So, it appears like this new linear structure cannot become the default, but can only be created from the DAG structure after checking that it is the right type (names and integer coefficients, say), or by an explicit command called by a programmer who cares about inserting the right input. Anyway, it is my opinion that expand should distribute products over sums, but not expand sin(2*x) (or other mathematical functions) unless explicitly requested. The latest comments added to the Post, Sparse Polynomial Arithmetic 2: Packed Arrays 61251 Sat, 05 Dec 2009 10:01:15 Z jakubi jakubi default? http://www.mapleprimes.com/posts/36220-Sparse-Polynomial-Arithmetic-2-Packed-Arrays?ref=Feed:MaplePrimes:Sparse Polynomial Arithmetic 2: Packed Arrays:Comments#comment61252 When polynomials are first entered, Maple will create the old dag structure and simplify it to new one. But after that, Maple will try to keep things in the array format. For example, let f(x,y,z) and g(x,y,z) be two polynomials stored as packed arrays. If you create f*g it will be a Maple prod with f^1*g^1. Nothing new, the packed array replaces the Maple's sum. Calling expand(f*g) will multiply in the packed array format. Other routines like coeff(f,x,i) will similarly preserve the structure. There are quite a lot of gory details to handle polynomials in different variables and things like subs(x=y+1, f) and stuff, which is why this is not shipping soon. Those details have been worked out with an emphasis on speed. More generality can be added later once we get the thing working. The latest comments added to the Post, Sparse Polynomial Arithmetic 2: Packed Arrays 61252 Sat, 05 Dec 2009 11:19:54 Z roman_pearce roman_pearce 64-bit packed array http://www.mapleprimes.com/posts/36220-Sparse-Polynomial-Arithmetic-2-Packed-Arrays?ref=Feed:MaplePrimes:Sparse Polynomial Arithmetic 2: Packed Arrays:Comments#comment61253 On a 64-bit machine do you allow more variables, or higher exponents, or a combination?  The latest comments added to the Post, Sparse Polynomial Arithmetic 2: Packed Arrays 61253 Wed, 10 Mar 2010 11:47:24 Z Joe Riel Joe Riel 64-bit packed array http://www.mapleprimes.com/posts/36220-Sparse-Polynomial-Arithmetic-2-Packed-Arrays?ref=Feed:MaplePrimes:Sparse Polynomial Arithmetic 2: Packed Arrays:Comments#comment61254 In the current Maple interface you specify the number of exponents per word, so 64-bits gets you higher degrees and/or fewer words per monomial. The monomials are not limited in size, but they do use a dense format. We assume that all variables could appear in all terms. In the data structure we are adding to the kernel the monomials are always one word long. Then 64-bits gives you higher degrees and more variables. It always uses grlex order and the variables are sorted in Maple's set order. The packing is fixed by the number of variables and the range is different for 32 and 64-bit machines. On a 64-bit machine a polynomial with 3 variables stores 4 exponents (the first is the total degree), 16 bits each, so the maximum total degree and the maximum degree in each variable is 65535. Beyond that the kernel won't use the structure. For a 32-bit machine this limit is 255, which is much more restrictive but still widely applicable. The latest comments added to the Post, Sparse Polynomial Arithmetic 2: Packed Arrays 61254 Sat, 13 Mar 2010 09:10:22 Z roman_pearce roman_pearce