You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(67) |
Jul
(61) |
Aug
(49) |
Sep
(43) |
Oct
(59) |
Nov
(24) |
Dec
(18) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(34) |
Feb
(35) |
Mar
(72) |
Apr
(42) |
May
(46) |
Jun
(15) |
Jul
(64) |
Aug
(62) |
Sep
(22) |
Oct
(41) |
Nov
(57) |
Dec
(56) |
2004 |
Jan
(48) |
Feb
(47) |
Mar
(33) |
Apr
(39) |
May
(6) |
Jun
(17) |
Jul
(19) |
Aug
(10) |
Sep
(14) |
Oct
(74) |
Nov
(80) |
Dec
(22) |
2005 |
Jan
(43) |
Feb
(33) |
Mar
(52) |
Apr
(74) |
May
(32) |
Jun
(58) |
Jul
(18) |
Aug
(41) |
Sep
(71) |
Oct
(28) |
Nov
(65) |
Dec
(68) |
2006 |
Jan
(54) |
Feb
(37) |
Mar
(82) |
Apr
(211) |
May
(69) |
Jun
(75) |
Jul
(279) |
Aug
(139) |
Sep
(135) |
Oct
(58) |
Nov
(81) |
Dec
(78) |
2007 |
Jan
(141) |
Feb
(134) |
Mar
(65) |
Apr
(49) |
May
(61) |
Jun
(90) |
Jul
(72) |
Aug
(53) |
Sep
(86) |
Oct
(61) |
Nov
(62) |
Dec
(101) |
2008 |
Jan
(100) |
Feb
(66) |
Mar
(76) |
Apr
(95) |
May
(77) |
Jun
(93) |
Jul
(103) |
Aug
(76) |
Sep
(42) |
Oct
(55) |
Nov
(44) |
Dec
(75) |
2009 |
Jan
(103) |
Feb
(105) |
Mar
(121) |
Apr
(59) |
May
(103) |
Jun
(82) |
Jul
(67) |
Aug
(76) |
Sep
(85) |
Oct
(75) |
Nov
(181) |
Dec
(133) |
2010 |
Jan
(107) |
Feb
(116) |
Mar
(145) |
Apr
(89) |
May
(138) |
Jun
(85) |
Jul
(82) |
Aug
(111) |
Sep
(70) |
Oct
(83) |
Nov
(60) |
Dec
(16) |
2011 |
Jan
(61) |
Feb
(16) |
Mar
(52) |
Apr
(41) |
May
(34) |
Jun
(41) |
Jul
(57) |
Aug
(73) |
Sep
(21) |
Oct
(45) |
Nov
(50) |
Dec
(28) |
2012 |
Jan
(70) |
Feb
(36) |
Mar
(71) |
Apr
(29) |
May
(48) |
Jun
(61) |
Jul
(44) |
Aug
(54) |
Sep
(20) |
Oct
(28) |
Nov
(41) |
Dec
(137) |
2013 |
Jan
(62) |
Feb
(55) |
Mar
(31) |
Apr
(23) |
May
(54) |
Jun
(54) |
Jul
(90) |
Aug
(46) |
Sep
(38) |
Oct
(60) |
Nov
(92) |
Dec
(17) |
2014 |
Jan
(62) |
Feb
(35) |
Mar
(72) |
Apr
(30) |
May
(97) |
Jun
(81) |
Jul
(63) |
Aug
(64) |
Sep
(28) |
Oct
(45) |
Nov
(48) |
Dec
(109) |
2015 |
Jan
(106) |
Feb
(36) |
Mar
(65) |
Apr
(63) |
May
(95) |
Jun
(56) |
Jul
(48) |
Aug
(55) |
Sep
(100) |
Oct
(57) |
Nov
(33) |
Dec
(46) |
2016 |
Jan
(76) |
Feb
(53) |
Mar
(88) |
Apr
(79) |
May
(62) |
Jun
(65) |
Jul
(37) |
Aug
(23) |
Sep
(108) |
Oct
(68) |
Nov
(66) |
Dec
(47) |
2017 |
Jan
(55) |
Feb
(11) |
Mar
(30) |
Apr
(19) |
May
(14) |
Jun
(21) |
Jul
(30) |
Aug
(48) |
Sep
(39) |
Oct
(30) |
Nov
(75) |
Dec
(28) |
2018 |
Jan
(70) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2019 |
Jan
(19) |
Feb
(61) |
Mar
(14) |
Apr
(7) |
May
(5) |
Jun
(17) |
Jul
(5) |
Aug
(7) |
Sep
(11) |
Oct
(2) |
Nov
(17) |
Dec
(9) |
2020 |
Jan
(8) |
Feb
(8) |
Mar
(12) |
Apr
(17) |
May
(2) |
Jun
(10) |
Jul
(24) |
Aug
(6) |
Sep
(16) |
Oct
(3) |
Nov
(10) |
Dec
(40) |
2021 |
Jan
(53) |
Feb
(18) |
Mar
(20) |
Apr
(11) |
May
(23) |
Jun
(37) |
Jul
(28) |
Aug
(32) |
Sep
(105) |
Oct
(81) |
Nov
(109) |
Dec
(41) |
2022 |
Jan
(139) |
Feb
(82) |
Mar
(96) |
Apr
(51) |
May
(58) |
Jun
(104) |
Jul
(32) |
Aug
(61) |
Sep
(37) |
Oct
(25) |
Nov
(94) |
Dec
(81) |
2023 |
Jan
(113) |
Feb
(77) |
Mar
(98) |
Apr
(43) |
May
(48) |
Jun
(28) |
Jul
(72) |
Aug
(40) |
Sep
(44) |
Oct
(61) |
Nov
(70) |
Dec
(94) |
2024 |
Jan
(101) |
Feb
(21) |
Mar
(66) |
Apr
(88) |
May
(55) |
Jun
(109) |
Jul
(57) |
Aug
(103) |
Sep
(44) |
Oct
|
Nov
|
Dec
|
From: SourceForge.net <no...@so...> - 2006-07-31 02:48:16
|
Bugs item #990924, was opened at 2004-07-14 09:04 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=990924&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: is(equal(...)) takes sign(%i) Initial Comment: Sometimes is(equal(...)) fails with the message that SIGN was called on an imaginary argument. This happens on Maxima version: 5.9.0 Maxima build date: 19:20 6/28/2004 host type: i686-pc-linux-gnu lisp-implementation-type: CMU Common Lisp lisp-implementation-version: 18e but I have seen it with a later CMUCL snapshot, too. Smallest example I can find: (C1) prederror: false $ (C2) is(equal((%E^(%I*z)-%E^-(%I*z)), 0)); SIGN called on an imaginary argument: %I -- an error. Quitting. To debug this try DEBUGMODE(TRUE);) Albert Reiner, <ar...@tp...>. ---------------------------------------------------------------------- >Comment By: Robert Dodier (robert_dodier) Date: 2006-07-30 20:48 Message: Logged In: YES user_id=501686 Observed in 5.9.3cvs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=990924&group_id=4933 |
From: SourceForge.net <no...@so...> - 2006-07-31 02:47:01
|
Bugs item #984129, was opened at 2004-07-02 09:11 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=984129&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: sometimes Maxima crashes! Initial Comment: Hi, I am facing a very strange problem. I recently installed Maxima on my Windows XP Laptop (I have 512 Mb RAM on it). Everything works fine, but sometimes Maxima crashes (my computer just restarts!) and an error report is generated. Can anyone tell me what the problem is and if there is a patch for this. Thanks for the help! Regards, Narayan Kovvali ---------------------------------------------------------------------- >Comment By: Robert Dodier (robert_dodier) Date: 2006-07-30 20:47 Message: Logged In: YES user_id=501686 Not enough information to make progress, and no contact info to follow up with reporter. Closing this report as "rejected". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=984129&group_id=4933 |
From: SourceForge.net <no...@so...> - 2006-07-31 02:44:54
|
Bugs item #973208, was opened at 2004-06-15 06:23 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=973208&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Xmaxima Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: read prompt appears after read terminates Initial Comment: The read function does not work properly using xmaxima on MS windows. The prompt appears after the terminating semicolon is typed. ---------------------------------------------------------------------- >Comment By: Robert Dodier (robert_dodier) Date: 2006-07-30 20:44 Message: Logged In: YES user_id=501686 Duplicate of bug report [ 874337 ] read prompt string appears "late". Closing this report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=973208&group_id=4933 |
From: SourceForge.net <no...@so...> - 2006-07-31 02:41:54
|
Bugs item #972212, was opened at 2004-06-13 13:12 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=972212&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core - Simplification Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: sqrt((-1)^(1/4) * x) Initial Comment: sqrt(sqrt(-1) * x) is okay (%i2) sqrt(sqrt(-1)*x); (%o2) SQRT(%I x) but sqrt((-1)^(1/4) * x) isn't (%i3) sqrt((-1)^(1/4)*x); SIGN called on an imaginary argument: ... (%i4) build_info(); Maxima version: 5.9.0.1cvs Maxima build date: 12:16 5/28/2004 host type: i686-pc-mingw32 lisp-implementation-type: Kyoto Common Lisp lisp-implementation-version: GCL 2.7.0 Barton ---------------------------------------------------------------------- >Comment By: Robert Dodier (robert_dodier) Date: 2006-07-30 20:41 Message: Logged In: YES user_id=501686 Observed in 5.9.3cvs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=972212&group_id=4933 |
From: SourceForge.net <no...@so...> - 2006-07-31 02:40:27
|
Bugs item #965926, was opened at 2004-06-03 11:21 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=965926&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core - Trigonometry Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: trigsimp exponentially slow on lists Initial Comment: trigsimp of a [] list can sometimes take time exponential in the length of the list. For example: trigsimp(makelist(sin(i)^2+cos(i)^2,i,1,N)) for N=4,5,... takes 0.12, 0.52, 1.50, 4.45, 13.97 secs. Also for sin(i)^2. Of course, it should take linear time. This doesn't happen ---------------------------------------------------------------------- Comment By: Stavros Macrakis (macrakis) Date: 2004-06-03 11:22 Message: Logged In: YES user_id=588346 Oops, "this doesn't happen" should continue... in other cases, like sin(1)^2, sin(x)^2+cos(x)^2, etc. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=965926&group_id=4933 |
From: SourceForge.net <no...@so...> - 2006-07-31 00:05:32
|
Bugs item #1531458, was opened at 2006-07-30 17:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1531458&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Share Libraries Group: To be reviewed Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: specfunctions missing in v. 5.9.3 Initial Comment: I noticed that the directory specfunctions was missing in v. 5.9.3 Is this an oversight, or is there another reason? I am running this on RedHat Fedora Core 4 from v. 5.9.2: [sen@gumbie ~]$ cd /usr/share/maxima/5.9.2/share [sen@gumbie share]$ ls affine diffequations matrix share.usg trigonometry algebra integequations maxima-init.lisp simplification utils calculus integration misc specfunctions vector combinatorics linearalgebra numeric sym contrib macro physics tensor >From v. 5.9.3: [sen@gumbie share]$ pwd /usr/local/src/maxima-5.9.3/share [sen@gumbie share]$ ls affine integequations matrix simplification algebra integration maxima-init.lisp sym builtins-list.txt linearalgebra misc template.texi calculus macro numeric tensor combinatorics Makefile orthopoly trigonometry contrib Makefile.am physics utils diffequations Makefile.in share.usg vector ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1531458&group_id=4933 |
From: SourceForge.net <no...@so...> - 2006-07-29 20:53:45
|
Bugs item #1530698, was opened at 2006-07-28 20:15 Message generated for change (Comment added) made by vttoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1530698&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Share Libraries Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Michael Callaham (callaham) Assigned to: Viktor Toth (vttoth) Summary: ctensor: riemann Initial Comment: /* Example */ load(ctensor); ratfac:true$ ct_coordsys(exteriorschwarzschild,all); lg /* ok */; christof(mcs) /* ok */; riemann(false); cdisplay(riem) /* not ok; cf.: */ ; describe(cdisplay); ---------------------------------------------------------------------- >Comment By: Viktor Toth (vttoth) Date: 2006-07-29 16:53 Message: Logged In: YES user_id=1023504 Yes, I indeed fixed this bug recently in CVS. It was a regression introduced by another change elsewhere in Maxima. Viktor ---------------------------------------------------------------------- Comment By: Viktor Toth (vttoth) Date: 2006-07-29 16:53 Message: Logged In: YES user_id=1023504 The reported bug is not present in the current cvs version of Maxima. Thank you for your report. If you see this bug in a later version of Maxima, please submit a new bug report. ---------------------------------------------------------------------- Comment By: Michael Callaham (callaham) Date: 2006-07-29 16:03 Message: Logged In: YES user_id=1404851 Viktor, I see that ctensor.mac rev. 1.22 (current HEAD of MAIN branch) uses m% instead of m as the summation index variable, so the bug is apparently fixed in rev. 1.22. --Mike ---------------------------------------------------------------------- Comment By: Michael Callaham (callaham) Date: 2006-07-29 15:50 Message: Logged In: YES user_id=1404851 Viktor, Yes, that was obscure--apologies. In maxima-5.9.3 (released version) with clisp on Debian sarge, and also in the binary release for Windows, cdisplay(riem) does not produce the same output that describe(cdisplay) says it should. The outputs are long so I don't want to quote them all here, but one example is the riem[3,1] matrix displayed by cdisplay(riem): [ 0 0 0 0 ] [ ] [ 0 0 0 0 ] [ ] riem = [ 2 ] 3, 1 [ - 0 0 0 ] [ r ] [ ] [ 0 0 0 0 ] describe(cdisplay) says it should be: [ 0 0 0 0 ] [ ] [ 0 0 0 0 ] [ ] riem = [ m ] 3, 1 [ - 0 0 0 ] [ r ] [ ] [ 0 0 0 0 ] This provides a hint: 2 is substituted for m. I've found a patch to ctensor.mac that solves the problem; the diff is: < [flat : true, i, j, k, l, n], --- > [flat : true], 1182,1183c1182,1183 < sum(mcs[n,k,l]*mcs[i,j,n] - < mcs[n,j,l]*mcs[i,k,n], n, 1, dim)), --- > sum(mcs[m,k,l]*mcs[i,j,m] - > mcs[m,j,l]*mcs[i,k,m], m, 1, dim)), The summation index variable m in the else block in the definition of riemann was not local, and it appears that in some components of riem, the value of the index variable m was being used as the value of the mass parameter m. Thanks, --Mike ---------------------------------------------------------------------- Comment By: Viktor Toth (vttoth) Date: 2006-07-29 13:25 Message: Logged In: YES user_id=1023504 I need more information: exactly what is the bug reported here? I tested the CVS version with GCL, CLISP, CMUCL and SBCL on Linux, and cisplay(riem) produces the exact same output that appears in the documentation. Please let me know if you see something different or if I missed something! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1530698&group_id=4933 |
From: SourceForge.net <no...@so...> - 2006-07-29 20:03:49
|
Bugs item #1530698, was opened at 2006-07-28 20:15 Message generated for change (Comment added) made by callaham You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1530698&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Share Libraries Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Callaham (callaham) Assigned to: Viktor Toth (vttoth) Summary: ctensor: riemann Initial Comment: /* Example */ load(ctensor); ratfac:true$ ct_coordsys(exteriorschwarzschild,all); lg /* ok */; christof(mcs) /* ok */; riemann(false); cdisplay(riem) /* not ok; cf.: */ ; describe(cdisplay); ---------------------------------------------------------------------- >Comment By: Michael Callaham (callaham) Date: 2006-07-29 16:03 Message: Logged In: YES user_id=1404851 Viktor, I see that ctensor.mac rev. 1.22 (current HEAD of MAIN branch) uses m% instead of m as the summation index variable, so the bug is apparently fixed in rev. 1.22. --Mike ---------------------------------------------------------------------- Comment By: Michael Callaham (callaham) Date: 2006-07-29 15:50 Message: Logged In: YES user_id=1404851 Viktor, Yes, that was obscure--apologies. In maxima-5.9.3 (released version) with clisp on Debian sarge, and also in the binary release for Windows, cdisplay(riem) does not produce the same output that describe(cdisplay) says it should. The outputs are long so I don't want to quote them all here, but one example is the riem[3,1] matrix displayed by cdisplay(riem): [ 0 0 0 0 ] [ ] [ 0 0 0 0 ] [ ] riem = [ 2 ] 3, 1 [ - 0 0 0 ] [ r ] [ ] [ 0 0 0 0 ] describe(cdisplay) says it should be: [ 0 0 0 0 ] [ ] [ 0 0 0 0 ] [ ] riem = [ m ] 3, 1 [ - 0 0 0 ] [ r ] [ ] [ 0 0 0 0 ] This provides a hint: 2 is substituted for m. I've found a patch to ctensor.mac that solves the problem; the diff is: < [flat : true, i, j, k, l, n], --- > [flat : true], 1182,1183c1182,1183 < sum(mcs[n,k,l]*mcs[i,j,n] - < mcs[n,j,l]*mcs[i,k,n], n, 1, dim)), --- > sum(mcs[m,k,l]*mcs[i,j,m] - > mcs[m,j,l]*mcs[i,k,m], m, 1, dim)), The summation index variable m in the else block in the definition of riemann was not local, and it appears that in some components of riem, the value of the index variable m was being used as the value of the mass parameter m. Thanks, --Mike ---------------------------------------------------------------------- Comment By: Viktor Toth (vttoth) Date: 2006-07-29 13:25 Message: Logged In: YES user_id=1023504 I need more information: exactly what is the bug reported here? I tested the CVS version with GCL, CLISP, CMUCL and SBCL on Linux, and cisplay(riem) produces the exact same output that appears in the documentation. Please let me know if you see something different or if I missed something! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1530698&group_id=4933 |
From: SourceForge.net <no...@so...> - 2006-07-29 19:50:46
|
Bugs item #1530698, was opened at 2006-07-28 20:15 Message generated for change (Comment added) made by callaham You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1530698&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Share Libraries Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Callaham (callaham) Assigned to: Viktor Toth (vttoth) Summary: ctensor: riemann Initial Comment: /* Example */ load(ctensor); ratfac:true$ ct_coordsys(exteriorschwarzschild,all); lg /* ok */; christof(mcs) /* ok */; riemann(false); cdisplay(riem) /* not ok; cf.: */ ; describe(cdisplay); ---------------------------------------------------------------------- >Comment By: Michael Callaham (callaham) Date: 2006-07-29 15:50 Message: Logged In: YES user_id=1404851 Viktor, Yes, that was obscure--apologies. In maxima-5.9.3 (released version) with clisp on Debian sarge, and also in the binary release for Windows, cdisplay(riem) does not produce the same output that describe(cdisplay) says it should. The outputs are long so I don't want to quote them all here, but one example is the riem[3,1] matrix displayed by cdisplay(riem): [ 0 0 0 0 ] [ ] [ 0 0 0 0 ] [ ] riem = [ 2 ] 3, 1 [ - 0 0 0 ] [ r ] [ ] [ 0 0 0 0 ] describe(cdisplay) says it should be: [ 0 0 0 0 ] [ ] [ 0 0 0 0 ] [ ] riem = [ m ] 3, 1 [ - 0 0 0 ] [ r ] [ ] [ 0 0 0 0 ] This provides a hint: 2 is substituted for m. I've found a patch to ctensor.mac that solves the problem; the diff is: < [flat : true, i, j, k, l, n], --- > [flat : true], 1182,1183c1182,1183 < sum(mcs[n,k,l]*mcs[i,j,n] - < mcs[n,j,l]*mcs[i,k,n], n, 1, dim)), --- > sum(mcs[m,k,l]*mcs[i,j,m] - > mcs[m,j,l]*mcs[i,k,m], m, 1, dim)), The summation index variable m in the else block in the definition of riemann was not local, and it appears that in some components of riem, the value of the index variable m was being used as the value of the mass parameter m. Thanks, --Mike ---------------------------------------------------------------------- Comment By: Viktor Toth (vttoth) Date: 2006-07-29 13:25 Message: Logged In: YES user_id=1023504 I need more information: exactly what is the bug reported here? I tested the CVS version with GCL, CLISP, CMUCL and SBCL on Linux, and cisplay(riem) produces the exact same output that appears in the documentation. Please let me know if you see something different or if I missed something! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1530698&group_id=4933 |
From: SourceForge.net <no...@so...> - 2006-07-29 17:25:24
|
Bugs item #1530698, was opened at 2006-07-28 20:15 Message generated for change (Comment added) made by vttoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1530698&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Share Libraries Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Callaham (callaham) >Assigned to: Viktor Toth (vttoth) Summary: ctensor: riemann Initial Comment: /* Example */ load(ctensor); ratfac:true$ ct_coordsys(exteriorschwarzschild,all); lg /* ok */; christof(mcs) /* ok */; riemann(false); cdisplay(riem) /* not ok; cf.: */ ; describe(cdisplay); ---------------------------------------------------------------------- >Comment By: Viktor Toth (vttoth) Date: 2006-07-29 13:25 Message: Logged In: YES user_id=1023504 I need more information: exactly what is the bug reported here? I tested the CVS version with GCL, CLISP, CMUCL and SBCL on Linux, and cisplay(riem) produces the exact same output that appears in the documentation. Please let me know if you see something different or if I missed something! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1530698&group_id=4933 |
From: SourceForge.net <no...@so...> - 2006-07-29 17:23:42
|
Bugs item #1530653, was opened at 2006-07-28 17:36 Message generated for change (Settings changed) made by vttoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1530653&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open >Resolution: Fixed Priority: 5 Submitted By: Michael Callaham (callaham) >Assigned to: Viktor Toth (vttoth) Summary: documentation for 'riemann' Initial Comment: In Maxima 5.9.3, in the ctensor package, describe(riemann); 2; prints: 8<- - - - - ... If the variable `cframe_flag' is `false', the Riemann tensor is computed directly from the Christoffel-symbols. If `cframe_flag' is `false', the covariant Riemann-tensor is computed first from the frame field coefficients. 8<- - - - - I think the second sentence should begin, If `cframe_flag' is `true', .... The same error appears in maxima.pdf. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1530653&group_id=4933 |
From: SourceForge.net <no...@so...> - 2006-07-29 15:36:17
|
Bugs item #928644, was opened at 2004-04-02 18:00 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=928644&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: None >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Ignacio Martinez (natacho) Assigned to: Robert Dodier (robert_dodier) Summary: installation fails: .mem not created by this vers of clisp Initial Comment: Hi, i install maxima buy it does not work imartinez@xp2400:~> maxima /usr/lib/clisp/base/lisp.run: initialization file `/usr/lib/maxima/5.9. 0/binary-clisp/maxima.mem' was not created by this version of CLISP Thanks ---------------------------------------------------------------------- >Comment By: Robert Dodier (robert_dodier) Date: 2006-07-29 09:36 Message: Logged In: YES user_id=501686 Well, as noted below this bug should now be impossible because Maxima packages a private copy of Clisp runtime. Be that as it may, I've also modified the maxima.spec file (rpm configuration) so that the maxima, maxima-exec, and other rpms all depend on specific version numbers. I hope that helps to prevent similar errors in the future. Closing this report as fixed. ---------------------------------------------------------------------- Comment By: Vadim V. Zhytnikov (vvzhy) Date: 2006-07-29 01:34 Message: Logged In: YES user_id=366498 I don't know why this bug is still open. Now Maxima package a private copy of clisp runtime during make install stage. This any other clisp versions should not affect Maxima installation. ---------------------------------------------------------------------- Comment By: Robert Dodier (robert_dodier) Date: 2005-04-16 01:20 Message: Logged In: YES user_id=501686 The Maxima rpms should have a dependency on the lisp version they were built with, so that the rpm can't be installed on a system which doesn't have the same Lisp type, or has the same type with a different version number. ---------------------------------------------------------------------- Comment By: Vadim V. Zhytnikov (vvzhy) Date: 2004-04-05 07:13 Message: Logged In: YES user_id=366498 Binaries compiled with diffrent version of CLISP usually are not compitible. You are trying to run Maxima buld with CLISP X on system with CLISP Y installed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=928644&group_id=4933 |
From: SourceForge.net <no...@so...> - 2006-07-29 11:28:54
|
Bugs item #1112532, was opened at 2005-01-30 06:40 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1112532&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: zeta declared posfun Initial Comment: The zeta function is declared to be a positive function (%i70) featurep(zeta,'posfun); (%o70) TRUE This isn't true--for example, zeta(-1) = -1/12. The bogus declaration is in the file compar.lisp. Barton ---------------------------------------------------------------------- >Comment By: Barton Willis (willisbl) Date: 2006-07-29 06:28 Message: Logged In: YES user_id=895922 Fixed with compar.lisp revision 1.12. Closing report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1112532&group_id=4933 |
From: SourceForge.net <no...@so...> - 2006-07-29 07:34:44
|
Bugs item #928644, was opened at 2004-04-03 01:00 Message generated for change (Comment added) made by vvzhy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=928644&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: None Status: Open Resolution: None Priority: 7 Submitted By: Ignacio Martinez (natacho) Assigned to: Robert Dodier (robert_dodier) Summary: installation fails: .mem not created by this vers of clisp Initial Comment: Hi, i install maxima buy it does not work imartinez@xp2400:~> maxima /usr/lib/clisp/base/lisp.run: initialization file `/usr/lib/maxima/5.9. 0/binary-clisp/maxima.mem' was not created by this version of CLISP Thanks ---------------------------------------------------------------------- >Comment By: Vadim V. Zhytnikov (vvzhy) Date: 2006-07-29 07:34 Message: Logged In: YES user_id=366498 I don't know why this bug is still open. Now Maxima package a private copy of clisp runtime during make install stage. This any other clisp versions should not affect Maxima installation. ---------------------------------------------------------------------- Comment By: Robert Dodier (robert_dodier) Date: 2005-04-16 07:20 Message: Logged In: YES user_id=501686 The Maxima rpms should have a dependency on the lisp version they were built with, so that the rpm can't be installed on a system which doesn't have the same Lisp type, or has the same type with a different version number. ---------------------------------------------------------------------- Comment By: Vadim V. Zhytnikov (vvzhy) Date: 2004-04-05 13:13 Message: Logged In: YES user_id=366498 Binaries compiled with diffrent version of CLISP usually are not compitible. You are trying to run Maxima buld with CLISP X on system with CLISP Y installed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=928644&group_id=4933 |
From: SourceForge.net <no...@so...> - 2006-07-29 06:53:15
|
Bugs item #1046737, was opened at 2004-10-13 19:48 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1046737&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Tests fail when run multiple times. Initial Comment: Version: Maxima 5.9.1 When I select "Run Tests" on the menu multiple times the results are different for selections after the first selection. First "Run Tests": no errors reported. Second "Run Tests": errors reported in some test cases. ---------------------------------------------------------------------- >Comment By: Robert Dodier (robert_dodier) Date: 2006-07-29 00:53 Message: Logged In: YES user_id=501686 Not observed in 5.9.3cvs. This problem was fixed a year or two ago by heavily revising kill. Closing this report as fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1046737&group_id=4933 |
From: SourceForge.net <no...@so...> - 2006-07-29 06:40:42
|
Bugs item #1045287, was opened at 2004-10-12 06:43 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1045287&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core Group: None Status: Open Resolution: None >Priority: 7 Submitted By: Alexander VIDYBIDA (vidybida) Assigned to: Nobody/Anonymous (nobody) Summary: FLOAT(EXP(EXP(2))) does not give a complete answer Initial Comment: Maxima version: 5.9.1 Maxima build date: 17:35 10/8/2004 host type: i586-pc-linux-gnu lisp-implementation-type: Kyoto Common Lisp lisp-implementation-version: GCL 2.6.5 (--enable-ansi) When applied to compositions like EXP(EXP(2)), or EXP(SIN(2)), the FLOAT() function seems unable to get a complete result. If we consider SIN(SIN(2)), or SIN(EXP(2)) instead, the result is complete. (%i1) float(EXP(EXP(2))); 2 %E (%o1) 2.718281828459045 (%i2) float(EXP(SIN(2))); SIN(2) (%o2) 2.718281828459045 (%i3) float(SIN(EXP(2))); (%o3) 0.89385495491281 (%i5) display2d:false$ (%i6) float(EXP(EXP(2))); (%o6) 2.718281828459045^%E^2 (%i7) float(EXP(SIN(2))); (%o7) 2.718281828459045^SIN(2) (%i8) float(SIN(EXP(2))); (%o8) 0.89385495491281 ---------------------------------------------------------------------- >Comment By: Robert Dodier (robert_dodier) Date: 2006-07-29 00:40 Message: Logged In: YES user_id=501686 Observed in 5.9.3cvs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1045287&group_id=4933 |
From: SourceForge.net <no...@so...> - 2006-07-29 06:37:42
|
Bugs item #993098, was opened at 2004-07-17 19:15 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=993098&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Marcus Christopher (elven6) Assigned to: Nobody/Anonymous (nobody) Summary: factor produces type-error and crashes Initial Comment: Working with Maxima 5.9.0.1, based on cmucl 18d, on SuSE Linux 9.1... ----- The following crashes the core: f(x,y) := ((x*y)^2 + x^2*2)^2 + (x + y^2)^2; factor(f(x, y)); (btw, I DO realize that the above term cannot be factorized without having been expanded.) The error looks like this: Type-error in KERNEL::OBJECT-NOT-FIXNUM-ERROR-HANDLER: NIL is not of type FIXNUM Restarts: 0: [MACSYMA-QUIT] Macsyma top-level 1: [ABORT ] Skip remaining initializations. Debug (type H for help) (KTERMS 2 2415061 NIL)[:EXTERNAL] Source: Error finding source: Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM: Source file no longer exists: /usr/src/redhat/BUILD/maxima-5.9.0/src/factor.lisp. ----- Note that the following works fine: f(x,y) := ((x*y)^2 + x^2)^2 + (x + y^2)^2; factor(f(x, y)); ...or... f(x,y) := ((x*y)^2 + x^2*2)^2; factor(f(x, y)); ---------------------------------------------------------------------- >Comment By: Robert Dodier (robert_dodier) Date: 2006-07-29 00:37 Message: Logged In: YES user_id=501686 Not observed in 5.9.3cvs / sbcl 0.9.9 / Linux. Closing this report as fixed per comments below. ---------------------------------------------------------------------- Comment By: Robert Dodier (robert_dodier) Date: 2004-10-13 21:50 Message: Logged In: YES user_id=501686 For what it's worth, I tried f(x,y) := ((x*y)^2 + x^2*2)^2 + (x + y^2)^2; factor(f(x, y)); in Maxima 5.9.1 (cmucl) and 5.9.0 (clisp) on Linux, and in both cases it succeeds and yields x^4*y^4+y^4+4*x^4*y^2+2*x*y^2+4*x^4+x^2 ---------------------------------------------------------------------- Comment By: Barton Willis (willisbl) Date: 2004-07-18 15:03 Message: Logged In: YES user_id=895922 I think this bug has been fixed; see bug 686619 http://sourceforge.net/tracker/index.php? func=detail&aid=686619&group_id=4933&atid=104933 Barton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=993098&group_id=4933 |
From: SourceForge.net <no...@so...> - 2006-07-29 06:31:51
|
Bugs item #955404, was opened at 2004-05-17 13:01 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=955404&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: mactex ignores aliases / FIX Initial Comment: Mactex ignores aliases; here is an example (%i1) ordergreat(a); (%o1) DONE (%i2) tex(a); $$_101a\leqno{\tt NIL}$$ (%o2) NIL (%i3) build_info(); Maxima version: 5.9.0.1cvs Maxima build date: 12:29 5/12/2004 host type: i686-pc-mingw32 lisp-implementation-type: Kyoto Common Lisp lisp-implementation-version: GCL 2.7.0 Here is one way fix this bug; change tex-atom to (defun tex-atom (x l r) ;; atoms: note: can we lose by leaving out {}s ? (if (symbolp x) (setq x (or (get x 'reversealias) x))) (append l (list (cond ((numberp x) (texnumformat x)) ((and (symbolp x) (get x 'texword))) ((stringp x) (tex-string x)) ((characterp x) (tex-char x)) (t (tex-stripdollar x)))) r)) Testing ... (%o3) (%i4) load("c:/maximacvs/maxima/src/mactex.lisp"); (%o4) c:/maximacvs/maxima/src/mactex.lisp (%i5) tex(a); $$a\leqno{\tt NIL}$$ (%o5) NIL (%i6) Ordergreat isn't all that useful, but it is a good way to change the ordering of an expression to something more standard for typesetting. Barton ---------------------------------------------------------------------- >Comment By: Robert Dodier (robert_dodier) Date: 2006-07-29 00:31 Message: Logged In: YES user_id=501686 Observed in 5.9.3cvs. ---------------------------------------------------------------------- Comment By: Barton Willis (willisbl) Date: 2004-11-23 10:19 Message: Logged In: YES user_id=895922 I can't think of any reason to not apply it---I've used the patch a few times to help tidy tex output. For this purpose, it doesn't work all that well. Say I want all x's before y's. Using ordergreat works in a sum, but not in a product (%i1) x+y+x*y; (%o1) x y + y + x (%i2) ordergreat(x,y,z); (%o2) done (%i3) x+y+x*y; (%o3) y x + x + y (The funny \leqno{\tt ...} stuff in my first posting was due to a mactex bug that is no longer with us, I think). Barton ---------------------------------------------------------------------- Comment By: Raymond Toy (rtoy) Date: 2004-11-23 09:02 Message: Logged In: YES user_id=28849 Is there a reason not to apply this fix? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=955404&group_id=4933 |
From: SourceForge.net <no...@so...> - 2006-07-29 06:30:19
|
Bugs item #951388, was opened at 2004-05-10 10:58 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=951388&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core Group: None Status: Open Resolution: None >Priority: 3 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: inchar: "string"; inchar: 9 Initial Comment: inchar:"q"$ (q28) foo$ (q29) q28; => q28 (q30) "q28" => foo !!! It has assigned a value to a string, which is illegal: (q31) "q28": 234234; => improper value assignment especially amusing if you assign inchar:"".... inchar also allows itself to be assigned a number: inchar:"9" (932) foo$ (933) ?\932; => foo ---------------------------------------------------------------------- >Comment By: Robert Dodier (robert_dodier) Date: 2006-07-29 00:30 Message: Logged In: YES user_id=501686 Observed in 5.9.3cvs. Although the final example is: (%i1) inchar:"9"; (%o1) 9 (92) foo; (%o2) foo (93) "914"; (%o3) 914 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=951388&group_id=4933 |
From: SourceForge.net <no...@so...> - 2006-07-29 06:27:45
|
Bugs item #947808, was opened at 2004-05-04 10:15 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=947808&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core - Simplification Group: None Status: Open Resolution: None Priority: 3 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: logcontract and ratfac Initial Comment: logcontract(2*log(x+1)) => log((x+1)^2) but logcontract(2*log(x+1)+1) => log(x^2+2*x+1)+1 That is, it performs a ratsimp only in the second case. logcontract is documented to perform the ratsimp, in fact. But in general, it doesn't seem like a good idea. Consider, e.g. logcontract(1000*log(x+1)+log(x)). This stack-overflows since it expands out the result, but it could just as well return log((x+1)^1000*x). There is a workaround, which is to bind ratfac to true, which leaves things in factored form. Perhaps logcontract should always have ratfac:true? ---------------------------------------------------------------------- >Comment By: Robert Dodier (robert_dodier) Date: 2006-07-29 00:27 Message: Logged In: YES user_id=501686 Same behavior in 5.9.3cvs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=947808&group_id=4933 |
From: SourceForge.net <no...@so...> - 2006-07-29 06:25:56
|
Bugs item #944743, was opened at 2004-04-29 12:03 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=944743&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: poly_discriminant with ratfac == true / FIX Initial Comment: When ratfac == true, poly_discriminant often incorrectly determines that the first argument is non-polynomial; for example (C1) ratfac : true$ (C2) poly_discriminant((x-1)*(x-2),x); ARG. MUST BE A POLYNOMIAL IN VAR -- an error. Quitting. To debug this try DEBUGMODE (TRUE);) Additionally, (1) The error message is silly. (2) The function poly_discriminant isn't documented. (3) What other functions misbehave when ratfac == true? A simple fix is (DEFMFUN $POLY_DISCRIMINANT (POLY VAR) (LET* ((VARLIST (LIST VAR)) ($ratfac nil) (GENVAR ()) (RFORM (RFORM ($rat POLY var))) (RVAR (CAR (LAST GENVAR))) (N (PDEGREE (SETQ POLY (CAR RFORM)) RVAR))) (COND ((= N 1) 1) ((OR (= N 0) (NOT (atom (CDR RFORM)))) (MERROR "The first argument must be a polynomial in ~:M" var)) (T (PDIS (PRESIGN (// (f* N (f1- N)) 2) (PQUOTIENT (RESULTANT POLY (PDERIVATIVE POLY RVAR)) (P-LC POLY)))))))) Barton ---------------------------------------------------------------------- >Comment By: Robert Dodier (robert_dodier) Date: 2006-07-29 00:25 Message: Logged In: YES user_id=501686 Observed in 5.9.3cvs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=944743&group_id=4933 |
From: SourceForge.net <no...@so...> - 2006-07-29 06:20:06
|
Bugs item #940835, was opened at 2004-04-23 10:08 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=940835&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core - Complex Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: rectform fails with float/numer flags Initial Comment: rectform(log(-%i)) => -%i*%pi/2 OK float(rectform(log(-%i))) => -1.57 * %i OK rectform(log(-%i)),numer => 4.71 * %i NO! rectform(log(-%i)),float => fatal error The problem is the function 2pistrip. ---------------------------------------------------------------------- >Comment By: Robert Dodier (robert_dodier) Date: 2006-07-29 00:20 Message: Logged In: YES user_id=501686 In 5.9.3cvs: rectform(log(-%i)),numer; => - 1.570796326794897 %i (OK) rectform(log(-%i)),float; => 1.5 %i %pi (OOPS) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=940835&group_id=4933 |
From: SourceForge.net <no...@so...> - 2006-07-29 06:14:40
|
Bugs item #938134, was opened at 2004-04-19 14:00 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=938134&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core - Complex Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: diff(realpart) bogus Initial Comment: declare(z,complex)$ diff(realpart(z),z) => realpart(1) ?!?! Realpart is nowhere differentiable! ---------------------------------------------------------------------- >Comment By: Robert Dodier (robert_dodier) Date: 2006-07-29 00:14 Message: Logged In: YES user_id=501686 Observed in 5.9.3cvs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=938134&group_id=4933 |
From: SourceForge.net <no...@so...> - 2006-07-29 06:13:55
|
Bugs item #935030, was opened at 2004-04-14 10:17 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=935030&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core - Simplification Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: ratsimp with algebraic == true Initial Comment: With algebraic == true, ratsimp doesn't fully simplify some expressions. Here is an example (C1) display2d : false$ (C2) algebraic : true$ (C3) integrate(1/(2+x^3),x)$ (C4) ratsimp(diff(%,x)); (D4) 4*2^(2/3)/(4*2^(2/3)*x^3+8*2^(2/3)) (C5) ratsimp(%); (D5) 1/(x^3+2) Maybe this is the purpose of fullratsimp, but it seems odd that ratsimp fails to cancel the factor of 2^(2/3). I discovered this when I ran run_testsuite with algebraic == true. (C6) build_info(); Maxima version: 5.9.0.1cvs Maxima build date: 7:58 4/5/2004 host type: i686-pc-mingw32 lisp-implementation-type: Kyoto Common Lisp lisp-implementation-version: GCL 2.7.0 Barton ---------------------------------------------------------------------- >Comment By: Robert Dodier (robert_dodier) Date: 2006-07-29 00:13 Message: Logged In: YES user_id=501686 Observed in 5.9.3cvs. ---------------------------------------------------------------------- Comment By: Stavros Macrakis (macrakis) Date: 2004-04-19 13:55 Message: Logged In: YES user_id=588346 Though this is annoying and surprising, it *is* documented: >>>>>>>>>(fullratsimp) When non-rational expressions are involved, one call to RATSIMP followed as is usual by non-rational ("general") simplification may not be sufficient to return a simplified result. <<<<<<<<< Also, the algebraic flag only changes the behavior with gcd=spmod. With gcd=subres (the default), you need two ratsimp's regardless of the setting of algebraic. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=935030&group_id=4933 |
From: SourceForge.net <no...@so...> - 2006-07-29 06:12:58
|
Bugs item #932395, was opened at 2004-04-09 11:17 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=932395&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: solve confused by ratvars Initial Comment: solve(rat(a+c,a,b,c,d),[a,b]) => [[a=-%r1, b=%r1]] NO! Remove the extra variable: solve(rat(a+c,a,b,c),[a,b]) => [[a = - c, b = %r2]] OK Also works fine if you call algsys directly: algsys([rat(a+c,a,b,c,d)],[a,b]); At first I thought this had something to do with the variable *ordering* in the first case, but in fact it happens with all orderings. The problem is the number of ratvars. Note that this is *not* an artificial situation. It is common to have CREs with more ratvars than they use after arithmetic operations, e.g. rat(a+b)-rat(a). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=932395&group_id=4933 |