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}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 






1

2
(2) 
3
(1) 
4

5
(2) 
6
(2) 
7

8
(2) 
9

10

11

12
(1) 
13
(2) 
14
(2) 
15
(1) 
16

17
(4) 
18
(7) 
19
(1) 
20
(1) 
21

22
(4) 
23

24
(2) 
25
(7) 
26

27

28
(3) 
29
(8) 
30
(1) 
31
(4) 






From: SourceForge.net <noreply@so...>  20110731 18:47:10

Bugs item #3377320, was opened at 20110725 10: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=3377320&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: Includes proposed fix >Status: Closed >Resolution: Fixed Priority: 1 Private: No Submitted By: Andrew Kovalev (aakov) Assigned to: Nobody/Anonymous (nobody) Summary: ezuints  wrong unit for Loschmidt constant Initial Comment: Proper unit should be 1/(m^3), not m^3. Although the mistake is small and noncritical, Maxima not need it.  >Comment By: Robert Dodier (robert_dodier) Date: 20110731 12:47 Message: Changed units to 1/m^3 as suggested. Committed as ab86cb42e5e85ae6c90c06ab35cd72e646c5f259 in Git. Thanks to Andrew for pointing out the problem. Closing this report as fixed.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3377320&group_id=4933 
From: SourceForge.net <noreply@so...>  20110731 18:35:05

Bugs item #3383300, was opened at 20110731 12:28 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3383300&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 Private: No Submitted By: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: stack overflow on floor of expression containing log(1) Initial Comment: I find that this: floor (log (2^(floor (log ( 1))  1)  1)); causes a stack overflow. Happens w/ current Git Maxima + Clisp and SBCL. Some similar examples just take a while to run to completion  maybe it is not an unbounded recursion, but rather a problem that could be solved by using a bigger stack. I didn't investigate that. That is the simplest example I could find  removing some of the bits makes it run to completion.  Comment By: Robert Dodier (robert_dodier) Date: 20110731 12:35 Message: Problem originated here: http://stackoverflow.com/questions/6808077/  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3383300&group_id=4933 
From: SourceForge.net <noreply@so...>  20110731 18:28:26

Bugs item #3383300, was opened at 20110731 12:28 Message generated for change (Tracker Item Submitted) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3383300&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 Private: No Submitted By: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: stack overflow on floor of expression containing log(1) Initial Comment: I find that this: floor (log (2^(floor (log ( 1))  1)  1)); causes a stack overflow. Happens w/ current Git Maxima + Clisp and SBCL. Some similar examples just take a while to run to completion  maybe it is not an unbounded recursion, but rather a problem that could be solved by using a bigger stack. I didn't investigate that. That is the simplest example I could find  removing some of the bits makes it run to completion.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3383300&group_id=4933 
From: SourceForge.net <noreply@so...>  20110731 18:15:39

Bugs item #3374715, was opened at 20110722 08:01 Message generated for change (Settings changed) made by riotorto You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3374715&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: yuihji () Assigned to: Nobody/Anonymous (nobody) Summary: a wrong display of the line number in the manual Initial Comment: i found it in the pdf manual , and the same in the online manual . in this page http://maxima.sourceforge.net/docs/manual/en/maxima_4.html#SEC10 , the 4th example of section " Operator: '' " : (%i3) dispfun (foo_1a, foo_1b); (%t3) foo_1a(x) := x log(x)  x (%t4) foo_1b(x) := integrate(log(x), x) (%o4) [%t3, %t4] (%i4) integrate (log (x), x); (%o4) x log(x)  x (%i5) foo_2a (x) := ''%; (%o5) foo_2a(x) := x log(x)  x after the 1st (%o4) , there should be a (%i5) not a (%i4) . and there are some similar mistakes.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3374715&group_id=4933 
From: SourceForge.net <noreply@so...>  20110730 02:14:24

Bugs item #3382358, was opened at 20110729 13:29 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3382358&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  Integration Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: integrating function with signum incorrect Initial Comment: In Maxima 5.24.0: (%i11) integrate(x*signum(x^21/4),x,1,0); 1 (%o11)  2 But the picture makes it pretty clear this should be 1/4. Is this antideriv ok? (%i15) integrate(x*signum(x^21/4),x); ! 2 1! !x  ! ! 4! (%o15)  2 This was originally reported at the Sage trac at http://trac.sagemath.org/sage_trac/ticket/11590  >Comment By: Barton Willis (willisbl) Date: 20110729 21:14 Message: By the way: (%i4) load(abs_integrate)$ Correct antiderivative: (%i5) 'integrate(x*signum(x^21/4),x); (%o5) abs(x^21/4)/2 Correct definite integral (%i6) 'integrate(x*signum(x^21/4),x,1,0); (%o6) 1/4  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3382358&group_id=4933 
From: SourceForge.net <noreply@so...>  20110729 18:29:47

