wxMaxima-developers / wxmaxima

A gui for the computer algebra system Maxima built with wxWidgets
https://wxMaxima-developers.github.io/wxmaxima/
Other
459 stars 96 forks source link

Autoconvert to greek letters fails for "beta" #1921

Closed QMeqGR closed 4 days ago

QMeqGR commented 1 month ago

version 24.05.0

I have "Change names of greek letters to greek letters" checked in the configuration. It fails for 'beta' but works for the others I have tried.

daute commented 1 week ago

That's a strange thing. It seem to occur on Windows, but not Linux.

The XML-output on Windows contains different XML for beta than for other Greek characters:

SENT TO MAXIMA:

alpha + beta + gamma;
―
:lisp-quiet (wx-print-gui-variables)

MAXIMA RESPONSE:

<math>
  <lbl altCopy="%o3">(%o3) </lbl>
  <g>gamma</g>
  <mo>+</mo>
  <mi lisp="*var-tag*">beta</mi>
  <mo>+</mo>
  <g>alpha</g>
  </math>
<PROMPT>(%i4) </PROMPT>

On Linux (compiled the tag Version-24.05.0) the output for beta is the same as for the other greek characters: :<g>beta</g>

But - why?

QMeqGR commented 1 week ago

Strange indeed. But I'm using Linux, not windows.

When I try your input above with :lisp-quiet (wx-print-gui-variables) in my wxMaxima I get no output. Rather, I see a message that the cell is in the evaluation queue and nothing happens. If I do :lisp (wx-print-gui-variables) I get NIL. Am I doing something wrong?

daute commented 1 week ago

I did only enter alpha + beta + gamma; in wxMaxima - the :lisp-quiet ... is sent to Maxima by wxMaxima, to get the Maxima variables. The issue seems to be a change in Maxima itself. It works (on Linux too, you are right) when using Maxima 5.43.2 / GCL (included in Ubuntu 20.04), it does not work when using a current Maxima build (also using with GCL 2.6.14).

Hm. What changed there?

Best regards, Wolfgang

QMeqGR commented 1 week ago

You are correct. I just tested with maxima 5.47.0 with sbcl 2.3.11 and "beta" is correctly translated into the Greek symbol. But the current git version of maxima shows the issue.

I don't see any debug settings in wxMaxima that allow me to see the output of :lisp-quiet (wx-print-gui-variables). Is there a maxima console you can type this into after you start wxMaxima?

gunterkoenigsmann commented 1 week ago

The output of wx-print-gui-variables is shown in the xml-monitor: Just double-click on the network symbol in the bottom right of the wxMaxima window.

QMeqGR commented 6 days ago

Thank you. I'm confused because grepping for "var-tag" in the Maxima sources produces nothing. However, it is defined in wxMaxima's source file wxMathML.lisp:

;; The tag that is put around something that might be a variable or function name
;;
;; My guess is that since in maxima functions and variables can have the same name
;; and lazy evaluation means that often it is only later decided which one is used
;; this variable informs the code that prints out the symbol's name if we know that
;; this time the symbol names a function.
(defvar *var-tag* '("<mi lisp=\"*var-tag*\">" "</mi>"))

So I don't understand how <mi lisp="*var-tag*">beta</mi> could be in maxima's response. Does wxMaxima parse the raw output before it shows "MAXIMA RESPONSE"?

Anyway, I suspected this might be the issue because 'beta' is a maxima function, but then why doesn't the same thing occur for 'gamma' which is also a maxima function?

Also, there is a slight difference in output from maxima between 5.47.0 and current git, but I don't know if this is even relevant. This is just maxima's mathml output.

Maxima 5.47.0 https://maxima.sourceforge.io
using Lisp SBCL 2.3.11-2.fc40
(%i1)  load("alt-display.mac")$
(%i2) set_alt_display(2,mathml_display)$
(%i3) beta;
<math xmlns="http://www.w3.org/1998/Math/MathML"> <mi>mlabel</mi> 
 <mfenced separators=""><msub><mi>%o</mi> <mn>3</mn></msub> 
 <mo>,</mo><mi>&beta;</mi> </mfenced> </math>
Maxima branch_5_47_base_1234_g528b07d8b https://maxima.sourceforge.io
using Lisp SBCL 2.4.5
(%i13) beta;
<math xmlns="http://www.w3.org/1998/Math/MathML"> <mi>mlabel</mi> 
 <mfenced separators=""><msub><mi>%o</mi> <mn>13</mn></msub> <mo>,</mo>
 <mi>%beta</mi> </mfenced> </math>
gunterkoenigsmann commented 6 days ago

One of the first things wxMaxima does is to send the contents of wxMathML.lisp to maxima in order to teach it to speak the XML dialect wxMaxima understands.

gunterkoenigsmann commented 6 days ago

One difference between Windows and Linux is that Linux uses real Unicode. Windows often uses 16-bit characters which can represent most of the common unicode characters, but don't waste 32 bits per char like UTF32 would and don't require one to scan all the characters to find the address of the nth char. Not that this is the difference...

gunterkoenigsmann commented 6 days ago

@daute: What definitely has changed is that gcl now has partial unicode support. Before that it was encoding-agnostic: A byte in a string was a byte in a string - and gcl didn't care if that byte is part of an unicode char or not.

daute commented 5 days ago

Found the problematic Maxima commit with git bisect (compiled all Maxima versions with Clisp): https://sourceforge.net/p/maxima/code/ci/446bc61b10f09cfb15915053161c51be29b062dd

The following patch would solve the issue:

$ git diff
diff --git a/src/wxMathML.lisp b/src/wxMathML.lisp
index 776c3816a..07580c931 100644
--- a/src/wxMathML.lisp
+++ b/src/wxMathML.lisp
@@ -727,7 +727,7 @@ Submit bug reports by following the 'New issue' link on that page."))
 (wx-defprop $%alpha "<g>%alpha</g>" wxxmlword)
 (wx-defprop $alpha "<g>alpha</g>" wxxmlword)
 (wx-defprop $%beta "<g>%beta</g>" wxxmlword)
-(wx-defprop $beta "<g>beta</g>" wxxmlword)
+(wx-defprop %beta "<g>beta</g>" wxxmlword)
 (wx-defprop $%gamma "<g>%gamma</g>" wxxmlword)
 (wx-defprop %gamma "<g>gamma</g>" wxxmlword)
 (wx-defprop $%delta "<g>%delta</g>" wxxmlword)

But how to code that, so that wxMaxima will work with Maxima versions before and after the Maxima commit above? (See my message at the Maxima mailing list...)

daute commented 4 days ago

Fixed with commit: https://github.com/wxMaxima-developers/wxmaxima/commit/3bcc55eabf991ef1ea8da7cfaf0c0d62c2e2be7b