From: Stavros M. (Σ. Μ. <mac...@al...> - 2015-12-13 22:03:36
|
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 > > |