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

[Roland S. <ma...@ro...>]

My intention was to give an example for conflicts when coding independent subscripted variables in the present way as M[x]. In this example I don’t want to address components or elements by the subscripts, but just use them for whatever other reason. When I want to use the variables M, <M subscript 1>, <M subscript 2>, etc. as independent objects, let’s say all of them matrices, I cannot. As soon as M is a matrix, M[x] is not free to use any more for my independent <M subscript x>. Of course M[x,y] shall continue to denote the elements of M and M[x] the row. But how can I represent my independent variable <M subscript x>? I have no possibility left, do I? 

 

The user, as far as I see, has to always be aware of these types of conflicts arising when he wants to use the present mechanism for encoding subscripted names. That is what I mean by not satisfactory. Best would be, if these conflicts could not arise at all. But then these “independent” (not denoting elements) subscripts would have to be encoded in a principally different way.

 

Maybe my example was not good. But practically I ran into these types of conflicts a hundred times when using maxima. Am I alone with this experience? (I hope not …!!)

 

Best regards,

 

Roland

 

From: mac...@gm... [mailto:mac...@gm...] On Behalf Of Stavros Macrakis (Sta???? ?a??????)
Sent: Sunday, December 13, 2015 11:03 PM
To: Roland Salz
Cc: Maxima discuss
Subject: Re: [Maxima-discuss] Encoding of bold, underscored, subscripted and superscripted identifiers by wxmaxima

 

Re

Secondly, the present way in maxima of coding subscripted identifiers as elements of hashed arrays is not satisfying, because it regularly causes conflicts within these arrays and with lists. If, for example, a 2-dimensional matrix is assigned to an identifier M, then M[1] cannot be used as another variable, because it already denotes the first line of the matrix M.

 

Maxima uses subscripts to denote indexing in a variety of contexts, not just hasharrays. For example, L:[a,b,c]$ L[2] => b.

 

I am not sure what your proposal is about M vs. M[1]. Are you suggesting that those should be considered distinct, unrelated objects? I don't see how that would work. Don't you expect M[2,2] to be the 2,2 element of object M? Would you prefer to have to write matrix_element(M,2,2)?

 

               -s

 

 

On Fri, Dec 11, 2015 at 2:17 PM, Roland Salz <ma...@ro...> wrote:

Hi,

 

Mathematical literature makes extensive use of bold characters in order to give semantic value to identifiers, e.g. mark an identifier to be a vector or a tensor. In order to keep formulas readable, every identifier is kept as short as possible, even though loaded with all the information necessary. Unfortunately, in programming languages ‘bold’ is not a semantic value but merely a style of presentation. The user of maxima, if he thinks mathematically in bold – non bold categories, has to somehow translate this semantic difference, but he does not find a really satisfying way. Identifiers become longer and formulas less readable.

Secondly, the present way in maxima of coding subscripted identifiers as elements of hashed arrays is not satisfying, because it regularly causes conflicts within these arrays and with lists. If, for example, a 2-dimensional matrix is assigned to an identifier M, then M[1] cannot be used as another variable, because it already denotes the first line of the matrix M. 

Superscripts, as far as I know, are not possible at all, because they would be interpreted as exponents.

I would like to propose consideration of the following mechanism as a possible solution to resolve these handicaps of present maxima. Bold as well as sub-/superscripted identifiers are encoded by wxmaxima into simple character strings, then being passed to maxima as the corresponding identifier names. They are thus encoded as unique normal maxima identifiers. The length of the resulting strings will probably not be a problem. And special characters for encoding purposes there are now enough within unicode. When maxima sends back the results, wxmaxima decodes them into what was the user’s input and intention and displays them accordingly. One would have to think about how the user has to code these features, either by directly using bold characters (which of course would be best) or by some other indication, and some way to indicate sub-/superscripts (best would be again a direct, intuitive way, e.g. by switching the input to subscript or superscript in the same way as he switches to bold input). 

Example:   M{2;3} is displayed by wxmaxima as M with a subscript 2 and a superscript 3; it is encoded as e.g. zM{2|3 and sent to maxima.

One advantage of this solution would be the perfect backward compatibility. If the user makes no use of these features, no encoding is done. And he can even still make use of the traditional way to encode subscripts as hashed arrays. So no old worksheets have to be changed. Maxima is not affected. The whole translation issue remains within wxmaxima.

A possible problem could arise, if the user’s program code itself generates identifiers, e.g. by concatenation. In this case the user/programmer would need to know the internal coding translation. 

As a third feature to be treated in the same way, also underscored characters could be used as identifiers, enlarging even more the user’s possibility to easily create sets of short and consistent variable names for his purposes.

 

Best regards,

Roland

 


------------------------------------------------------------------------------

_______________________________________________
Maxima-discuss mailing list
Max...@li...
https://lists.sourceforge.net/lists/listinfo/maxima-discuss