You can subscribe to this list here.
2009 
_{Jan}
(2) 
_{Feb}
(5) 
_{Mar}

_{Apr}

_{May}
(2) 
_{Jun}
(8) 
_{Jul}
(4) 
_{Aug}

_{Sep}

_{Oct}
(2) 
_{Nov}
(6) 
_{Dec}


2010 
_{Jan}
(1) 
_{Feb}
(1) 
_{Mar}
(3) 
_{Apr}
(2) 
_{May}
(2) 
_{Jun}
(2) 
_{Jul}
(18) 
_{Aug}
(13) 
_{Sep}
(7) 
_{Oct}

_{Nov}

_{Dec}
(2) 
2011 
_{Jan}

_{Feb}
(11) 
_{Mar}

_{Apr}
(4) 
_{May}

_{Jun}
(1) 
_{Jul}
(18) 
_{Aug}
(16) 
_{Sep}
(12) 
_{Oct}
(12) 
_{Nov}
(19) 
_{Dec}
(42) 
2012 
_{Jan}
(16) 
_{Feb}
(3) 
_{Mar}
(8) 
_{Apr}
(14) 
_{May}
(30) 
_{Jun}
(5) 
_{Jul}
(7) 
_{Aug}
(3) 
_{Sep}
(10) 
_{Oct}
(4) 
_{Nov}
(10) 
_{Dec}
(1) 
2013 
_{Jan}
(14) 
_{Feb}
(8) 
_{Mar}
(5) 
_{Apr}
(3) 
_{May}
(9) 
_{Jun}
(19) 
_{Jul}

_{Aug}
(27) 
_{Sep}
(5) 
_{Oct}
(18) 
_{Nov}
(12) 
_{Dec}
(8) 
2014 
_{Jan}
(5) 
_{Feb}
(8) 
_{Mar}
(20) 
_{Apr}
(22) 
_{May}
(28) 
_{Jun}
(9) 
_{Jul}
(6) 
_{Aug}
(46) 
_{Sep}
(40) 
_{Oct}
(15) 
_{Nov}
(8) 
_{Dec}
(34) 
2015 
_{Jan}
(20) 
_{Feb}
(15) 
_{Mar}
(18) 
_{Apr}
(20) 
_{May}
(3) 
_{Jun}
(13) 
_{Jul}
(8) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 



1

2

3

4

5
(5) 
6
(2) 
7
(1) 
8

9
(1) 
10

11

12

13

14

15

16

17
(1) 
18
(1) 
19
(4) 
20

21

22

23

24

25

26

27
(3) 
28
(1) 
29

30




From: Michael Tuexen <tuexen@fh...>  20111119 20:23:40