Bugs item #3382358, was opened at 20110729 18:29 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3382358&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  Integration Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: integrating function with signum incorrect Initial Comment: In Maxima 5.24.0: (%i11) integrate(x*signum(x^21/4),x,1,0); 1 (%o11)  2 But the picture makes it pretty clear this should be 1/4. Is this antideriv ok? (%i15) integrate(x*signum(x^21/4),x); ! 2 1! !x  ! ! 4! (%o15)  2 This was originally reported at the Sage trac at http://trac.sagemath.org/sage_trac/ticket/11590  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3382358&group_id=4933 
From: SourceForge.net <noreply@so...>  20110729 12:53:26

Bugs item #3381301, was opened at 20110728 14:31 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3381301&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  Floating point Group: None Status: Open Resolution: None Priority: 1 Private: No Submitted By: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: log(1.0b0) has small realpart Initial Comment: The result of log(1.0b0) has a small realpart within the numerical precision. To be more consistent with log(1.0b0) >0.0b0 I think the small realpart should be omitted. Maxima version: 5.24post Maxima build date: 20:27 7/28/2011 Host type: i686pclinuxgnu Lisp implementation type: SBCL Lisp implementation version: 1.0.45 (%i2) log(1.0b0); (%o2) 3.141592653589793b0*%i1.084202172485504b19 Dieter Kaiser  >Comment By: Barton Willis (willisbl) Date: 20110729 07:53 Message: Using Clozure CL, I get the same three test failures.  Comment By: Dieter Kaiser (crategus) Date: 20110729 06:08 Message: With the proposed change I get the desired result for log(1.0b0) > 3.141592653589793b0 %i. With SBCL I get three changes in the testsuite. I have not looked at the examples in detail, but it seems to me that failures are due to a slightly loss of accuracy in the numerical calculation of special functions. Perhaps the results have changed only within the predictable accuracy. Because we have no checks in the testsite for the numerical precision of the log function, it might be difficult to say if there is a small problem in the bigfloat package. At the end, it would be nice if we can implement one scheme of numerical evaluation, or if both available schemes give equivalent results. These are the changed results: Running tests in rtest15: ********************** Problem 233 *************** Input: ev(Y1, numer) Result: [.1601071267287311, .3182173976481846, .6792822087245607,  .2554475201086612, .4550000458216386, 1.513096652187913, 1.631906796078438, 1.153564994895108,  1.9459101, .9354375628925464, 6.548062940247827, 1.427448757889531 %i, .1438410362258904  1.570796326794897 %i, 2.644120761058629, 2.633915793849634, .1423756431678044, .1438410362258905, 1.010221447322645, 7.047554385466547, 6.976247043798604, .9898819735517056, .1433435475724631, .1418931937669325, .3779644730092272, 1.427448757889531, 1.428899272190733, 1.570796326794897  2.633915793849634 %i, 2.633915793849634 %i, .1433475689053653, .1418970546041639, .9898132604466151, 6.952316038379696, 7.023866335396166, 1.010291577169605, .1423717297922636, .1438369594361909, .1541506798272584, .1483117974987926, .1455231696984896,  7.363980242224349, 50.3574714369117,  687.6815220686585] This differed from the expected result: [0.16010712672873, 0.31821739764818, 0.67928220872456,  0.25544752010866, 0.45500004582164, 1.513096652187913, 1.631906796078438, 1.153564994895108,  1.945910149055313, 0.93543756289255, 6.548062940247834, 1.427448757889531 %i, 0.14384103622589  1.570796326794897 %i, 2.644120761058629, 2.633915793849633, 0.1423756431678, 0.14384103622589, 1.010221447322645, 7.047554385466551, 6.976247043798608, 0.98988197355171, 0.14334354757246, 0.14189319376693, 0.37796447300923, 1.427448757889531, 1.428899272190733, 1.570796326794897  2.633915793849634 %i, 2.633915793849634 %i, 0.14334756890537, 0.14189705460416, 0.98981326044662, 6.952316038379697, 7.023866335396166, 1.010291577169605, 0.14237172979226, 0.14383695943619, 0.15415067982726, 0.14831179749879, 0.14552316969849,  7.363980242224349, 50.3574714369117,  687.6815220686585] 251/252 tests passed The following 1 problem failed: (233) Running tests in rtest_gamma: ********************** Problem 654 *************** Input: 1 beta_incomplete(1.0b0, 2, ) 2 Result: 3.750000000000002b1 This differed from the expected result: 3.75b1 702/703 tests passed (not counting 2 expected errors) The following 1 problem failed: (654) Running tests in rtest_expintegral: ********************** Problem 66 *************** Input: ev(test_value(%, expintegral_e(3, 0.5), 15), numer) Result: 1.190408882578708e10 and 5.463923757886846e9 This differed from the expected result: true 184/185 tests passed The following 1 problem failed: (66) Dieter Kaiser  Comment By: Barton Willis (willisbl) Date: 20110729 05:14 Message: Correction: ((and (complexnumberp y #'mnump) (or $numer (not (complexnumberp y #'$ratnump)))) (maxima::to (bigfloat::log (bigfloat::to y))))  Comment By: Barton Willis (willisbl) Date: 20110728 22:39 Message: rest_log #11 is a known failure: Running tests in rtest_log: ********************** Problem 11 *************** Input: log( 1.0b0)  bfloat(%i %pi) Inserting ((or (complexnumberp y #'(lambda(s) (or (floatp s) ($bfloatp s)))) (and $numer (complexnumberp y #'mnump))) (maxima::to (bigfloat::log (bigfloat::to y)))) into simpln fixes this bug, and it changes some expected results.  Comment By: Barton Willis (willisbl) Date: 20110728 21:38 Message: The bigfloat package handles this better: MAXIMA> (bigfloat::log (bigfloat::to (maxima::meval '$x))) +0.0b0+3.141592653589793b0*%i Would it be possible to use the bigfloat package in simpln?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3381301&group_id=4933 
From: SourceForge.net <noreply@so...>  20110729 11:08:27

