#2697 Inconsistent handling of Greek symbols


The statement:

integrate(y(%theta)=sin(%theta),%theta,%theta[0], %theta[1]);

does not uniformly substitute the Greek symbol for theta on the output. (image attachment 1)

If one substitutes the symbol t, for theta, there is an error:
integrate(y(t)=sin(t),t,t[0], t[1]);
defint: variable of integration cannot be a constant; found true (image attachment 2)

If one substitutes the Greek symbol for tau for t, then and only then does it work correctly, but why doesn't tau require the %sign?
integrate(y(tau)=sin(tau),tau,tau[0], tau[1]);

These three situations should behave identically, but they don't.
Further Greek symbols should uniformly require escape with % and they should be case sensitive. as in:
Gamma; gamma; %gamma; float(%gamma); float(Gamma); float(gamma);
producing image attachment 4.
when they should produce image attachment 5.

build_info(version="5.30.0",timestamp="2013-06-01 21:29:43",host="i686-pc-mingw32",lisp_name="GNU Common Lisp (GCL)",lisp_version="GCL 2.6.8")

5 Attachments


  • Robert Dodier

    Robert Dodier - 2014-05-13

    The stuff about %gamma, etc, is easy to explain. The stuff about the integration problem is a bug and I'm working on it. (I wish that these two items had been filed under separate reports, but it's not a big deal.)

    About %gamma, etc: the reason 'gamma' is displayed as the big (majuscule) letter is that 'gamma(x)' is Maxima's notation for the gamma function, which is conventionally displayed with a big letter. On the other hand, '%gamma' is the Euler-Mascheroni constant (approx. 0.5772) which is conventionally displayed with a small (minuscule) letter. You may disagree with these conventions but if so, you'll have to make an argument for changing them; I don't see a bug there.

    I am working on the integration problem.

  • Robert Dodier

    Robert Dodier - 2014-05-13

    In the integration problem, there is the combined effect of 3 different bugs.

    (1) freeof(x, x[1]) => false, when it should be true

    (2) defint tries to substitute a gensym for x, but it gets the Lisp symbol X instead of a gensym; I suspect this is a special variable problem, as the variable in the Lisp code is VAR.

    (3) defint doesn't substitute the original variable back into the result after mapping over the equation.

    I think I can fix (2) and (3) easily. (1) might be harder, but if the others are fixed it may be harmless in this case.

  • Robert Dodier

    Robert Dodier - 2014-05-13
    • labels: integration, Greek symbols, % semantics, special constants, case-sensitivity --> integration, Greek symbols
    • status: open --> closed
  • Robert Dodier

    Robert Dodier - 2014-05-13

    Fixed by commit [2e70e407bba]. Closing this report. Thanks for the bug report.

    (As a follow-up to my previous comment: can't fix bug #1; #2 was fixed already; the commit fixes #3.)

  • Dan Gildea

    Dan Gildea - 2014-05-14

    After commit [2e70e407bba], I get the following error in the testsuite:

    stdin:40973:incorrect syntax: F is not a prefix operator

    This seems to be caused by the line

    (postfix("f"), prefix("g"), done);

    earlier in rtest16.mac

  • Robert Dodier

    Robert Dodier - 2014-05-23

    I've committed [f59632ff] to kill the operators. There is already a workaround in place in rtest16 but this will keep f and g from interfering elsewhere.


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks