## maxima-discuss — Maxima discussion list

You can subscribe to this list here.

 2014 2015 2016 2017 Jan Feb (232) Mar (323) Apr (383) May (359) Jun (435) Jul (252) Aug (172) Sep (265) Oct (263) Nov (350) Dec (359) Jan (267) Feb (220) Mar (311) Apr (269) May (388) Jun (403) Jul (172) Aug (399) Sep (364) Oct (269) Nov (357) Dec (468) Jan (618) Feb (592) Mar (625) Apr (516) May (375) Jun (155) Jul (346) Aug (262) Sep (346) Oct (291) Nov (333) Dec (335) 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)

Showing 11 results of 11

 Re: [Maxima-discuss] [Maxima-commits] [git] Maxima CAS branch, master, updated. branch-5_32-base-61-g793ed00 From: Raymond Toy - 2014-02-25 23:51:18 ```>>>>> "Volker" == Volker van Nek 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.0710678118654754604974576799218b-1 >> >> 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.071067811865475b-1 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.0710678118654754604974576799218b-1 :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 (integer-decode-float \$%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 double-float), 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 ```
 [Maxima-discuss] SOLVED! - was load(draw) stopped working for me in Mac OSX From: Norman Beam - 2014-02-25 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 2014-02-25, Norman Beam wrote: > >> /Users/norman/.maxima/binary/binary-sbcl/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 > > > ------------------------------------------------------------------------------ > Flow-based real-time 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. All-in-one tool. > http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk > _______________________________________________ > Maxima-discuss mailing list > Maxima-discuss@... > https://lists.sourceforge.net/lists/listinfo/maxima-discuss > ```
 Re: [Maxima-discuss] load(draw) stopped working for me in Mac OSX From: Leo Butler - 2014-02-25 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/binary-sbcl/share/draw/grcommon.fasl" > Maxima encountered a Lisp error: > > # for "file > /Users/norman/.maxima/binary/binary-sbcl/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 *debugger-hook* 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 out-of-date). Open a terminal and copy the following command: rm -fr /Users/norman/.maxima/binary/binary-sbcl/share/draw/*.fasl I think that this has been fixed in newer versions of draw, but I am not certain. Leo ```
 Re: [Maxima-discuss] [Maxima-commits] [git] Maxima CAS branch, master, updated. branch-5_32-base-61-g793ed00 From: Volker van Nek - 2014-02-25 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.0710678118654754604974576799218b-1 > > 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.071067811865475b-1 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 > > > ------------------------------------------------------------------------------ > Flow-based real-time 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. All-in-one tool. > http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk > _______________________________________________ > Maxima-discuss mailing list > Maxima-discuss@... > https://lists.sourceforge.net/lists/listinfo/maxima-discuss > ```
 Re: [Maxima-discuss] load(draw) stopped working for me in Mac OSX From: Robert Dodier - 2014-02-25 20:32:39 ```On 2014-02-25, Norman Beam wrote: > /Users/norman/.maxima/binary/binary-sbcl/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 ```
 Re: [Maxima-discuss] load(draw) stopped working for me in Mac OSX From: Norman Beam - 2014-02-25 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/binary-sbcl/share/draw/grcommon.fasl" Maxima encountered a Lisp error: # 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 *debugger-hook* 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 2014-02-25, Norman Beam 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 > > > ------------------------------------------------------------------------------ > Flow-based real-time 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. All-in-one tool. > http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk > _______________________________________________ > Maxima-discuss mailing list > Maxima-discuss@... > https://lists.sourceforge.net/lists/listinfo/maxima-discuss > ```
 Re: [Maxima-discuss] load(draw) stopped working for me in Mac OSX From: Robert Dodier - 2014-02-25 19:07:16 ```On 2014-02-25, Norman Beam 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 ```
 [Maxima-discuss] load(draw) stopped working for me in Mac OSX From: Norman Beam - 2014-02-25 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/binary-sbcl/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 ```
 Re: [Maxima-discuss] Naive Use of the Lambda Function with QuadpackDouble Integrals From: Raymond Toy - 2014-02-25 02:39:05 ```>>>>> "Edwin" == Edwin 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 ```
 Re: [Maxima-discuss] quadpack double integral error in v. 5.31.2 From: Raymond Toy - 2014-02-25 00:40:14 ```>>>>> "Robert" == Robert Dodier writes: Robert> On 2014-02-21, Raymond Toy 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 ```
 Re: [Maxima-discuss] [Maxima-commits] [git] Maxima CAS branch, master, updated. branch-5_32-base-61-g793ed00 From: Raymond Toy - 2014-02-25 00:37:25 ```>>>>> "Volker" == Volker van Nek writes: Volker> Am 18.02.2014 22:56, schrieb Robert Dodier: >> On 2014-02-18, Volker van Nek 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.0710678118654754604974576799218b-1 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/Top-200000-Digits-Of-Pi.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> Top-200000-Digits-Of-Pi.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 non-GCL 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 ```

Showing 11 results of 11