Bugs item #3381301, was opened at 20110728 21:31 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3381301&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  Floating point Group: None Status: Open Resolution: None Priority: 1 Private: No Submitted By: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: log(1.0b0) has small realpart Initial Comment: The result of log(1.0b0) has a small realpart within the numerical precision. To be more consistent with log(1.0b0) >0.0b0 I think the small realpart should be omitted. Maxima version: 5.24post Maxima build date: 20:27 7/28/2011 Host type: i686pclinuxgnu Lisp implementation type: SBCL Lisp implementation version: 1.0.45 (%i2) log(1.0b0); (%o2) 3.141592653589793b0*%i1.084202172485504b19 Dieter Kaiser  >Comment By: Dieter Kaiser (crategus) Date: 20110729 13:08 Message: With the proposed change I get the desired result for log(1.0b0) > 3.141592653589793b0 %i. With SBCL I get three changes in the testsuite. I have not looked at the examples in detail, but it seems to me that failures are due to a slightly loss of accuracy in the numerical calculation of special functions. Perhaps the results have changed only within the predictable accuracy. Because we have no checks in the testsite for the numerical precision of the log function, it might be difficult to say if there is a small problem in the bigfloat package. At the end, it would be nice if we can implement one scheme of numerical evaluation, or if both available schemes give equivalent results. These are the changed results: Running tests in rtest15: ********************** Problem 233 *************** Input: ev(Y1, numer) Result: [.1601071267287311, .3182173976481846, .6792822087245607,  .2554475201086612, .4550000458216386, 1.513096652187913, 1.631906796078438, 1.153564994895108,  1.9459101, .9354375628925464, 6.548062940247827, 1.427448757889531 %i, .1438410362258904  1.570796326794897 %i, 2.644120761058629, 2.633915793849634, .1423756431678044, .1438410362258905, 1.010221447322645, 7.047554385466547, 6.976247043798604, .9898819735517056, .1433435475724631, .1418931937669325, .3779644730092272, 1.427448757889531, 1.428899272190733, 1.570796326794897  2.633915793849634 %i, 2.633915793849634 %i, .1433475689053653, .1418970546041639, .9898132604466151, 6.952316038379696, 7.023866335396166, 1.010291577169605, .1423717297922636, .1438369594361909, .1541506798272584, .1483117974987926, .1455231696984896,  7.363980242224349, 50.3574714369117,  687.6815220686585] This differed from the expected result: [0.16010712672873, 0.31821739764818, 0.67928220872456,  0.25544752010866, 0.45500004582164, 1.513096652187913, 1.631906796078438, 1.153564994895108,  1.945910149055313, 0.93543756289255, 6.548062940247834, 1.427448757889531 %i, 0.14384103622589  1.570796326794897 %i, 2.644120761058629, 2.633915793849633, 0.1423756431678, 0.14384103622589, 1.010221447322645, 7.047554385466551, 6.976247043798608, 0.98988197355171, 0.14334354757246, 0.14189319376693, 0.37796447300923, 1.427448757889531, 1.428899272190733, 1.570796326794897  2.633915793849634 %i, 2.633915793849634 %i, 0.14334756890537, 0.14189705460416, 0.98981326044662, 6.952316038379697, 7.023866335396166, 1.010291577169605, 0.14237172979226, 0.14383695943619, 0.15415067982726, 0.14831179749879, 0.14552316969849,  7.363980242224349, 50.3574714369117,  687.6815220686585] 251/252 tests passed The following 1 problem failed: (233) Running tests in rtest_gamma: ********************** Problem 654 *************** Input: 1 beta_incomplete(1.0b0, 2, ) 2 Result: 3.750000000000002b1 This differed from the expected result: 3.75b1 702/703 tests passed (not counting 2 expected errors) The following 1 problem failed: (654) Running tests in rtest_expintegral: ********************** Problem 66 *************** Input: ev(test_value(%, expintegral_e(3, 0.5), 15), numer) Result: 1.190408882578708e10 and 5.463923757886846e9 This differed from the expected result: true 184/185 tests passed The following 1 problem failed: (66) Dieter Kaiser  Comment By: Barton Willis (willisbl) Date: 20110729 12:14 Message: Correction: ((and (complexnumberp y #'mnump) (or $numer (not (complexnumberp y #'$ratnump)))) (maxima::to (bigfloat::log (bigfloat::to y))))  Comment By: Barton Willis (willisbl) Date: 20110729 05:39 Message: rest_log #11 is a known failure: Running tests in rtest_log: ********************** Problem 11 *************** Input: log( 1.0b0)  bfloat(%i %pi) Inserting ((or (complexnumberp y #'(lambda(s) (or (floatp s) ($bfloatp s)))) (and $numer (complexnumberp y #'mnump))) (maxima::to (bigfloat::log (bigfloat::to y)))) into simpln fixes this bug, and it changes some expected results.  Comment By: Barton Willis (willisbl) Date: 20110729 04:38 Message: The bigfloat package handles this better: MAXIMA> (bigfloat::log (bigfloat::to (maxima::meval '$x))) +0.0b0+3.141592653589793b0*%i Would it be possible to use the bigfloat package in simpln?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3381301&group_id=4933 
From: SourceForge.net <noreply@so...>  20110729 11:01:20

