Re: [Maxima-discuss] Encoding of bold, underscored, subscripted and superscripted identifiers by wxmaxima

[Gunter K. <gu...@pe...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512



On 14.12.2015 00:28, Roland Salz wrote:
> Hi Gunter,
> 
> thank you very much for your interest in the issue and your 
> detailed answer! My proposal for encoding is of course very 
> primitive, I know, because I stand outside of the knowledge and 
> experience that you guys have with the maxima system. In 
> particular, I have to learn Lisp first, which I just started. (By 
> the way: Can you possibly tell me, which is the better system to 
> work with, GCL or CLISP? Which system is used for compiling
> maxima, I believe it is GCL?)
> 
GCL is much faster than CLISP (can be a factor of 10). But CLISP
doesn't run out of memory even if you handle real big objects so both
have their advantage.

> From the threads of maxima-discuss I've read so far, I get the 
> impression that you are the one who is primarily responsible for 
> wxmaxima?
> 
The main developer is Andrej. But if a thing affects my work and I am
convinced that there is no better way of implementing a thing I am
willing to change things in the code, too.

The disadvantage of this is that I would want to be able to use
underscored and fat text inside of text cells, but don't need this
features within equations (the _bold notation unfortunately won't look
reasonable in text cells). The same is true with superscripts.

And I don't dare to decide that a notation is the Right One if there
are alternatives - even if Andrej might.

Greek letters are a good example of what I am afraid of: We can use
alpha, %alpha and <ESC>alpha<ESC>. All three methods have their
individual disadvantages and cannot be mixed - which is
counter-intuitive. I therefore refused to touch them until the maxima
project in a collaborative effort made maxima support greek letters
natively.

> I follow with great interest the discussion going on about this 
> issue and I try to understand as much as possible. If a mechanism 
> for easy use of variables with properties bold, underscored and 
> sub-/superscripts could be implemented in (wx)maxima, I think a lot
> of users would be very thankful. Instead of just a and A, one could
> use a, A, a_bold, A_bold, a-underscored, A_underscored, etc. and
> all of that together with indexes. No one will ever more run out of
> short and flexible variable names,
he can easily create his
> own systems of lucid variable names for his special mathematical 
> purpose. And all of them could easily be typed on the keyboard.

This notation looks like a good candidate for being the Right Notation
Bold text cannot be supported by the maxima core (as maxima is a
console application) but this notation doesn't break when dropped into
xmaxima or similar.

> 
> I wished I could help programming, but for me it is still a long 
> way to go in understanding the system.
> 

For variable and function names there would the following be to do:

 - Add a method to TextCell that makes this cell bold
 - tell MathParser how to recognize bold text
 - and tell the ToTex and ToHTML methods of TextCell how to deal with
bold text.

Kind regards,

  Gunter.

> Best regards,
> 
> Roland
> 
>> -----Original Message----- From: Gunter Königsmann 
>> [mailto:gu...@pe...] Sent: Saturday, December 12, 2015 
>> 9:31 AM To: max...@li... Subject: Re: 
>> [Maxima-discuss] Encoding of bold, underscored, subscripted and 
>> superscripted identifiers by wxmaxima
>> 
> I would like a real subscript mechanism, too, mainly because one 
> can still impress other people by having an easy way of entering 
> them; Superscripts I have never used until now.
> 
> Hashed arrays are close enough to the Real Thing for most purposes 
> that allowing to add properties to individual hash array entries, 
> resolving a few incompatibilities (for example numericalio won't 
> accept a[1] as a parameter that is to be fitted to a curve) and 
> finding out why hashed arrays are sometimes astonishingly slow (I 
> have still to find a minimal example for this before this issue
> can be resolved) would make them a real subscript mechanism for
> me.
> 
> If a new notation is needed for super-and subscript your notation 
> isn't bad since it doesn't collide with anything maxima currently 
> accept s.
> 
> Telling wxMaxima to convert your notation to some 
> non-suspicious-looking variable name maxima can work with and then 
> converting maxima's output back would be doable, too. But I vote 
> against this option: This would mean that you can enter things
> that are legal for wxMaxima - but will throw an error in maxima
> itself as they will in xMaxima, Jupyter, the maxima mode of emacs,
> Maxima on Android (which is an excellent work, too), maxima as a 
> stand-alone-program and everything I have forgotten to mention.
> And it would give strange results with wxMaxima and
> display2d:false. Also any kind of URL-encoding of strings tends to
> collide with variable names that sooner or later will be actually
> used by a user. Also this would mean that wxMaxima's input might be
> in a format half of the readers of this list won't be able to deal
> with and it would mean that maxima's TeX output would be - strange
> while wxMaxima's TeX output would work file if sub- ore
> superscripts are used.
> 
> If on the other hand the subscript- and superscript feature would 
> be added to maxima's core and someone would help me with the 
> wxmathml.lisp part of the feature I would volunteer adding the 
> necessary code to wxMaxima.
> 
> Kind regards,
> 
> Gunter.
>> 
>> ---------------------------------------------------------------------
- ---------
>>
>>
>> 
_______________________________________________
>> Maxima-discuss mailing list Max...@li...
>>  https://lists.sourceforge.net/lists/listinfo/maxima-discuss
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQJ8BAEBCgBmBQJWbmBbXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ1M0YwNDdDRTY2QjkxQjBGNzI0QzU0NUQ1
Qzg2QzBFNDIxMUQ1QjhFAAoJEFyGwOQhHVuOqx8P/1xY8vHIeH9tUtcE7ObasmM5
xKCuGgoi+OXqcgdmRHoBCEu1ulnhn1gdyaqDiruE7KknJG5y96gXNqxSWn+Wkpfy
Yd+YZZRx0LbqNx1tfcdpFQdTnQEgjWXzd72CeMlevv7jQliZypDIUKqjAVos5by1
k963yYx4MMtHpUT7/RCm1pgxV67QQY0YbT10m/NBKMSBMczIYx87VWPmgPzgQCLG
E+aIms7rbKs7BhCv/zq7MOv2EXapLwtUcWTrW7MZYMyRBuv7qVmCfCs7ir5KPSpK
h30CTYgl4FLrUuJMxHpP9M/k1n+/pl3tXYbvzp0YRjpLxNQzBbgmzjetuZ15hddr
rtezGLxSnsvTfJTaT9ebpLF911il0BlO16HtlNfetI9mddl6PXW4jyro28VXhTtB
AyVmHKh2VtOz9EbAc1/ozasmoniOk0GsPZACmX7qrZ30a0FNJ8uTCyTiEqdwHG6n
c9tDZJ3LMUBckWwDxLsj+BVQZzkHCWXoCFN+cIr/9GOkHttdwZgugFFJzN0ciN9J
RhSWOILPrNm4Su7adO57FcXLulsSHnWkRKXU/ML2u4PzlB805FW0Ht/dR4LS2CvZ
sObfMXMd9JmkXrGxu4S195lv+3tq7v04Q1bHjkSrywvjuR53IFUEDxBe24RQbc/o
FvGkHvh3Wd1AuwPOhh7+
=1MWh
-----END PGP SIGNATURE-----