You can subscribe to this list here.
2014 
_{Jan}

_{Feb}
(232) 
_{Mar}
(323) 
_{Apr}
(383) 
_{May}
(359) 
_{Jun}
(435) 
_{Jul}
(252) 
_{Aug}
(172) 
_{Sep}
(265) 
_{Oct}
(263) 
_{Nov}
(350) 
_{Dec}
(359) 

2015 
_{Jan}
(267) 
_{Feb}
(220) 
_{Mar}
(311) 
_{Apr}
(269) 
_{May}
(388) 
_{Jun}
(403) 
_{Jul}
(172) 
_{Aug}
(399) 
_{Sep}
(364) 
_{Oct}
(269) 
_{Nov}
(357) 
_{Dec}
(468) 
2016 
_{Jan}
(618) 
_{Feb}
(592) 
_{Mar}
(625) 
_{Apr}
(516) 
_{May}
(375) 
_{Jun}
(155) 
_{Jul}
(346) 
_{Aug}
(262) 
_{Sep}
(300) 
_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 







1

2

3

4

5

6

7
(1) 
8

9
(3) 
10
(3) 
11
(1) 
12
(7) 
13
(8) 
14
(13) 
15
(18) 
16
(13) 
17
(11) 
18
(17) 
19
(25) 
20
(22) 
21
(10) 
22
(2) 
23
(16) 
24
(5) 
25
(11) 
26
(10) 
27
(10) 
28
(26) 

From: Richard Fateman <fateman@be...>  20140214 21:50:40

There are really two different issues. 1. Do you really want the fastest integer factorization processing available for large integers? If so, it's probably not going to be the one in Maxima. There are people who devote their lives to hacking up fast factoring programs, and they probably have their own clever ideas for building systems in assembly language etc. Not to say that Maxima doesn't include standard fast methods factoring  but the methods must run in all lisps, including ones with faster or slower bignum arithmetic. or modular arithmetic. So they are not likely going to be the best. 2. Are you looking for a command which compactly states a valid problem in the domain of problems that Maxima addresses, but which runs out of resources, just to see how it breaks? There are many many possibilities. Perhaps we could have a contest to find the shortest command that makes Maxima run out of memory? Or computes for (say) 24 hours, but will in fact terminate. Historical note.. An early version of Macsyma running on a DEC PDP6 computer loaded an integer factoring program into registers, where it ran much fast than it would otherwise. It was able to do this because the PDP6 implemented locations 0 to 15 in its address space as registers, so if you have a 16word program loop, you can run it faster if you put it in those addresses. This hack was of course rather machine dependent. :) RJF 
From: Thomas D. Dean <tomdean@wa...>  20140214 19:24:25

On 02/14/14 04:07, Doug Stewart wrote: I have this same problem. Looking in GCL, >(LISPIMPLEMENTATIONVERSION) "GCL 2.6.10" >(SI::ALLOCATEDCONTIGUOUSPAGES) 299 >(SI::ALLOCATECONTIGUOUSPAGES 5000 T ) 5000 >(SI::ALLOCATEDCONTIGUOUSPAGES) 5000 The argument T makes ALLOCATECONTIGUOUSPAGES do the allocation immediately. If used without T, >(SI::ALLOCATECONTIGUOUSPAGES 5000) T >(SI::MAXIMUMCONTIGUOUSPAGES) 5000 Does this mean the allocation is dynamic? This can be done from maxima either by using to_lisp() or (%i42) :lisp (SI::MAXIMUMCONTIGUOUSPAGES) 64000 etc. Tom Dean 
From: Raymond Toy <toy.raymond@gm...>  20140214 19:15:43