Bugs item #3381037, was opened at 20110728 10:08 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3381037&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  Integration Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: integrate(log(2*sin(t/2)),t,0,%pi) contains false Initial Comment: Maxima version: 5.24post Maxima build date: 14:8 7/28/2011 Host type: i686pclinuxgnu Lisp implementation type: SBCL Lisp implementation version: 1.0.45 (%i2) integrate(log(2*sin(t/2)),t,0,%pi); (%o2) 2*(false+%pi*log(2)/2) The result should be 0. I have not verified the result for the indefinite integral: (%i3) integrate(log(2*sin(t/2)),t); (%o3) 2*(t*log(2*sin(t/2))/2(t*log(sin(t/2)^2+cos(t/2)^2+2*cos(t/2)+1)/2 +t*log(sin(t/2)^2+cos(t/2)^22*cos(t/2)+1)/2 +%i*t*atan2(sin(t/2),cos(t/2)+1) %i*t*atan2(sin(t/2),1cos(t/2)) 2*%i*li[2](%e^(%i*t/2))2*%i*li[2](%e^(%i*t/2)) %i*t^2/4) /2) Dieter Kaiser  >Comment By: Barton Willis (willisbl) Date: 20110729 06:01 Message: might be related to this bug: (%i8) t * atan2(sin(t/2),1cos(t/2)); (%o8) t*atan2(sin(t/2),1cos(t/2)) (%i9) limit(%,t,0); atan2: atan2(0,0) is undefined.  an error. To debug this try: debugmode(true);  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3381037&group_id=4933 
From: SourceForge.net <noreply@so...>  20110729 10:21:58

Bugs item #3382008, was opened at 20110729 12:21 Message generated for change (Tracker Item Submitted) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3382008&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: Open Resolution: None Priority: 1 Private: No Submitted By: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: Definition of simpisrealp is duplicated Initial Comment: The definition of the function simpisrealp is duplicated. The function is defined in topoly.lisp and in to_poly_solve_extra.lisp. The definitions are identical. At least, with SBCL this gives a warning when loading to_poly_solver. It is not a real problem, but a user might be irritated that something goes wrong when reading the warning from the compiler. It seems to be no problem to cut out the second definition in to_poly_solve_extra.lisp, because topoly.lisp is loaded first. By the way, it would be nice to have a separate directory for the code and the documentation for to_poly_solver. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3382008&group_id=4933 
From: SourceForge.net <noreply@so...>  20110729 10:14:34

