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}
(436) 
_{Feb}
(460) 
_{Mar}
(370) 
_{Apr}
(189) 
_{May}
(252) 
_{Jun}
(272) 
_{Jul}
(286) 
_{Aug}
(293) 
_{Sep}
(303) 
_{Oct}
(331) 
_{Nov}
(240) 
_{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: Raymond Toy <toy.raymond@gm...>  20140225 23:51:18

>>>>> "Volker" == Volker van Nek <volkervannek@...> writes: Volker> Am 25.02.2014 01:37, schrieb Raymond Toy: Volker> ... >> Note, however, that some care needs to be exercised when comparing >> with base 10 results. I noticed this just the other day when >> investigating something unrelated. >> >> Consider this: >> >> fpprec:32$ >> cos(bfloat(float(%pi/4))); >> 7.0710678118654754604974576799218b1 >> >> Now consider rounding this bfloat answer to 16 digits. You would get >> 0.7071067811865475 since ..46 is less than half. However, the >> correctly rounded result is: >> >> float(cos(bfloat(float(%pi/4)))); >> 0.7071067811865476 >> >> Note the difference in the last digit. This is because bfloats and >> floats are binary so the rounding happens on bits, not digits and when >> rounding digits, we may not get the same answer as when rounding bits. >> Volker> As far as I understand fpround it does adding an adjust and then Volker> shifting right. That obviously works on bits. I should take a closer Volker> look at that and create some examples for me ... Volker> 0.7071067811865476 is rounded correctly? What am I missing? I can't read Volker> that as an effect of rounding bits. Volker> fpprec:32$ Volker> bfloat(float(%pi/4)) is smaller than bfloat(%pi/4) because the bigfloat Volker> mantissa of bfloat(float(%pi/4)) is padded with zeros on the right. Volker> So cos(bfloat(float(%pi/4))) is greater than cos(bfloat(%pi/4)) = Volker> 1/sqrt(2.0b0) because cos is decreasing around %pi/4. That explains why Volker> 0.7071067811865476 is too large. Volker> With fpprec:32$ I get Volker> 7.0710678118654752440084436210485b−1 as the result of both Volker> cos(bfloat(%pi/4)); and 1/sqrt(2.0b0); Volker> With fpprec:16$ I get Volker> 7.071067811865475b1 which to me is rounded correctly. Volker> float(cos(bfloat(float(%pi/4)))); comprehensibly gives Volker> 0.7071067811865476 in clisp,cmucl,ecl,sbcl but surprisingly gcl returns Volker> 0.70710678118654 Volker> Mmmh? Here is how I derived the result. Lots of manual work. fpprec:32; cos(bfloat(float(%pi/4))); (%o3) 7.0710678118654754604974576799218b1 :lisp $%o3 ((BIGFLOAT SIMP 109) 458938539825448072265192383024213 0) :lisp (write 458938539825448072265192383024213 :base 2) 1011010100000100111100110011001111111001110111100110011000010011101100111000100101101001111011000110001010101 Now, you can use lisp functions to get the top 53 bits of that number and the remaining bits. For the top 53 bits: :lisp (ldb (byte 53 ( 109 53)) 458938539825448072265192383024213) 6369051672525772 Compare that to cos(float(%pi/4)); (%o5) 0.7071067811865476 (%i6) :lisp (integerdecodefloat $%o5) 6369051672525773 53 1 So we see that the mantissa differs by one bit. But look at the other bits of the bigfloat result: :lisp (write (ldb (byte ( 109 53) 0) 458938539825448072265192383024213) :base 2) 11000010011101100111000100101101001111011000110001010101 So if we want to round the result to 53 bits (a doublefloat), we need to add 1 since the remaining bits are greater than 1/2 (leading bit is 1, and the remaining bits are not 0). Hence, add 1 to 6369051672525772 to get 6369051672525773. This matches cos(float(%pi/4)). I'd have to check, but I suspect float(cos(%pi/4)) might be computing float(1/sqrt(2)) which probably causes two roundings: one for float(sqrt(2)) and one for the division. Note that sqrt(0.5) is different from float(1/sqrt(2)). I hope I did this correctly! It's easy to make simple mistakes that cause additional roundings that affect the result. Ray 
From: Norman Beam <ephemeris@gr...>  20140225 21:51:00

Robert, Thank you so much! The rm command did the trick. I hate to think how long that would've taken me to figure out. Best regards, Norman On 2/25/14 3:32 PM, Robert Dodier wrote: > On 20140225, Norman Beam <ephemeris@...> wrote: > >> /Users/norman/.maxima/binary/binarysbcl/share/draw/grcommon.fasl" >> {1005780B23}> >> is a fasl file compiled with SBCL 1.1.14, and can't be loaded into SBCL >> 1.1.15. > I see that file is in the cache of compiled files which Maxima > maintains  just nuke (rm rf, be careful I guess) ~/.maxima/binary > and Maxima will recompile that stuff (using the current version of Lisp). > > HTH > > Robert Dodier > > >  > Flowbased realtime traffic analytics software. Cisco certified tool. > Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer > Customize your own dashboards, set traffic alerts and generate reports. > Network behavioral analysis & security monitoring. Allinone tool. > http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk > _______________________________________________ > Maximadiscuss mailing list > Maximadiscuss@... > https://lists.sourceforge.net/lists/listinfo/maximadiscuss > 
From: Leo Butler <l_butler@us...>  20140225 21:46:10

> Thanks for the prompts reply! If I parse this correctly I've bumped into > the versioning getting out of line with SBCL? > > > > (%i3) :lisp (load "/opt/local/share/maxima/5.30.0/share/draw/draw.lisp"); > ;; loading > #P"/Users/norman/.maxima/binary/binarysbcl/share/draw/grcommon.fasl" > Maxima encountered a Lisp error: > > #<SBSYS:FDSTREAM > for "file > /Users/norman/.maxima/binary/binarysbcl/share/draw/grcommon.fasl" > {1005780B23}> > is a fasl file compiled with SBCL 1.1.14, and can't be loaded into SBCL > 1.1.15. > > Automatically continuing. > To enable the Lisp debugger set *debuggerhook* to nil. > ; > ; compilation unit aborted > ; caught 1 fatal ERROR condition > (%i3) > > > Anything clever I can do or do I just have to trick ports into using the > older version of SBCL? > Norman, if you nuke those out of date fasl files, draw will load fine (it will recompile all the necessary bits which are now outofdate). Open a terminal and copy the following command: rm fr /Users/norman/.maxima/binary/binarysbcl/share/draw/*.fasl I think that this has been fixed in newer versions of draw, but I am not certain. Leo 
From: Volker van Nek <volkervannek@gm...>  20140225 20:42:09

Am 25.02.2014 01:37, schrieb Raymond Toy: ... > Note, however, that some care needs to be exercised when comparing > with base 10 results. I noticed this just the other day when > investigating something unrelated. > > Consider this: > > fpprec:32$ > cos(bfloat(float(%pi/4))); > 7.0710678118654754604974576799218b1 > > Now consider rounding this bfloat answer to 16 digits. You would get > 0.7071067811865475 since ..46 is less than half. However, the > correctly rounded result is: > > float(cos(bfloat(float(%pi/4)))); > 0.7071067811865476 > > Note the difference in the last digit. This is because bfloats and > floats are binary so the rounding happens on bits, not digits and when > rounding digits, we may not get the same answer as when rounding bits. > As far as I understand fpround it does adding an adjust and then shifting right. That obviously works on bits. I should take a closer look at that and create some examples for me ... 0.7071067811865476 is rounded correctly? What am I missing? I can't read that as an effect of rounding bits. fpprec:32$ bfloat(float(%pi/4)) is smaller than bfloat(%pi/4) because the bigfloat mantissa of bfloat(float(%pi/4)) is padded with zeros on the right. So cos(bfloat(float(%pi/4))) is greater than cos(bfloat(%pi/4)) = 1/sqrt(2.0b0) because cos is decreasing around %pi/4. That explains why 0.7071067811865476 is too large. With fpprec:32$ I get 7.0710678118654752440084436210485b−1 as the result of both cos(bfloat(%pi/4)); and 1/sqrt(2.0b0); With fpprec:16$ I get 7.071067811865475b1 which to me is rounded correctly. float(cos(bfloat(float(%pi/4)))); comprehensibly gives 0.7071067811865476 in clisp,cmucl,ecl,sbcl but surprisingly gcl returns 0.70710678118654 Mmmh? ... > > Volker> 3. Timing results: > Volker> fpprec : 199990$ :lisp (time (progn (fppi1) 0)) > ... > > I think some of these results would be useful comments in the code. > Otherwise future maintainers are left wondering why exactly some lisps > use one version and some another. > OK, I can do that. Volker > A commit message including this info is good too, but I find it an annoyance > to go through git log (or git blame) to find the actual commit message. > > Ray > > >  > Flowbased realtime traffic analytics software. Cisco certified tool. > Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer > Customize your own dashboards, set traffic alerts and generate reports. > Network behavioral analysis & security monitoring. Allinone tool. > http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk > _______________________________________________ > Maximadiscuss mailing list > Maximadiscuss@... > https://lists.sourceforge.net/lists/listinfo/maximadiscuss > 
From: Robert Dodier <robert.dodier@gm...>  20140225 20:32:39

On 20140225, Norman Beam <ephemeris@...> wrote: > /Users/norman/.maxima/binary/binarysbcl/share/draw/grcommon.fasl" > {1005780B23}> > is a fasl file compiled with SBCL 1.1.14, and can't be loaded into SBCL > 1.1.15. I see that file is in the cache of compiled files which Maxima maintains  just nuke (rm rf, be careful I guess) ~/.maxima/binary and Maxima will recompile that stuff (using the current version of Lisp). HTH Robert Dodier 
From: Norman Beam <ephemeris@gr...>  20140225 20:16:34

Robert, Thanks for the prompts reply! If I parse this correctly I've bumped into the versioning getting out of line with SBCL? (%i3) :lisp (load "/opt/local/share/maxima/5.30.0/share/draw/draw.lisp"); ;; loading #P"/Users/norman/.maxima/binary/binarysbcl/share/draw/grcommon.fasl" Maxima encountered a Lisp error: #<SBSYS:FDSTREAM for "file /Users/norman/.maxima/binary/binarysbcl/share/draw/grcommon.fasl" {1005780B23}> is a fasl file compiled with SBCL 1.1.14, and can't be loaded into SBCL 1.1.15. Automatically continuing. To enable the Lisp debugger set *debuggerhook* to nil. ; ; compilation unit aborted ; caught 1 fatal ERROR condition (%i3) Anything clever I can do or do I just have to trick ports into using the older version of SBCL? Best regards, Norman On 2/25/14 2:06 PM, Robert Dodier wrote: > On 20140225, Norman Beam <ephemeris@...> wrote: > >> loadfile: failed to load /opt/local/share/maxima/5.30.0/share/draw/draw.lisp > In the command line user interface, can you try: > > (%i1) :lisp (load "/opt/local/share/maxima/5.30.0/share/draw/draw.lisp") > > I think that might give a more specific error message. > > best > > Robert Dodier > > >  > Flowbased realtime traffic analytics software. Cisco certified tool. > Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer > Customize your own dashboards, set traffic alerts and generate reports. > Network behavioral analysis & security monitoring. Allinone tool. > http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk > _______________________________________________ > Maximadiscuss mailing list > Maximadiscuss@... > https://lists.sourceforge.net/lists/listinfo/maximadiscuss > 
From: Robert Dodier <robert.dodier@gm...>  20140225 19:07:16

On 20140225, Norman Beam <ephemeris@...> wrote: > loadfile: failed to load /opt/local/share/maxima/5.30.0/share/draw/draw.lisp In the command line user interface, can you try: (%i1) :lisp (load "/opt/local/share/maxima/5.30.0/share/draw/draw.lisp") I think that might give a more specific error message. best Robert Dodier 
From: Norman Beam <ephemeris@gr...>  20140225 17:06:10

I need a suggestion on how to debug this. I run wxmaxima under OSX 10.8.5 having built it with the port command. To use the draw2d() command I've always had to start by loading draw. This worked fine until I updated wxmaxima this morning. Now it won't return when I enter load(draw); I uninstalled and rebuilt wxmaxima and see the same problem. I downloaded the current wxmaxima 13.04.0/Maxima 5.30.0 prebuilt binary from sourceforge and get the same result with wxmaxima hanging with 'Reading Maxima output' displayed in the status field at the bottom of the wxmaxima window. I tried it from xmaxima and see this: (%i2) load(draw); ;; loading #P"/Users/norman/.maxima/binary/binarysbcl/share/draw/grcommon.fasl" ; ; compilation unit aborted ; caught 1 fatal ERROR condition ; ; compilation unit aborted ; caught 1 fatal ERROR condition loadfile: failed to load /opt/local/share/maxima/5.30.0/share/draw/draw.lisp  an error. To debug this try: debugmode(true); (%i3) The file draw.lisp seems to be there. Any clues how I might debug this problem? Thanks in advance. Norman 
From: Raymond Toy <toy.raymond@gm...>  20140225 02:39:05

>>>>> "Edwin" == Edwin Woollett <woollett@...> writes: [snip] Edwin> By the way, I think it is important for users to see all Edwin> the information quad_qags returns for the outer Edwin> integration, since this can give a clue to potential Edwin> problems. (I use this return information in my nint Edwin> package, for example, for both one and two dimensional Edwin> integrals.) For multiple integrals, I would treat the returned values with some suspicion because it doesn't include any information from the inner integrals. The returned accuracy may be way more accurate than is warranted from the accuracy of the inner integrals. Ray 
From: Raymond Toy <toy.raymond@gm...>  20140225 00:40:14

>>>>> "Robert" == Robert Dodier <robert.dodier@...> writes: Robert> On 20140221, Raymond Toy <toy.raymond@...> wrote: >> Suggestions on what I should do? Should I revert the change? >> Should we just say you have to quote the inner calls to >> quadpack? The former is not so nice since some bug was fixed, >> but the latter is not nice either since that's an incompatible >> change. Robert> Well, I can see advantages either way, but I am learning Robert> towards reverting the change. Maxima has a general policy I'll revert soon. Got to find the bug that originated this change so I can mark it as open again. Ray 
From: Raymond Toy <toy.raymond@gm...>  20140225 00:37:25

>>>>> "Volker" == Volker van Nek <volkervannek@...> writes: Volker> Am 18.02.2014 22:56, schrieb Robert Dodier: >> On 20140218, Volker van Nek <volkervannek@...> wrote: >> >>> Bill Gosper stopped maintaining the code. I am not sure if I >>> should contact him. >> >> Well, I think there's no harm in trying. If he responds, >> terrific, if not, no loss. Volker> In a first step I will try to convince the development Volker> team of my contribution. Volker> I have uploaded new code (and some comments) for fppi1 Volker> resp. comppi which I regard as a bugfix and an Volker> improvement. Volker> I performed tests in which I compared the original code Volker> from Bill Gosper, the revision I made in 2007 and todays Volker> code. Thanks for the update. These look really nice and I'm excited that these match the published values very closely. And the comments on the algorithms helps to understand the code too. Nice! Note, however, that some care needs to be exercised when comparing with base 10 results. I noticed this just the other day when investigating something unrelated. Consider this: fpprec:32$ cos(bfloat(float(%pi/4))); 7.0710678118654754604974576799218b1 Now consider rounding this bfloat answer to 16 digits. You would get 0.7071067811865475 since ..46 is less than half. However, the correctly rounded result is: float(cos(bfloat(float(%pi/4)))); 0.7071067811865476 Note the difference in the last digit. This is because bfloats and floats are binary so the rounding happens on bits, not digits and when rounding digits, we may not get the same answer as when rounding bits. Volker> 1. %pi rounded to $fpprec: Volker> For each $fpprec from 10 to 5010 I compared Volker> string(bfloat(%pi)) to the string of the bigfloat I parsed Volker> in from a published reference file Volker> (http://digitsofpi.com/Top200000DigitsOfPi.htm). With Volker> bfloat(parse_string($fpprec+10_digits_read_from_file)) I Volker> rounded the reference number to current $fpprec. I Volker> compared rounded not truncated numbers. Volker> Todays code: No difference. All bfloat(%pi) correctly Volker> rounded to $fpprec. Original code: 1849 times the last Volker> digit was different, 2642 times the last 2 digits were Volker> different, Volker> 281 times the last 3, Volker> 23 times the last 4, Volker> 3 times the last 5, 1 time the last 6 and 1 time the Volker> last 7. Volker> $fpprec = 199990, last 20 characters: Reference : Volker> "2304687661585748313508b0" Todays code : Volker> "2304687661585748313508b0" Original code: Volker> "2304687661585748313042b0" Volker> 2. Consistency of todays code  example: Volker> Digits 199970 to 200000 (behind 3.) from Volker> Top200000DigitsOfPi.htm: 4687661585 7483135080 Volker> 1444759928 With $fpprec from 199982 to 199991 Volker> substring(string( bfloat(%pi) ), 199973) results: Volker> "46876615857b0" "468766158575b0" "4687661585748b0" Volker> "46876615857483b0" "468766158574831b0" Volker> "4687661585748314b0" "46876615857483135b0" Volker> "468766158574831351b0" "4687661585748313508b0" Volker> "4687661585748313508b0" Volker> 3. Timing results: Volker> fpprec : 199990$ :lisp (time (progn (fppi1) 0)) Volker> With GCL: Original code: real time : 104.870 secs Revision Volker> 2007 (tested with Maxima 5.32.0): real time : 8.200 secs Volker> Todays code: real time : 6.760 secs Volker> Since 2007 there is a GCL and a nonGCL version by Raymond Volker> Toy. I improved the GCL version and now everyone but SBCL Volker> gets benefit from this new code. Maybe some more timing Volker> tests (other environments, more details) have to be done. Volker> rmaxima l ecl u 5.32.0 real time : 13.162 secs rmaxima Volker> l ecl < Todays code real time : 11.367 secs Volker> rmaxima l ccl u 5.32.0 took 213,457 milliseconds Volker> (213.457 seconds) to run. rmaxima l ccl took 117,132 Volker> milliseconds (117.132 seconds) to run. Volker> rmaxima l clisp u 5.32.0 Real time: 20.232536f0 sec. Volker> rmaxima l clisp Real time: 18.960596f0 sec. Volker> rmaxima l cmucl u 5.32.0 Volker> The absolute value of 199990 exceeds limit 100000. > Volker> fpprec : 100000$ Volker> ; 10.68f0 seconds of real time Volker> rmaxima l cmucl Volker> ; 8.54f0 seconds of real time I think some of these results would be useful comments in the code. Otherwise future maintainers are left wondering why exactly some lisps use one version and some another. A commit message including this info is good too, but I find it an annoyance to go through git log (or git blame) to find the actual commit message. Ray 