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}
(346) 
_{Oct}
(291) 
_{Nov}
(333) 
_{Dec}
(335) 
2017 
_{Jan}
(251) 
_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{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...>  20140217 22:56:50

I think the reality is that the limit program ignores assumptions and declarations. Furthermore, it was initially designed to solve limit problems of real functions of a real variable. If it works in complex cases, that is nice, but perhaps coincidental. The simplifications you observe have to do with simplification after the limit computation. And I think they have nothing to do with log, either. On 2/17/2014 2:39 PM, Mark wrote: > I was checking on the log's branch behavior in the complex plane: > > (%i31) declare(a,real); > (%o31) done > > (%i32) declare(b,real); > (%o32) done > > (%i33) assume(a>b,b>0); > (%o33) [a > b,b > 0] > > (%i34) limit(log(a+%i*eta),eta,0,plus); > (%o34) log(a)+%i*%pi > > (%i35) limit(log(a+%i*eta),eta,0,minus); > (%o35) log(a)%i*%pi > > That's fine with me. Now: > > (%i36) limit(log(ba+%i*eta),eta,0,plus); > (%o36) log(ba)+%i*%pi > > (%i37) limit(log(ba+%i*eta),eta,0,minus); > (%o37) log(ba)%i*%pi > > Here, log(ba) in the preceeding two outputs seems incorrect, > at least the output o36o37 seems inconsistent with o34o35. > For me this should be either log(abs(ba)) or log(ab). > > Why is Maxima's log doing this? note that limit( log(q+%i*z) , z, 0) returns log(q)+%i*atan2(0,q) therefore adding a direction seems unnecessary. the ..,minus and ..., plus limits must be the same. so now we are left with figuring out the meaning of atan2(0,q), or in your case q=ba, which is negative. atan2(0, negative_number) is %pi. So that's what is happening. I hope this is helpful. RJF 
From: Richard Fateman <fateman@be...>  20140217 22:43:12

I'm pretty sure the original comppi code is from Bill Gosper, billgosper@... and it is sometimes the case that making a change that you think is not consequential, really matters. But maybe you've changed all that. You might send a note to Bill, introducing yourself and your objectives.. On 2/17/2014 11:11 AM, Volker van Nek wrote: > Am 17.02.2014 02:39, schrieb Raymond Toy: >> Could you explain why fpe1 and fppi1 needs 24 bits now instead of 12? is it >> because you need these extra bits to get e and pi correct for million >> digits? >> > There are two issues here: > > 1. fpe1 > > My intention was to make sure that all digits are correct up one > million. I now checked this again and it seems that I was fooled by some > random results. It seems that on my computer I generally can't compute > results with a precision of one million. I'm not sure what you are checking, binarytodecimal conversion, string, memory allocation, or the algorithm itself. I assume that the method is amenable to some numerical roundoff analysis and that if the change is to bump up the precision by 12 more bits, that should be defended. And how 11 bits is insufficient and 13 is too much. If you want to see if the numbers are consistent, consider changing ?fpprec, the number of binary digits, and compare the numerical values of the fraction. Ideally the nbit approximation should not differ from the n+M bit approximation rounded down to n bits, but I think that this may not be entirely correct. the last 30 digits of 1,000,000 decimal digits of %e are "786528622001379817644769422819" and 32 digits gives "78652862200137981764476942281888" I have not looked at this again, but it could entirely be the case that the issue is with fpformat, which does DECIMAL bigfloat arithmetic, and may need more extra digits, and that fpe etc does not need more binary bits at all. There is a line in fpformat .. (let ((extradigs (floor (1+ (quotient (integerlength (caddr l)) #.(/ (log 10.0) (log 2.0)))))) ... and maybe that is too small. I think that it is appropriate to do (and write down!) a careful analysis of this to make sure that the changes are not just ad hoc to make 1,000,000 decimal digits work, and that the changes are necessary for the binary number to be correct and to any number of bits. At least if that is the objective. I have a minor quibble with the fix to #1842 nonrepeatable beta_incomplete(1b0,1,z) in which it seems the previous hack, which was to store e pi ,gamma, log(2) to the largest precision yet encountered, and to respond to the needs of lower precision values by rounding... into a hashtable based system in which not the largest precision value, but ALL previously computed values of any precision, are stored. This should not be necessary. This hack of storing everything seemed to result from the observation that the 56bit value of %e was different in the last bit from the 57bit value rounded down. That should not be the case. Maybe the cure is to up the precision by 12 more bits and always round down as you propose?? Please, some explanation, not just "I changed the code" and "here is an example". Thanks RJF > > volker@...:~$ rmaxima l gcl u 5.32.1 > Maxima 5.32.1 http://maxima.sourceforge.net > using Lisp GNU Common Lisp (GCL) GCL 2.6.8 (a.k.a. GCL) > > (%i1) (fpprec:1000000, s:string(bfloat(%e)))$ > > (%i2) [substring(s, 1, 10), substring(s, fpprec  30)]; > (%o2) [2.7182818, 337865286220013798176447694229517b3] > (%i3) (fpprec:1000001, s:string(bfloat(%e)))$ > > (%i4) [substring(s, 1, 10), substring(s, fpprec  31)]; > �3�ˍ,�3���յ:K�b0]b:, K"�r>V_��f�? > (%i5) quit(); > > 33786528622001379817644769422 are correct digits, but: b3 in (%o2) !!! > > With yesterdays build: > > volker@...:~$ rmaxima > Maxima branch_5_32_base_60_g7020269_dirty http://maxima.sourceforge.net > using Lisp GNU Common Lisp (GCL) GCL 2.6.8 (a.k.a. GCL) > > (%i1) (fpprec:1000000, s:string(bfloat(%e)))$ > > (%i2) [substring(s, 1, 10), substring(s, fpprec  30)]; > (%o2) [2.7182818, 33786528622001379817644769423318b0] > (%i3) (fpprec:1000001, s:string(bfloat(%e)))$ > > (%i4) [substring(s, 1, 10), substring(s, fpprec  31)]; > (%o4) [2.7182818, 337865286220013798176447694228238b0] > (%i5) (fpprec:1000002, s:string(bfloat(%e)))$ > > (%i6) [substring(s, 1, 10), substring(s, fpprec  32)]; > (%o6) [2.7182818, 33786528622001379817644769422b5] > (%i7) (fpprec:1000003, s:string(bfloat(%e)))$ > > Unrecoverable error: Pages out of range in make_writable. > > b5 in (%o6) !!! > >> Could you also add some comments on how commpi actually computes >> Chudnovsky's formula? I used to understand it but now I'm not sure. > > 2. comppi > > I thought this change cleaned the source code, but a closer look shows > that I introduced a bug. It seems that all digits up to one million are > correct but there must be wrong values in case of higher precisions. > > > So I will revert these two changes. There is only one thing that is > definitely true: ( (* 6 i) 4) and ( (* 3 i) 2) can be truncated in > comppi. > > Also I am going to add some additional comments. > > Volker > > >> One thing I've always liked about clisp's source code was that (almost?) >> all mathematical algorithms were pretty well commented so you could figure >> out what the code was doing. >> >> >> >> >> On Sun, Feb 16, 2014 at 4:00 AM, Volker van Nek < >> van_nek@...> wrote: >> >>> This is an automated email from the git hooks/postreceive script. It was >>> generated because a ref change was pushed to the repository containing >>> the project "Maxima CAS". >>> >>> The branch, master has been updated >>> via 793ed002e8645f672ebe718462c6f279f4a74adc (commit) >>> from 7020269c68b8f93d3850b6921e68441a256b669e (commit) >>> >>> Those revisions listed above that are new to this repository have >>> not appeared on any other notification email; so we list those >>> revisions in full, below. >>> >>>  Log  >>> commit 793ed002e8645f672ebe718462c6f279f4a74adc >>> Author: Volker van Nek <volkervannek@...> >>> Date: Sun Feb 16 12:59:55 2014 +0100 >>> >>> improve comppi and make sure that %e and %pi are correct up to one mio >>> digits >>> >>> diff git a/src/float.lisp b/src/float.lisp >>> index 9bc1554..8b7b8a4 100644 >>>  a/src/float.lisp >>> +++ b/src/float.lisp >>> @@ 829,7 +829,7 @@ One extra decimal digit in actual representation for >>> rounding purposes.") >>> ;; fpe1 is the bigfloat part of the bfloat(%e) computation >>> ;; >>> (defun fpe1 nil >>>  (bcons (list (fpround (compe (+ fpprec 12))) (+ 12 *m)))) >>> + (bcons (list (fpround (compe (+ fpprec 24))) (+ 24 *m)))) >>> ;; >>> ;; compe is the bignum part of the bfloat(%e) computation >>> ;; (compe N)/(2.0^N) is an approximation to E >>> @@ 872,7 +872,7 @@ One extra decimal digit in actual representation for >>> rounding purposes.") >>> (bcons >>> (fpquotient >>> (fprt18231_) >>>  (list (fpround (comppi (+ fpprec 12))) (+ 12 *m)) ))) >>> + (list (fpround (comppi (+ fpprec 24))) (+ 24 *m)) ))) >>> ;; >>> ;; comppi is the bignum part of the bfloat(%pi) computation >>> ;; (comppi N)/(2.0^N) is an approximation to 640320^(3/2)/12 * 1/PI >>> @@ 884,17 +884,19 @@ One extra decimal digit in actual representation for >>> rounding purposes.") >>> ;; sum( (1)^i*(6*i)!*(545140134*i+13591409) / (i!^3*(3*i)!*640320^(3*i)) >>> ,i,0,inf ) >>> ;; >>> (defun comppi (prec) >>>  (let (s h n d) >>>  (setq s (ash 13591409 prec)) >>>  (setq h (neg (truncate (ash 67047785160 prec) 262537412640768000))) >>>  (setq s (+ s h)) >>>  (do ((i 2 (1+ i))) >>>  ((zerop h)) >>>  (setq n (* 12 ( (* 6 i) 5) ( (* 6 i) 4) ( (* 2 i) 1) ( (* 6 i) >>> 1) (+ (* i 545140134) 13591409) )) >>>  (setq d (* ( (* 3 i) 2) (expt i 3) ( (* i 545140134) 531548725) >>> 262537412640768000)) >>>  (setq h (neg (truncate (* h n) d))) >>>  (setq s (+ s h))) >>>  s )) >>> + (let (s1 s2 h n d) >>> + (setq s1 (ash 1 prec) >>> + h (neg (truncate s1 2187811772006400)) >>> + s1 (+ s1 h) >>> + s2 h ) >>> + (do ((i 2 (1+ i))) >>> + ((zerop h)) >>> + (setq n (* 24 ( (* 6 i) 5) ( (* 2 i) 1) ( (* 6 i) 1)) >>> + d (* (expt i 3) 262537412640768000) >>> + h (neg (truncate (* h n) d)) >>> + s1 (+ s1 h) >>> + s2 (+ s2 (* i h)) )) >>> + (+ (* 13591409 s1) (* 545140134 s2)) )) >>> ;; >>> ;; fprt18231_ computes sqrt(640320^3/12^2) >>> ;; = sqrt(1823176476672000) = 42698670.666333... >>> >>>  >>> >>> Summary of changes: >>> src/float.lisp  28 +++++++++++++++ >>> 1 files changed, 15 insertions(+), 13 deletions() >>> >>> >>> hooks/postreceive >>>  >>> Maxima CAS >>> >>> >>>  >>> 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 >>> _______________________________________________ >>> Maximacommits mailing list >>> Maximacommits@... >>> https://lists.sourceforge.net/lists/listinfo/maximacommits >>> > >  > Managing the Performance of CloudBased Applications > Take advantage of what the Cloud has to offer  Avoid Common Pitfalls. > Read the Whitepaper. > http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk > _______________________________________________ > Maximadiscuss mailing list > Maximadiscuss@... > https://lists.sourceforge.net/lists/listinfo/maximadiscuss 
From: Mark <zeitlinie@ya...>  20140217 22:39:49

I was checking on the log's branch behavior in the complex plane: (%i31) declare(a,real); (%o31) done (%i32) declare(b,real); (%o32) done (%i33) assume(a>b,b>0); (%o33) [a > b,b > 0] (%i34) limit(log(a+%i*eta),eta,0,plus); (%o34) log(a)+%i*%pi (%i35) limit(log(a+%i*eta),eta,0,minus); (%o35) log(a)%i*%pi That's fine with me. Now: (%i36) limit(log(ba+%i*eta),eta,0,plus); (%o36) log(ba)+%i*%pi (%i37) limit(log(ba+%i*eta),eta,0,minus); (%o37) log(ba)%i*%pi Here, log(ba) in the preceeding two outputs seems incorrect, at least the output o36o37 seems inconsistent with o34o35. For me this should be either log(abs(ba)) or log(ab). Why is Maxima's log doing this? M 
From: Rupert Swarbrick <rswarbrick@gm...>  20140217 20:00:23

Richard Fateman <fateman@...> writes: > On 2/16/2014 4:53 PM, Richard Fateman wrote: > Here is an iterative version > > RIN(pred,lt):=block([res:[]], > for i in lt do if apply(pred,[i]) then res:cons(i,res),reverse(res))$ Thank you, Richard. Perhaps you didn't see the code that you snipped, but that's basically the same as what I hacked out in the example I posted: (%i25) block ([acc: []], map(lambda ([rhs], if is('zero = sign(imagpart (rhs))) then acc: cons(rhs, acc)), map (rhs, soln_vt)), acc); except that I do the iteration by calling map for its side effects (wastefully discarding the argument, I admit) and I don't bother calling reverse (mainly because I knew the result had length one). Fortunately, Robert was on hand to show us the wheel we were both reinventing (sublist). Rupert 
From: Rupert Swarbrick <rswarbrick@gm...>  20140217 19:50:13

Robert Dodier <robert.dodier@...> writes: >> A pity that Maxima doesn't seem to have a "filter" or "removeifnot" >> function (going with the common lisp name). > > sublist and/or sublist_indices, perhaps? Ahah! I knew there was something like that, but got stuck at "sublis" (which is rather different). Thanks! Rupert 
From: Rupert Swarbrick <rswarbrick@gm...>  20140217 19:45:22

"Thomas D. Dean" <tomdean@...> writes: > On 02/16/14 03:15, Rupert Swarbrick wrote: > >> Ahah! The first problem is that Maxima doesn't know p(t) is real. If it >> did, then all those horrible atan2's would disappear. Let's try again: >> >> (%i16) declare(p, real); > > Thank you, this is the key. I could not discover how to tell Maxima > that p(t) was real. I was misleading in my subject. I wanted to get > the real solution from the solution set. Er, yes. I think that's what the code I sent you did. But maybe I misunderstood? Rupert 
From: Volker van Nek <volkervannek@gm...>  20140217 19:12:04

Am 17.02.2014 02:39, schrieb Raymond Toy: > Could you explain why fpe1 and fppi1 needs 24 bits now instead of 12? is it > because you need these extra bits to get e and pi correct for million > digits? > There are two issues here: 1. fpe1 My intention was to make sure that all digits are correct up one million. I now checked this again and it seems that I was fooled by some random results. It seems that on my computer I generally can't compute results with a precision of one million. volker@...:~$ rmaxima l gcl u 5.32.1 Maxima 5.32.1 http://maxima.sourceforge.net using Lisp GNU Common Lisp (GCL) GCL 2.6.8 (a.k.a. GCL) (%i1) (fpprec:1000000, s:string(bfloat(%e)))$ (%i2) [substring(s, 1, 10), substring(s, fpprec  30)]; (%o2) [2.7182818, 337865286220013798176447694229517b3] (%i3) (fpprec:1000001, s:string(bfloat(%e)))$ (%i4) [substring(s, 1, 10), substring(s, fpprec  31)]; �3�ˍ,�3���յ:K�b0]b:, K"�r>V_��f�? (%i5) quit(); 33786528622001379817644769422 are correct digits, but: b3 in (%o2) !!! With yesterdays build: volker@...:~$ rmaxima Maxima branch_5_32_base_60_g7020269_dirty http://maxima.sourceforge.net using Lisp GNU Common Lisp (GCL) GCL 2.6.8 (a.k.a. GCL) (%i1) (fpprec:1000000, s:string(bfloat(%e)))$ (%i2) [substring(s, 1, 10), substring(s, fpprec  30)]; (%o2) [2.7182818, 33786528622001379817644769423318b0] (%i3) (fpprec:1000001, s:string(bfloat(%e)))$ (%i4) [substring(s, 1, 10), substring(s, fpprec  31)]; (%o4) [2.7182818, 337865286220013798176447694228238b0] (%i5) (fpprec:1000002, s:string(bfloat(%e)))$ (%i6) [substring(s, 1, 10), substring(s, fpprec  32)]; (%o6) [2.7182818, 33786528622001379817644769422b5] (%i7) (fpprec:1000003, s:string(bfloat(%e)))$ Unrecoverable error: Pages out of range in make_writable. b5 in (%o6) !!! > Could you also add some comments on how commpi actually computes > Chudnovsky's formula? I used to understand it but now I'm not sure. 2. comppi I thought this change cleaned the source code, but a closer look shows that I introduced a bug. It seems that all digits up to one million are correct but there must be wrong values in case of higher precisions. So I will revert these two changes. There is only one thing that is definitely true: ( (* 6 i) 4) and ( (* 3 i) 2) can be truncated in comppi. Also I am going to add some additional comments. Volker > One thing I've always liked about clisp's source code was that (almost?) > all mathematical algorithms were pretty well commented so you could figure > out what the code was doing. > > > > > On Sun, Feb 16, 2014 at 4:00 AM, Volker van Nek < > van_nek@...> wrote: > >> This is an automated email from the git hooks/postreceive script. It was >> generated because a ref change was pushed to the repository containing >> the project "Maxima CAS". >> >> The branch, master has been updated >> via 793ed002e8645f672ebe718462c6f279f4a74adc (commit) >> from 7020269c68b8f93d3850b6921e68441a256b669e (commit) >> >> Those revisions listed above that are new to this repository have >> not appeared on any other notification email; so we list those >> revisions in full, below. >> >>  Log  >> commit 793ed002e8645f672ebe718462c6f279f4a74adc >> Author: Volker van Nek <volkervannek@...> >> Date: Sun Feb 16 12:59:55 2014 +0100 >> >> improve comppi and make sure that %e and %pi are correct up to one mio >> digits >> >> diff git a/src/float.lisp b/src/float.lisp >> index 9bc1554..8b7b8a4 100644 >>  a/src/float.lisp >> +++ b/src/float.lisp >> @@ 829,7 +829,7 @@ One extra decimal digit in actual representation for >> rounding purposes.") >> ;; fpe1 is the bigfloat part of the bfloat(%e) computation >> ;; >> (defun fpe1 nil >>  (bcons (list (fpround (compe (+ fpprec 12))) (+ 12 *m)))) >> + (bcons (list (fpround (compe (+ fpprec 24))) (+ 24 *m)))) >> ;; >> ;; compe is the bignum part of the bfloat(%e) computation >> ;; (compe N)/(2.0^N) is an approximation to E >> @@ 872,7 +872,7 @@ One extra decimal digit in actual representation for >> rounding purposes.") >> (bcons >> (fpquotient >> (fprt18231_) >>  (list (fpround (comppi (+ fpprec 12))) (+ 12 *m)) ))) >> + (list (fpround (comppi (+ fpprec 24))) (+ 24 *m)) ))) >> ;; >> ;; comppi is the bignum part of the bfloat(%pi) computation >> ;; (comppi N)/(2.0^N) is an approximation to 640320^(3/2)/12 * 1/PI >> @@ 884,17 +884,19 @@ One extra decimal digit in actual representation for >> rounding purposes.") >> ;; sum( (1)^i*(6*i)!*(545140134*i+13591409) / (i!^3*(3*i)!*640320^(3*i)) >> ,i,0,inf ) >> ;; >> (defun comppi (prec) >>  (let (s h n d) >>  (setq s (ash 13591409 prec)) >>  (setq h (neg (truncate (ash 67047785160 prec) 262537412640768000))) >>  (setq s (+ s h)) >>  (do ((i 2 (1+ i))) >>  ((zerop h)) >>  (setq n (* 12 ( (* 6 i) 5) ( (* 6 i) 4) ( (* 2 i) 1) ( (* 6 i) >> 1) (+ (* i 545140134) 13591409) )) >>  (setq d (* ( (* 3 i) 2) (expt i 3) ( (* i 545140134) 531548725) >> 262537412640768000)) >>  (setq h (neg (truncate (* h n) d))) >>  (setq s (+ s h))) >>  s )) >> + (let (s1 s2 h n d) >> + (setq s1 (ash 1 prec) >> + h (neg (truncate s1 2187811772006400)) >> + s1 (+ s1 h) >> + s2 h ) >> + (do ((i 2 (1+ i))) >> + ((zerop h)) >> + (setq n (* 24 ( (* 6 i) 5) ( (* 2 i) 1) ( (* 6 i) 1)) >> + d (* (expt i 3) 262537412640768000) >> + h (neg (truncate (* h n) d)) >> + s1 (+ s1 h) >> + s2 (+ s2 (* i h)) )) >> + (+ (* 13591409 s1) (* 545140134 s2)) )) >> ;; >> ;; fprt18231_ computes sqrt(640320^3/12^2) >> ;; = sqrt(1823176476672000) = 42698670.666333... >> >>  >> >> Summary of changes: >> src/float.lisp  28 +++++++++++++++ >> 1 files changed, 15 insertions(+), 13 deletions() >> >> >> hooks/postreceive >>  >> Maxima CAS >> >> >>  >> 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 >> _______________________________________________ >> Maximacommits mailing list >> Maximacommits@... >> https://lists.sourceforge.net/lists/listinfo/maximacommits >> > 
From: Mark <zeitlinie@ya...>  20140217 07:51:21

On 02/15/2014 11:36 PM, Mark wrote: > On 02/15/2014 09:22 PM, Barton Willis wrote: >>> Yet, I do not seem to have a package 'Solver'. If I do load(Solver)$ >> Try load(solver) instead of load(Solver). At least with Maxima on my droid, load(Solver) fails >> and load(solver) works. Sorry for the bother. >> >> In share/algebra/solver there is German language documentation for solver. > This 'Solver' is not bad at all! > I've been playing around with it for the last hour or so and one can set > up lots of nontrivial eqns. it will solve while 'solve' returns just > []. Thanks again. Well, at the end also Solver acts different from what one may anticipate. Maybe I don't understand all of its internal switches yet. In any case, e.g.: eq:[sin(x/2)*cos(sqrt(3)*y/2)sin(x) = 0, sqrt(3)*cos(x/2)*sin(sqrt(3)*y/2) = 0]; This has one solution at [x,y]:[0,0] and one at [x,y]:[%pi,%pi/sqrt(3)] with a sixfold rotational symmetry around [0,0] for the latter. Solver(eq,[x,y]); returns only (%i1) Solver(eq,[x,y]); (%o1) [[x = %pi,y = %pi/sqrt(3)]] I have no problem with loosing the sixfold repetition, but it seems strange that [x,y]:[0,0] is not found  even if inverse angular functions have to be invoked. Another issue is Solver()'s 'behavior' on over determining the eqns., like in (%i1) Solver([sin(x)=0,sin(y)=0,y=1],[x,y]); (%o1) [[x = 0,y = 1]] I.m.h.o. this is just wrong. While (%i1) Solver([x=0,y=0,y=1],[x,y]); Solver terminated. #0: TerminateSolver()(solver.mac line 549) #1: ImmediateAssignments(solutions=[x = 0,y = 0],remainingeqs=[y = 1],variables=[],parameters=[])(solver.mac line 1010) #2: Solver(equations=[x = 0,y = 0,y = 1],solverparams=[[x,y]])(solver.mac line 473)  an error. To debug this try: debugmode(true); At least Solver() does not return a solution here, but I think returning '[]' would seem more 'natural'. M 
From: Richard Fateman <fateman@be...>  20140217 01:42:32

On 2/16/2014 4:53 PM, Richard Fateman wrote: Here is an iterative version RIN(pred,lt):=block([res:[]], for i in lt do if apply(pred,[i]) then res:cons(i,res),reverse(res))$ 
From: Raymond Toy <toy.raymond@gm...>  20140217 01:39:37

Could you explain why fpe1 and fppi1 needs 24 bits now instead of 12? is it because you need these extra bits to get e and pi correct for million digits? Could you also add some comments on how commpi actually computes Chudnovsky's formula? I used to understand it but now I'm not sure. One thing I've always liked about clisp's source code was that (almost?) all mathematical algorithms were pretty well commented so you could figure out what the code was doing. On Sun, Feb 16, 2014 at 4:00 AM, Volker van Nek < van_nek@...> wrote: > This is an automated email from the git hooks/postreceive script. It was > generated because a ref change was pushed to the repository containing > the project "Maxima CAS". > > The branch, master has been updated > via 793ed002e8645f672ebe718462c6f279f4a74adc (commit) > from 7020269c68b8f93d3850b6921e68441a256b669e (commit) > > Those revisions listed above that are new to this repository have > not appeared on any other notification email; so we list those > revisions in full, below. > >  Log  > commit 793ed002e8645f672ebe718462c6f279f4a74adc > Author: Volker van Nek <volkervannek@...> > Date: Sun Feb 16 12:59:55 2014 +0100 > > improve comppi and make sure that %e and %pi are correct up to one mio > digits > > diff git a/src/float.lisp b/src/float.lisp > index 9bc1554..8b7b8a4 100644 >  a/src/float.lisp > +++ b/src/float.lisp > @@ 829,7 +829,7 @@ One extra decimal digit in actual representation for > rounding purposes.") > ;; fpe1 is the bigfloat part of the bfloat(%e) computation > ;; > (defun fpe1 nil >  (bcons (list (fpround (compe (+ fpprec 12))) (+ 12 *m)))) > + (bcons (list (fpround (compe (+ fpprec 24))) (+ 24 *m)))) > ;; > ;; compe is the bignum part of the bfloat(%e) computation > ;; (compe N)/(2.0^N) is an approximation to E > @@ 872,7 +872,7 @@ One extra decimal digit in actual representation for > rounding purposes.") > (bcons > (fpquotient > (fprt18231_) >  (list (fpround (comppi (+ fpprec 12))) (+ 12 *m)) ))) > + (list (fpround (comppi (+ fpprec 24))) (+ 24 *m)) ))) > ;; > ;; comppi is the bignum part of the bfloat(%pi) computation > ;; (comppi N)/(2.0^N) is an approximation to 640320^(3/2)/12 * 1/PI > @@ 884,17 +884,19 @@ One extra decimal digit in actual representation for > rounding purposes.") > ;; sum( (1)^i*(6*i)!*(545140134*i+13591409) / (i!^3*(3*i)!*640320^(3*i)) > ,i,0,inf ) > ;; > (defun comppi (prec) >  (let (s h n d) >  (setq s (ash 13591409 prec)) >  (setq h (neg (truncate (ash 67047785160 prec) 262537412640768000))) >  (setq s (+ s h)) >  (do ((i 2 (1+ i))) >  ((zerop h)) >  (setq n (* 12 ( (* 6 i) 5) ( (* 6 i) 4) ( (* 2 i) 1) ( (* 6 i) > 1) (+ (* i 545140134) 13591409) )) >  (setq d (* ( (* 3 i) 2) (expt i 3) ( (* i 545140134) 531548725) > 262537412640768000)) >  (setq h (neg (truncate (* h n) d))) >  (setq s (+ s h))) >  s )) > + (let (s1 s2 h n d) > + (setq s1 (ash 1 prec) > + h (neg (truncate s1 2187811772006400)) > + s1 (+ s1 h) > + s2 h ) > + (do ((i 2 (1+ i))) > + ((zerop h)) > + (setq n (* 24 ( (* 6 i) 5) ( (* 2 i) 1) ( (* 6 i) 1)) > + d (* (expt i 3) 262537412640768000) > + h (neg (truncate (* h n) d)) > + s1 (+ s1 h) > + s2 (+ s2 (* i h)) )) > + (+ (* 13591409 s1) (* 545140134 s2)) )) > ;; > ;; fprt18231_ computes sqrt(640320^3/12^2) > ;; = sqrt(1823176476672000) = 42698670.666333... > >  > > Summary of changes: > src/float.lisp  28 +++++++++++++++ > 1 files changed, 15 insertions(+), 13 deletions() > > > hooks/postreceive >  > Maxima CAS > > >  > 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 > _______________________________________________ > Maximacommits mailing list > Maximacommits@... > https://lists.sourceforge.net/lists/listinfo/maximacommits > 
From: Richard Fateman <fateman@be...>  20140217 00:53:30

On 2/16/2014 3:33 PM, Robert Dodier wrote: > On Sun, Feb 16, 2014 at 3:15 AM, Rupert Swarbrick <rswarbrick@...> wrote: > >> A pity that Maxima doesn't seem to have a "filter" or "removeifnot" >> function (going with the common lisp name). RemoveIfNot(pred,list):=if []=list then [] else (if apply(pred,[first(list)]) then cons(first(list),RemoveIfNot(pred,rest(list))) else RemoveIfNot(pred,rest(list)))$ example RemoveIfNot(oddp,[1,2,3,4,5]); returns [1,3,5] An iterative version could be advantageous for very long lists. RJF > sublist and/or sublist_indices, perhaps? > > 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 