Bugs item #3381301, was opened at 20110728 14:31 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3381301&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  Floating point Group: None Status: Open Resolution: None Priority: 1 Private: No Submitted By: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: log(1.0b0) has small realpart Initial Comment: The result of log(1.0b0) has a small realpart within the numerical precision. To be more consistent with log(1.0b0) >0.0b0 I think the small realpart should be omitted. Maxima version: 5.24post Maxima build date: 20:27 7/28/2011 Host type: i686pclinuxgnu Lisp implementation type: SBCL Lisp implementation version: 1.0.45 (%i2) log(1.0b0); (%o2) 3.141592653589793b0*%i1.084202172485504b19 Dieter Kaiser  >Comment By: Barton Willis (willisbl) Date: 20110729 05:14 Message: Correction: ((and (complexnumberp y #'mnump) (or $numer (not (complexnumberp y #'$ratnump)))) (maxima::to (bigfloat::log (bigfloat::to y))))  Comment By: Barton Willis (willisbl) Date: 20110728 22:39 Message: rest_log #11 is a known failure: Running tests in rtest_log: ********************** Problem 11 *************** Input: log( 1.0b0)  bfloat(%i %pi) Inserting ((or (complexnumberp y #'(lambda(s) (or (floatp s) ($bfloatp s)))) (and $numer (complexnumberp y #'mnump))) (maxima::to (bigfloat::log (bigfloat::to y)))) into simpln fixes this bug, and it changes some expected results.  Comment By: Barton Willis (willisbl) Date: 20110728 21:38 Message: The bigfloat package handles this better: MAXIMA> (bigfloat::log (bigfloat::to (maxima::meval '$x))) +0.0b0+3.141592653589793b0*%i Would it be possible to use the bigfloat package in simpln?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3381301&group_id=4933 
From: SourceForge.net <noreply@so...>  20110729 03:39:49

Bugs item #3381301, was opened at 20110728 14:31 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3381301&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  Floating point Group: None Status: Open Resolution: None Priority: 1 Private: No Submitted By: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: log(1.0b0) has small realpart Initial Comment: The result of log(1.0b0) has a small realpart within the numerical precision. To be more consistent with log(1.0b0) >0.0b0 I think the small realpart should be omitted. Maxima version: 5.24post Maxima build date: 20:27 7/28/2011 Host type: i686pclinuxgnu Lisp implementation type: SBCL Lisp implementation version: 1.0.45 (%i2) log(1.0b0); (%o2) 3.141592653589793b0*%i1.084202172485504b19 Dieter Kaiser  >Comment By: Barton Willis (willisbl) Date: 20110728 22:39 Message: rest_log #11 is a known failure: Running tests in rtest_log: ********************** Problem 11 *************** Input: log( 1.0b0)  bfloat(%i %pi) Inserting ((or (complexnumberp y #'(lambda(s) (or (floatp s) ($bfloatp s)))) (and $numer (complexnumberp y #'mnump))) (maxima::to (bigfloat::log (bigfloat::to y)))) into simpln fixes this bug, and it changes some expected results.  Comment By: Barton Willis (willisbl) Date: 20110728 21:38 Message: The bigfloat package handles this better: MAXIMA> (bigfloat::log (bigfloat::to (maxima::meval '$x))) +0.0b0+3.141592653589793b0*%i Would it be possible to use the bigfloat package in simpln?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3381301&group_id=4933 
From: SourceForge.net <noreply@so...>  20110729 02:38:05

Bugs item #3381301, was opened at 20110728 14:31 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3381301&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  Floating point Group: None Status: Open Resolution: None Priority: 1 Private: No Submitted By: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: log(1.0b0) has small realpart Initial Comment: The result of log(1.0b0) has a small realpart within the numerical precision. To be more consistent with log(1.0b0) >0.0b0 I think the small realpart should be omitted. Maxima version: 5.24post Maxima build date: 20:27 7/28/2011 Host type: i686pclinuxgnu Lisp implementation type: SBCL Lisp implementation version: 1.0.45 (%i2) log(1.0b0); (%o2) 3.141592653589793b0*%i1.084202172485504b19 Dieter Kaiser  >Comment By: Barton Willis (willisbl) Date: 20110728 21:38 Message: The bigfloat package handles this better: MAXIMA> (bigfloat::log (bigfloat::to (maxima::meval '$x))) +0.0b0+3.141592653589793b0*%i Would it be possible to use the bigfloat package in simpln?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3381301&group_id=4933 
From: SourceForge.net <noreply@so...>  20110728 19:31:39

Bugs item #3381301, was opened at 20110728 21:31 Message generated for change (Tracker Item Submitted) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3381301&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  Floating point Group: None Status: Open Resolution: None Priority: 1 Private: No Submitted By: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: log(1.0b0) has small realpart Initial Comment: The result of log(1.0b0) has a small realpart within the numerical precision. To be more consistent with log(1.0b0) >0.0b0 I think the small realpart should be omitted. Maxima version: 5.24post Maxima build date: 20:27 7/28/2011 Host type: i686pclinuxgnu Lisp implementation type: SBCL Lisp implementation version: 1.0.45 (%i2) log(1.0b0); (%o2) 3.141592653589793b0*%i1.084202172485504b19 Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3381301&group_id=4933 
From: SourceForge.net <noreply@so...>  20110728 15:08:54

Bugs item #3381037, was opened at 20110728 17:08 Message generated for change (Tracker Item Submitted) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3381037&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  Integration Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: integrate(log(2*sin(t/2)),t,0,%pi) contains false Initial Comment: Maxima version: 5.24post Maxima build date: 14:8 7/28/2011 Host type: i686pclinuxgnu Lisp implementation type: SBCL Lisp implementation version: 1.0.45 (%i2) integrate(log(2*sin(t/2)),t,0,%pi); (%o2) 2*(false+%pi*log(2)/2) The result should be 0. I have not verified the result for the indefinite integral: (%i3) integrate(log(2*sin(t/2)),t); (%o3) 2*(t*log(2*sin(t/2))/2(t*log(sin(t/2)^2+cos(t/2)^2+2*cos(t/2)+1)/2 +t*log(sin(t/2)^2+cos(t/2)^22*cos(t/2)+1)/2 +%i*t*atan2(sin(t/2),cos(t/2)+1) %i*t*atan2(sin(t/2),1cos(t/2)) 2*%i*li[2](%e^(%i*t/2))2*%i*li[2](%e^(%i*t/2)) %i*t^2/4) /2) Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3381037&group_id=4933 
From: SourceForge.net <noreply@so...>  20110728 14:36:57

Bugs item #3381012, was opened at 20110728 16:36 Message generated for change (Tracker Item Submitted) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3381012&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  Integration Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: integrate(log(t)*log(t+1),t,0,1) gives Lisp error Initial Comment: integrate(log(t)*log(t+1),t,0,1) does not work in Maxima 5.24: Maxima version: 5.24.0 Maxima build date: 22:5 4/26/2011 Host type: i686pclinuxgnu Lisp implementation type: SBCL Lisp implementation version: 1.0.45 (%i2) integrate(log(t)*log(t+1),t,0,1); Maxima encountered a Lisp error: The value YX is not of type LIST. Automatically continuing. To enable the Lisp debugger set *debuggerhook* to nil. Maxima 5.23 gives a correct result: Maxima version: 5.23.2 Maxima build date: 20:6 4/3/2011 Host type: i686pclinuxgnu Lisp implementation type: SBCL Lisp implementation version: 1.0.45 (%i2) integrate(log(t)*log(t+1),t,0,1); (%o2) 2*log(2)%pi^2/12+2 Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3381012&group_id=4933 
From: SourceForge.net <noreply@so...>  20110725 21:01:03

Bugs item #3377347, was opened at 20110725 12:21 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3377347&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: 6 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: log(1/(1+%i)) gives error Initial Comment: log(1/(1+%i)); sign: argument cannot be imaginary; found %i  an error. Error comes from simpln. Looks like simpln needs to bind *complexsign* to T and do something intelligent....  >Comment By: Barton Willis (willisbl) Date: 20110725 16:01 Message: Changing $sign to $csign (two places?) might be all that is needed to fix this.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3377347&group_id=4933 
From: SourceForge.net <noreply@so...>  20110725 18:04:41