Doug> On Fri, Feb 14, 2014 at 7:44 AM, Doug Stewart Doug> <doug.dastew@...> wrote: [snip] Doug> The question that remains is: Doug> Could maxima do some cleanup (garbage collection) and Doug> release the not needed memory before trying to do this part Gcl should be running GC as needed. It's possible that the algorithm holds on to numbers longer than is needed (and can't be GCed). Or the default amount of memory is smaller than we might want. (I don't know what the default is for gcl and don't know how to find out. I know cmucl defaults to 512 MB of heap, but is easily changed to a different value from the command line. Sbcl can do the same, but I don't know the default amount of memory. Other lisps might have options for that as well.) Ray 
From: andre maute <andre.maute@gm...>  20140214 18:58:21

On 02/14/2014 01:05 PM, Andrej Vodopivec wrote: > On Fri, Feb 14, 2014 at 11:12 AM, andre maute <andre.maute@...> wrote: > >> 10^108 + 17 > > You can use the ifactor_verbose option variable. Below is a very short > computation which finds factors 3^2, 53, 5930, 24083, 6742807. > > Andrej That is very nice to know, but in my documentation for Maxima 5.31.3 the flag is NOT documented :( Regards Andre 
From: Mario Rodriguez <biomates@te...>  20140214 16:37:15

El 13/02/14 00:20, Mike Valenzuela escribió: > Hello I was wondering if there was a 3d draw or 3d plot utility that > uses nonparallel projection? The default parallel projection makes > the plots look flat from certain angles. Hello, Gnuplot doesn't plot 3d graphics with perspective projections, but you can try the vtk renderer with package draw: http://riotorto.users.sourceforge.net/vtk It plots with perspective projection by default. It would be quite simple to add an option to toggle between parallel and perspective projections, in case it were necessary.  Mario 
From: Doug Stewart <doug.dastew@gm...>  20140214 13:48:34

On Fri, Feb 14, 2014 at 7:44 AM, Doug Stewart <doug.dastew@...> wrote: > > > > On Fri, Feb 14, 2014 at 7:05 AM, Andrej Vodopivec < > andrej.vodopivec@...> wrote: > >> >> On Fri, Feb 14, 2014 at 11:12 AM, andre maute <andre.maute@...> wrote: >> >>> 10^108 + 17 >> >> >> You can use the ifactor_verbose option variable. Below is a very short >> computation which finds factors 3^2, 53, 5930, 24083, 6742807. >> >> Andrej >> >> (%i1) l: 10^108 + 17; >> (%o1) 100000000000000000000000000000[49 >> digits]000000000000000000000000000017 >> (%i2) ifactors(l), ifactor_verbose=true; >> Starting factorization of n = >> 1000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000017 >> Initializing prime diffs up to n=1280000 >> Factoring out small prime: 3 (degree:2) >> Factoring out small prime: 53 (degree:1) >> Factoring out small prime: 5939 (degree:1) >> Factoring out small prime: 24083 (degree:1) >> Factoring n = >> 14657425991358725148085733315380513434159805271143840002415775977003621026610874528390424241282333 >> Pollard rho: round #1 of 5 (lim=16000) >> Pollard rho: found factor 6742807 (7 digits) >> ========> Prime factor: 6742807 >> Factoring n = >> 2173786969041042572935237997377132911287510568097802592068225588690825798011254738329367019 >> Pollard rho: round #1 of 5 (lim=16000) >> Pollard rho: round #2 of 5 (lim=17000) >> Pollard rho: round #3 of 5 (lim=18000) >> Pollard rho: round #4 of 5 (lim=19000) >> Pollard rho: round #5 of 5 (lim=20000) >> Pollard p1: round #1 of 3 (lim=25000) >> Pollard p1: round #2 of 3 (lim=30000) >> Maxima encountered a Lisp error: >> Interactive interrupt at #x40003C0. >> Automatically continuing. >> To enable the Lisp debugger set *debuggerhook* to nil. >> >> >> > > > thanks for this info!!! > I got well past what you got but: > > ECM: trying with curve #134 of 150 (lim=26800) > ECM: trying with curve #135 of 150 (lim=27000) > ECM: trying with curve #136 of 150 (lim=27200) > ECM: trying with curve #137 of 150 (lim=27400) > ECM: trying with curve #138 of 150 (lim=27600) > Initializing prime diffs up to n=5520000 > > Maxima encountered a Lisp error: > > Error in MACSYMATOPLEVEL [or a callee]: Contiguous blocks exhausted. > Currently, 3578 pages are allocated. > Use ALLOCATECONTIGUOUSPAGES to expand the space. > > > Automatically continuing. > To enable the Lisp debugger set *debuggerhook* to nil. > after this error I restarted Maxima and now I am trying to factor Factoring n = 217378696904104257293523799737 7132911287510568097802592068225588690825798011254738329367019 This is progressing nicely. (no crash) This factor is of no importance to me (I am just playing). The question that remains is: Could maxima do some cleanup (garbage collection) and release the not needed memory before trying to do this part of the factoring? This is what I did manually by restarting and the starting again on the last part that it was working on. Doug  DAS <https://linuxcounter.net/user/206392.html>; 
From: Doug Stewart <doug.dastew@gm...>  20140214 12:44:18

On Fri, Feb 14, 2014 at 7:05 AM, Andrej Vodopivec < andrej.vodopivec@...> wrote: > > On Fri, Feb 14, 2014 at 11:12 AM, andre maute <andre.maute@...> wrote: > >> 10^108 + 17 > > > You can use the ifactor_verbose option variable. Below is a very short > computation which finds factors 3^2, 53, 5930, 24083, 6742807. > > Andrej > > (%i1) l: 10^108 + 17; > (%o1) 100000000000000000000000000000[49 > digits]000000000000000000000000000017 > (%i2) ifactors(l), ifactor_verbose=true; > Starting factorization of n = > 1000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000017 > Initializing prime diffs up to n=1280000 > Factoring out small prime: 3 (degree:2) > Factoring out small prime: 53 (degree:1) > Factoring out small prime: 5939 (degree:1) > Factoring out small prime: 24083 (degree:1) > Factoring n = > 14657425991358725148085733315380513434159805271143840002415775977003621026610874528390424241282333 > Pollard rho: round #1 of 5 (lim=16000) > Pollard rho: found factor 6742807 (7 digits) > ========> Prime factor: 6742807 > Factoring n = > 2173786969041042572935237997377132911287510568097802592068225588690825798011254738329367019 > Pollard rho: round #1 of 5 (lim=16000) > Pollard rho: round #2 of 5 (lim=17000) > Pollard rho: round #3 of 5 (lim=18000) > Pollard rho: round #4 of 5 (lim=19000) > Pollard rho: round #5 of 5 (lim=20000) > Pollard p1: round #1 of 3 (lim=25000) > Pollard p1: round #2 of 3 (lim=30000) > Maxima encountered a Lisp error: > Interactive interrupt at #x40003C0. > Automatically continuing. > To enable the Lisp debugger set *debuggerhook* to nil. > > > thanks for this info!!! I got well past what you got but: ECM: trying with curve #134 of 150 (lim=26800) ECM: trying with curve #135 of 150 (lim=27000) ECM: trying with curve #136 of 150 (lim=27200) ECM: trying with curve #137 of 150 (lim=27400) ECM: trying with curve #138 of 150 (lim=27600) Initializing prime diffs up to n=5520000 Maxima encountered a Lisp error: Error in MACSYMATOPLEVEL [or a callee]: Contiguous blocks exhausted. Currently, 3578 pages are allocated. Use ALLOCATECONTIGUOUSPAGES to expand the space. Automatically continuing. To enable the Lisp debugger set *debuggerhook* to nil. 
From: 本田康晃 <yasuaki.honda@gm...>  20140214 12:30:50

Dear Robert san, Thanks for restoring the maxima mailing list!! This is great!! Thanks and best regards, Yasuaki Honda, Chiba, Japan 20140214 4:36 GMT+09:00 Robert Dodier <robert.dodier@...>: > Hello, > > Sourceforge has imported the subscriber list for the old mailing list > (maxima@...). (We might get them to import the archives > too.) So now any message sent to maximadiscuss goes to all the same > subscribers as before. Have at it! > > best > > Robert Dodier > > >  > Android apps run on BlackBerry 10 > Introducing the new BlackBerry 10.2.1 Runtime for Android apps. > Now with support for Jelly Bean, Bluetooth, Mapview and more. > Get your Android app in front of a whole new audience. Start now. > > http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk > _______________________________________________ > Maximadiscuss mailing list > Maximadiscuss@... > https://lists.sourceforge.net/lists/listinfo/maximadiscuss > 
From: Doug Stewart <doug.dastew@gm...>  20140214 12:07:18

On Wed, Feb 12, 2014 at 7:59 PM, Doug Stewart <doug.dastew@...> wrote: > (%i24) factor(10^108 + 17); > Maxima encountered a Lisp error: > > Error in MACSYMATOPLEVEL [or a callee]: Contiguous blocks exhausted. > Currently, 3578 pages are allocated. > Use ALLOCATECONTIGUOUSPAGES to expand the space. > What I really wanted to know was how to: "Use ALLOCATECONTIGUOUSPAGES to expand the space." Since that is what Maxima tells me to do. > >  > DAS > > <https://linuxcounter.net/user/206392.html>; >  DAS[image: Certificate for 206392] <https://linuxcounter.net/user/206392.html>; 
From: Andrej Vodopivec <andrej.vodopivec@gm...>  20140214 12:05:26

On Fri, Feb 14, 2014 at 11:12 AM, andre maute <andre.maute@...> wrote: > 10^108 + 17 You can use the ifactor_verbose option variable. Below is a very short computation which finds factors 3^2, 53, 5930, 24083, 6742807. Andrej (%i1) l: 10^108 + 17; (%o1) 100000000000000000000000000000[49 digits]000000000000000000000000000017 (%i2) ifactors(l), ifactor_verbose=true; Starting factorization of n = 1000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000017 Initializing prime diffs up to n=1280000 Factoring out small prime: 3 (degree:2) Factoring out small prime: 53 (degree:1) Factoring out small prime: 5939 (degree:1) Factoring out small prime: 24083 (degree:1) Factoring n = 14657425991358725148085733315380513434159805271143840002415775977003621026610874528390424241282333 Pollard rho: round #1 of 5 (lim=16000) Pollard rho: found factor 6742807 (7 digits) ========> Prime factor: 6742807 Factoring n = 2173786969041042572935237997377132911287510568097802592068225588690825798011254738329367019 Pollard rho: round #1 of 5 (lim=16000) Pollard rho: round #2 of 5 (lim=17000) Pollard rho: round #3 of 5 (lim=18000) Pollard rho: round #4 of 5 (lim=19000) Pollard rho: round #5 of 5 (lim=20000) Pollard p1: round #1 of 3 (lim=25000) Pollard p1: round #2 of 3 (lim=30000) Maxima encountered a Lisp error: Interactive interrupt at #x40003C0. Automatically continuing. To enable the Lisp debugger set *debuggerhook* to nil. 
From: andre maute <andre.maute@gm...>  20140214 10:12:39

On 02/14/2014 11:11 AM, andre maute wrote: > On 02/14/2014 09:05 AM, Volker van Nek wrote: >> But I stopped factoring your number after about 20 minutes. It seems >> that it has at least two large prime factors. >> >> To factor large numbers I recommend to use PARI/GP. GP has implemented a >> field sieve algorithm and is quite fast. Of course GP also has its >> natural limits. To get a feeling for that limits I add a runtime test I >> made with GP. Figure out what runtime is to expect for 10^108 + 17 in >> case it splits into two primes. >> >> ? factorint(nextprime(10^24) * nextprime(10^25)) >> time = 1,332 ms. >> >> Volker van Nek >> >> >> Am 13.02.2014 01:59, schrieb Doug Stewart: >>> (%i24) factor(10^108 + 17); >>> Maxima encountered a Lisp error: >>> > > The original poster Doug asked for the factorization of > 10^108 + 17 > which has clearly 9 as a factor (because of 1 + 106*0 + 1 + 7 = 9) > > Volker revealed that he canceled the computation after 20 minutes. > > Couldn't ifactors be modified to reveal more information > for already found factors? > > Regards Andre 
From: Volker van Nek <volkervannek@gm...>  20140214 08:06:04

I guess you run the GCL version of Maxima. Don't know whether GCL provides an option variable to increase memory. If you compile Maxima with SBCL you can try something like maxima l sbcl X 'dynamicspacesize 2700' On my computer Maxima then uses about 160MB memory when factoring. But I stopped factoring your number after about 20 minutes. It seems that it has at least two large prime factors. To factor large numbers I recommend to use PARI/GP. GP has implemented a field sieve algorithm and is quite fast. Of course GP also has its natural limits. To get a feeling for that limits I add a runtime test I made with GP. Figure out what runtime is to expect for 10^108 + 17 in case it splits into two primes. ? factorint(nextprime(10^24) * nextprime(10^25)) time = 1,332 ms. ? factorint(nextprime(10^26) * nextprime(10^27)) time = 3,188 ms. ? factorint(nextprime(10^28) * nextprime(10^29)) time = 8,220 ms. ? factorint(nextprime(10^30) * nextprime(10^31)) time = 15,616 ms. ? factorint(nextprime(10^32) * nextprime(10^33)) time = 44,080 ms. ? factorint(nextprime(10^34) * nextprime(10^35)) time = 2min, 49,248 ms. ? factorint(nextprime(10^36) * nextprime(10^37)) time = 4min, 13,820 ms. ? factorint(nextprime(10^38) * nextprime(10^39)) time = 12min, 14,048 ms. ? factorint(nextprime(10^40) * nextprime(10^41)) time = 40min, 17,088 ms. Volker van Nek Am 13.02.2014 01:59, schrieb Doug Stewart: > (%i24) factor(10^108 + 17); > Maxima encountered a Lisp error: > > Error in MACSYMATOPLEVEL [or a callee]: Contiguous blocks exhausted. > Currently, 3578 pages are allocated. > Use ALLOCATECONTIGUOUSPAGES to expand the space. > > > >  > Android apps run on BlackBerry 10 > Introducing the new BlackBerry 10.2.1 Runtime for Android apps. > Now with support for Jelly Bean, Bluetooth, Mapview and more. > Get your Android app in front of a whole new audience. Start now. > http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk > > > > _______________________________________________ > Maximadiscuss mailing list > Maximadiscuss@... > https://lists.sourceforge.net/lists/listinfo/maximadiscuss > 
From: Raymond Toy <toy.raymond@gm...>  20140214 07:51:15

On Thu, Feb 13, 2014 at 12:52 PM, Robert Dodier <robert.dodier@...>wrote: > On 20140213, Raymond Toy <toy.raymond@...> wrote: > > > And the link to gmane is working again. Fantastic! > > How do you use Gmane? I am looking at the web interface [1] at the > moment and it doesn't seem to be displaying messages correctly. > I also use Gmane via slrn (textonly newsreader) and it seems to > be working as expected (I'm posting this message via slrn as we > speak). > I use GNUS, emacs news reader. The web interface seems to be working for me now. At least I see this thread there, along with the older messages. Ray > > best > > Robert Dodier > > [1] http://thread.gmane.org/gmane.comp.mathematics.maxima.general > > > > >  > Android apps run on BlackBerry 10 > Introducing the new BlackBerry 10.2.1 Runtime for Android apps. > Now with support for Jelly Bean, Bluetooth, Mapview and more. > Get your Android app in front of a whole new audience. Start now. > > http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk > _______________________________________________ > Maximadiscuss mailing list > Maximadiscuss@... > https://lists.sourceforge.net/lists/listinfo/maximadiscuss > 