On Nov 19, 2011, at 8:57 PM, Arthur Norman wrote: >> OK, that works. However, the commands I used were based on the documentation. > > Indeed they were  and in my first reply you see I was asking of other developers had bright ideas for how to provide a full fix. The documentation is in some sense right  just it does not express the awkward fact that multiplicities might be subject to the reductionmodp. That is liable to be an inelegancy (to say the least) that has been there ever since that capability went in > >> >> So let me ask one more question: >> >> Reduce (Free CSL version), 19Nov11 ... >> >> 1: setmod 2; on modular; tr factorize; >> 1 >> (factorize) >> 4: factorize(x^2+x+1); >> Entering factorize (1 arg) >> Arg1: (plus (expt x 2) x 1) >> factorize = (list (list (!*sq ((((x . 2) . 1) ((x . 1) . 1) . 1) . 1) t) 1)) >> >> 2 >> {{x + x + 1,1}} >> >> So the exponent of x is not reduced modulo 2. >> Can't we avoid the multiplicity being >> reduced? This would allow to use reduce as described in the handbook. >> > Exponents live in a different place in the internal datastructures and so are kept safe! The multiplicities are safe WITHIN the factoriser code, but outside that the design handed them back in simple lists. You in general want list elements to be reduced mod p. Hence this horror. > > So to survive that the system has to "know" a bit more that it does not have quite such a global "mod p" setting but that these bits need protecting. Right now I do not believe that that can be done while preserving backwards compatibility! > > For instance try > setmod 3; > on modular; > for i := 1:10 do write i,":",i+1,":",x+i; > and the value of i in the context "x+i" gets reduced mod 3, while the "i" alone and the "i+1" do not. OOOOOh! So this is NOT merely an issue with modular factorisation! OK, I see. > >> Of course, one can add your new function and change the handbook. > > Yup, I implemented my new function but have not (yet?) updated the documentation! Sorry. I didn't expect an updated documentation. Just wanted to make sure that there is no easy way to extend to code to work like it is currently documented. I understood that you asked other developers if they come up with an idea. > > I hope that some of the other developers will join in to see if there is a good rational way ahead that will keep not just this one case happy but happiness in greater generality! Thank you very much for your fast support! BTW: I used reduce years ago and it was running within Common Lisp (I think it was PSL being implemented in Common Lisp. Is this still available? (I think I took the code at that time and ported it to Macintosh Common Lisp....) Best regards Michael > > Arthur > >> Best regards >> Michael >>> >>> where the second argument is the prime you wish to use. At present it may misbehave randomly if you do not pass a PRIME. But at the top level you do not set a modulus or go "on modular" and so the bad reduction of the multiplicities does not happen. >>> >>> At least this gives a way ahead in some cases? >>> >>> Arthur >>> >>> >> >> > 
From: Arthur Norman <acn1@ca...>  20111119 19:57:51

> OK, that works. However, the commands I used were based on the documentation. Indeed they were  and in my first reply you see I was asking of other developers had bright ideas for how to provide a full fix. The documentation is in some sense right  just it does not express the awkward fact that multiplicities might be subject to the reductionmodp. That is liable to be an inelegancy (to say the least) that has been there ever since that capability went in > > So let me ask one more question: > > Reduce (Free CSL version), 19Nov11 ... > > 1: setmod 2; on modular; tr factorize; > 1 > (factorize) > 4: factorize(x^2+x+1); > Entering factorize (1 arg) > Arg1: (plus (expt x 2) x 1) > factorize = (list (list (!*sq ((((x . 2) . 1) ((x . 1) . 1) . 1) . 1) t) 1)) > > 2 > {{x + x + 1,1}} > > So the exponent of x is not reduced modulo 2. > Can't we avoid the multiplicity being > reduced? This would allow to use reduce as described in the handbook. > Exponents live in a different place in the internal datastructures and so are kept safe! The multiplicities are safe WITHIN the factoriser code, but outside that the design handed them back in simple lists. You in general want list elements to be reduced mod p. Hence this horror. So to survive that the system has to "know" a bit more that it does not have quite such a global "mod p" setting but that these bits need protecting. Right now I do not believe that that can be done while preserving backwards compatibility! For instance try setmod 3; on modular; for i := 1:10 do write i,":",i+1,":",x+i; and the value of i in the context "x+i" gets reduced mod 3, while the "i" alone and the "i+1" do not. OOOOOh! So this is NOT merely an issue with modular factorisation! > Of course, one can add your new function and change the handbook. Yup, I implemented my new function but have not (yet?) updated the documentation! Sorry. I hope that some of the other developers will join in to see if there is a good rational way ahead that will keep not just this one case happy but happiness in greater generality! Arthur > Best regards > Michael >> >> where the second argument is the prime you wish to use. At present it may misbehave randomly if you do not pass a PRIME. But at the top level you do not set a modulus or go "on modular" and so the bad reduction of the multiplicities does not happen. >> >> At least this gives a way ahead in some cases? >> >> Arthur >> >> > > 
From: Michael Tuexen <tuexen@fh...>  20111119 17:28:03

On Nov 19, 2011, at 1:51 PM, Arthur Norman wrote: >>> 3: factorize(x^2+1); >>> {{x + 1,0}} >>> I would expect {{x + 1,2}}. > > I have now just checked in a tiny extension so if you update from subversion and rebuild you should be able to go > > factorize!mod!p(x^2+1, 2); OK, that works. However, the commands I used were based on the documentation. So let me ask one more question: Reduce (Free CSL version), 19Nov11 ... 1: setmod 2; on modular; tr factorize; 1 (factorize) 4: factorize(x^2+x+1); Entering factorize (1 arg) Arg1: (plus (expt x 2) x 1) factorize = (list (list (!*sq ((((x . 2) . 1) ((x . 1) . 1) . 1) . 1) t) 1)) 2 {{x + x + 1,1}} So the exponent of x is not reduced modulo 2. Can't we avoid the multiplicity being reduced? This would allow to use reduce as described in the handbook. Of course, one can add your new function and change the handbook. Best regards Michael > > where the second argument is the prime you wish to use. At present it may misbehave randomly if you do not pass a PRIME. But at the top level you do not set a modulus or go "on modular" and so the bad reduction of the multiplicities does not happen. > > At least this gives a way ahead in some cases? > > Arthur > > 
From: Arthur Norman <acn1@ca...>  20111119 12:51:19

>> 3: factorize(x^2+1); >> >> {{x + 1,0}} >> >> I would expect {{x + 1,2}}. I have now just checked in a tiny extension so if you update from subversion and rebuild you should be able to go factorize!mod!p(x^2+1, 2); where the second argument is the prime you wish to use. At present it may misbehave randomly if you do not pass a PRIME. But at the top level you do not set a modulus or go "on modular" and so the bad reduction of the multiplicities does not happen. At least this gives a way ahead in some cases? Arthur 