Bugs item #3377380, was opened at 20110725 14:04 Message generated for change (Tracker Item Submitted) made by dloksnel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3377380&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  Solving equations Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Art Lenskold (dloksnel) Assigned to: Nobody/Anonymous (nobody) Summary: 7 nested levels Initial Comment: solve([0=x^21+(a(tx)*(t+1/(2*((tx)^2+(bsqrt(1x^2))^2))*(2(b*xt*sqrt(1x^2))*(bsqrt(1x^2))2*(x^2*(b^2t^2)*(x^22+2*t*xt^2)+t^2*(x^2+b^21)(2*t*xx^2)*(1+b^2+t^22*t*x)2*b*sqrt(1x^2)*((tx)^2+t*x*(x^2+2*t*xt^22)))^(1/2)))^1*(a+(11/(4*((tx)^2+(bsqrt(1x^2))^2)^2)*(4*(b*xt*sqrt(1x^2))^2*(bsqrt(1x^2))^28*(x^2*(b^2t^2)*(x^22+2*t*xt^2)+t^2*(x^2+b^21)(2*t*xx^2)*(1+b^2+t^22*t*x)2*b*sqrt(1x^2)*((tx)^2+t*x*(x^2+2*t*xt^22)))^(1/2)*(b*xt*sqrt(1x^2))*(bsqrt(1x^2))+4*(x^2*(b^2t^2)*(x^22+2*t*xt^2)+t^2*(x^2+b^21)(2*t*xx^2)*(1+b^2+t^22*t*x)2*b*sqrt(1x^2)*((tx)^2+t*x*(x^2+2*t*xt^22)))))^(1/2)))^2 ], [x] ); Maxima version: 5.24.0 Maxima build date: 20:39 4/5/2011 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3377380&group_id=4933 
From: SourceForge.net <noreply@so...>  20110725 17:21:56

Bugs item #3377347, was opened at 20110725 13:21 Message generated for change (Tracker Item Submitted) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3377347&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: 6 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: log(1/(1+%i)) gives error Initial Comment: log(1/(1+%i)); sign: argument cannot be imaginary; found %i  an error. Error comes from simpln. Looks like simpln needs to bind *complexsign* to T and do something intelligent....  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3377347&group_id=4933 
From: SourceForge.net <noreply@so...>  20110725 16:50:00

Bugs item #3377320, was opened at 20110725 23:48 Message generated for change (Settings changed) made by aakov You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3377320&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: Includes proposed fix Status: Open Resolution: None >Priority: 1 Private: No Submitted By: Andrew Kovalev (aakov) Assigned to: Nobody/Anonymous (nobody) Summary: ezuints  wrong unit for Loschmidt constant Initial Comment: Proper unit should be 1/(m^3), not m^3. Although the mistake is small and noncritical, Maxima not need it.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3377320&group_id=4933 
From: SourceForge.net <noreply@so...>  20110725 16:48:45

Bugs item #3377320, was opened at 20110725 23:48 Message generated for change (Tracker Item Submitted) made by aakov You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3377320&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: Includes proposed fix Status: Open Resolution: None Priority: 5 Private: No Submitted By: Andrew Kovalev (aakov) Assigned to: Nobody/Anonymous (nobody) Summary: ezuints  wrong unit for Loschmidt constant Initial Comment: Proper unit should be 1/(m^3), not m^3. Although the mistake is small and noncritical, Maxima not need it.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3377320&group_id=4933 
From: SourceForge.net <noreply@so...>  20110725 12:51:04

