Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

## #2697 Inconsistent handling of Greek symbols

None
closed
nobody
2
2014-05-23
2014-03-05
Van
No

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

## Discussion

• 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
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
2014-05-13

• labels: integration, Greek symbols, % semantics, special constants, case-sensitivity --> integration, Greek symbols
• status: open --> closed

• 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
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
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.