Bugs item #1330685, was opened at 20051019 06:44 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1330685&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: Accepted Priority: 2 Private: No Submitted By: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: "display: failed to break up a long expression Initial Comment: I find that with the following batch file  begin bug.mac  linel:79; linenum:87; fpprec:131; a:1/7.0B+0; b:1234B22; ldisplay(ab);  end bug.mac  then batch ("bug.mac"); => "Expression is too wide to be displayed" repeatably. If this stuff is typed at the command prompt it doesn't happen (output layout is slightly different so it doesn't tickle the bug). The error message originates in CHECKBREAK in src/displa.lisp. Maxima version: 5.9.2 Maxima build date: 0:2 10/11/2005 host type: i686pclinuxgnu lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7 (but also reported on the mailing list to exist in 5.9.1)  >Comment By: Dieter Kaiser (crategus) Date: 20110725 14:51 Message: The problem of this bug report is easy to see in the following example. First, a display of an expressions which fits exactly into the available space: (%i1) linel:10; (%o1) 10 (%i2) aaaaaaa+bbbb; (%o2) bbbb + aaaaaaa Now, we add one char to the first long symbol: (%i3) aaaaaaaa+bbbb; (%o3) bbbb display: failed to break up a long expression. display: change 'linel' slightly and try again.  an error. To debug this try: debugmode(true); The problem is present for all infixoperators. The display routines have to output the expression " + aaaaaaaa". The expression has 11 chars and is too long to be displayed on a line, but the display routines can not break up an expression, which is preceded by a infixoperator. This is a general problem of the implementation, therefore the message "display: change 'linel' slightly and try again.". Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20110706 02:03 Message: I've reopened this item. It's possible to find other values which trigger the bug. See the session pasted below. $ maxima Maxima 5.22.1 http://maxima.sourceforge.net using Lisp GNU Common Lisp (GCL) GCL 2.6.7 (a.k.a. GCL) Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. The function bug_report() provides bug reporting information. (%i1) linel:79; (%o1) 79 (%i2) linenum:87; (%o87) 87 (%i88) fpprec:131; (%o88) 131 (%i89) a:1/7.0B+0; (%o89) 1.428571428571428571428571428571428571428571428571428571428571428571428\ 5714285714285714285714285714285714285714285714285714285714286b1 (%i90) b:1234B22; (%o90) 1.234b19 (%i91) ldisplay(ab); (%t91) 1.428571428571428571428571428571428571428571428571428571428571428571428\ 5714285714285714285714285714285714285714285714285714285714286b1 + ( 1.234b19) = 1.428571428571428570194571428571428571428571428571428571428\ 5714285714285714285714285714285714285714285714285714285714285714285714286b1 (%o91) [%t91] (%i92) linenum:100; (%o100) 100 (%i101) linel:99; (%o101) 99 (%i102) fpprec:137; (%o102) 137 (%i103) ldisplay(ab); (%t103) 1.4285714285714285714285714285714285714285714285714285714285714285714285714285714285714285\ 714285714285714285714285714285714285714286b1 + ( 1.233999999999999999999999999999999999999999999\ 9999999999999999999999999999999999999999999999999999999999999999999999999999999999999992133b19) = display: failed to break up a long expression. display: change 'linel' slightly and try again.  Comment By: Dieter Kaiser (crategus) Date: 20110702 20:26 Message: The reported bug seems to be no longer present in Maxima 5.24post. When loading the batch file from above the result is (%i1) load("bug.mac"); (%t87) 1.428571428571428571428571428571428571428571428571428571428571428571428\ 5714285714285714285714285714285714285714285714285714285714286b1 + ( 1.234b19) = 1.428571428571428570194571428571428571428571428571428571428\ 5714285714285714285714285714285714285714285714285714285714285714285714286b1 (%o87) bug.mac Setting the resolution to "Works for me" and the status to "Pending". Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1330685&group_id=4933 
From: SourceForge.net <noreply@so...>  20110725 12:20:29

Bugs item #3377114, was opened at 20110725 14:20 Message generated for change (Tracker Item Submitted) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3377114&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: 2 Private: No Submitted By: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: Linear display of long symbols and strings Initial Comment: In linear display expressions with long symbols or strings are not formated as expected. This is an example for 2ddisplay and for linear display. The option variable linel is set to 10: (%i1) display2d:true$ (%i2) a+b+c+ddddddd+eeeeeee+ffffffffffffff; (%o2) fff\ fffffffff\ ff + eeee\ eee + ddd\ dddd + c + b + a Again for linear display. The spaces in the output are replaced by points to show the format in this posting: (%i3) display2d:false$ (%i4) a+b+c+ddddddd+eeeeeee+ffffffffffffff; (%o4) ffffffffffffff .......+eeeeeee .......+ddddddd .......+c .......+b .......+a In linear display there are two problems. First, long symbols and strings are not broken up. This is a problem in the function mprint. Second, in linear display the available space is not used fully. This problem is caused in the function lineardisplay. This function prints out the output label directly. Therefore the format of the output label is not under control of the function mprint. The second problem is solved by providing a function msizelabel, which does the formating of the output label under control of the functions msize and mprint. This is an example with a new msizelabel function: (%i1) a+b+c+ddddddd+eeeeeee+ffffffffffffff; (%o1) ffffffffffffff +eeeeeee +ddddddd +c+b+a Still, the first problem is present. Long symbols are not broken up. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3377114&group_id=4933 
From: SourceForge.net <noreply@so...>  20110724 11:52:29

Bugs item #3376603, was opened at 20110724 06:51 Message generated for change (Settings changed) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3376603&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 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: sign of declared imaginary Initial Comment: (%i6) declare(f,imaginary)$ Should be imaginary, not complex: (%i7) csign(f(0)); (%o7) complex OK: (%i8) declare(g,complex)$ (%i9) csign(g(0)); (%o9) complex  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3376603&group_id=4933 
From: SourceForge.net <noreply@so...>  20110724 11:51:53

Bugs item #3376603, was opened at 20110724 06:51 Message generated for change (Tracker Item Submitted) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3376603&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: Open Resolution: None Priority: 5 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: sign of declared imaginary Initial Comment: (%i6) declare(f,imaginary)$ Should be imaginary, not complex: (%i7) csign(f(0)); (%o7) complex OK: (%i8) declare(g,complex)$ (%i9) csign(g(0)); (%o9) complex  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3376603&group_id=4933 