Menu
▾
▴
maxima-discuss
|
From: Roland S. <ma...@ro...> - 2015-12-11 19:17:36
|
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
|
|
From: Richard F. <fa...@be...> - 2015-12-11 22:40:45
|
I think that if you wish to write such program extensions, that would be possible. I think that mimicking this aspect of mathematical literature is orthogonal to computing results, and so most people have been happy to use the computer as needed, and adapt to whatever notation was conventional for computer programming of the time. Clearly the wide-spread adoption of a larger character set has made more elaborate notations possible, even if not really as convenient as it might seem. It seems that there are 3 problems and one "meta problem". 1. The input language must be easy to learn, easy to type, and general. Thus you might find this easy to learn: bold_italic_M_script[1,2] or maybe whatever TeX has. but it is not easy to type. Picking out unicode and typing encodings is neither easy to learn or easy to type. Few people have keyboards that go much beyond ASCII. 2. The output language must be easy to read and interface with the user as necessary to select subparts. That is, copy the pre-superscript. 3. There must be an internal encoding that is compatible with the system, typically by using long names internally, with a systematic map from input, and to output. (probably not hard) Incidentally the Mathematica system has https://reference.wolfram.com/language/Notation/guide/NotationPackage.html I suspect this package is used by the author of the package and no one else. In any case, a carefully worked-out specification for much of what you might want is available for examination by looking at that documentation. The meta problem is: you can either write the program yourself, or you can convince someone else to write the program. I suggest you learn enough about the internals of Maxima and wxmaxima (and Lisp) to do this yourself. You might have fun. Another "solution" to the encoding of mathematical notation into multi-character symbol names was used by G.E. Collins and his students in writing algorithms and documentation for SAC-1 and then SAC-2. Their solution was just to use those symbol names for input , internal storage, and output. RJF On 12/11/2015 11:17 AM, Roland Salz 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 |
|
From: Bill W. <wil...@co...> - 2015-12-12 01:46:19
|
On Fri, 2015-12-11 at 14:40 -0800, Richard Fateman wrote: . . . > Clearly the wide-spread adoption of a larger character set > has made more elaborate notations possible, even if not > really as convenient as it might seem. Let's not forget the APL experience. I used the APL dialect provided by Control Data for their 6400/6600 series computers in 1974. They encoded APL operators by three-letter acronyms delimited by *, something like *RNK* for the rank operator. Reading a string of those was a treat and a half! I don't think anyone successfully marketed a typewriter or terminal providing the APL character set, though some tried (including, I think, IBM). Still, APL seems to be alive and well. Maybe notation does matter at that. -- Bill Wood |
|
From: Jalaluddin M. <jal...@gm...> - 2015-12-12 02:07:26
|
List Members, I downloaded Maxima-5.36.1.dmg System info wxWidgets: 3.0.2 Unicode Support: yes Maxima version: 5.36.1 Lisp: SBCL 1.2.10 It works once one follows the instructions precisely - it appears Maxima.app and wxMaxima.app need to be in the Applications folder. With 'run_testsuite();' there was 1 warning, and 2 tests failed out of 10,185 total tests: ------------------------------------------------------------------------ <snip> Running tests in rtest9a: ********************** Problem 24 *************** Input: block([s,display2d:true,stuff],s:make_string_output_stream(),with_stdout(s,print(a=b=(c=d))),stuff:get_output_stream_string(s),close(s),stuff) Result: "<mth><v>a</v><v>=</v><v>b</v><v>=</v><p><v>c</v><v>=</v><v>d</v></p><st> </st></mth>" This differed from the expected result: "(a = b) = (c = d) " ********************** Problem 27 *************** Input:block ([s,display2d:true,stuff],s:make_string_output_stream(),with_stdout(s,print(a foo b foo (c foo d))),stuff:get_output_stream_string(s),close(s),stuff) Result: "<mth><v>a</v><v> foo </v><v>b</v><v> foo </v><p><v>c</v><v> foo </v><v>d</v></p><st> </st></mth>" This differed from the expected result: "(a foo b) foo (c foo d) " 26/28 tests passed The following 2 problems failed: (24 27) <snip> Running tests in rtest16: ; in: PROGN (DEFPROP $F T TRANSLATED) ; (SETQ MAXIMA::$X 2) ; ; caught WARNING: ; undefined variable: $X ; ; compilation unit finished ; Undefined variable: ; $X ; caught 1 WARNING condition <snip> ------------------------------------------------------------------------ Jalaluddin |
|
From: Robert D. <rob...@gm...> - 2015-12-12 01:38:58
|
On 2015-12-11, Roland Salz <ma...@ro...> wrote: > 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. I dunno. Instead of encoding display stuff into the name, a more natural Maxima-ish solution would be to define expressions and then write display code for them. E.g. presuper(A, k) => k before and above A, presub(A, k) => k before and below A, etc. Writing display code is somewhat obscure but it could probably be largely adapted from existing stuff -- e.g. DIMENSION-SUPERSCRIPT in src/displa.lisp. I believe wxMaxima has its own display system so some hacking is necessary there too. Probably the easiest display system to handle would be Maxima's 'tex' function, since it's only necessary to generate the appropriate output and TeX will handle the rest. This is easy to arrange via 'texput'. As for properties such as bold or special fonts, presumably it's enough to attach such properties to the main symbol (e.g. A in the above example), or to use a suitable character set (e.g. to get the aleph for aleph-null or whatever). For another look at displaying such stuff, take a look at MathML, which amounts to an expression representation using XML syntax. See e.g.: http://www.w3.org/TR/REC-MathML/chap3_4.html Some Maxima functions handle expressions as variables (e.g. diff, integrate, solve) which means that presuper(A, k), etc would be OK as variables, but others don't (e.g. taylor); I think that's a bug. On a related note, maybe we'd like presuper(A, k), etc to be considered mapatoms (i.e. more like symbols than expressions). best, Robert Dodier |
|
From: Gunter K. <gu...@pe...> - 2015-12-12 08:31:08
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQJ8BAEBCgBmBQJWa9tDXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ1M0YwNDdDRTY2QjkxQjBGNzI0QzU0NUQ1
Qzg2QzBFNDIxMUQ1QjhFAAoJEFyGwOQhHVuODrEP/RXzcsrsN+71HLQoqg/XnM4x
0rxAFOH5XWu0AkPWOBnpYqD3UZKJ2DAoCSthwDCX3oo3UZZwvtk01VLzGZ4u+QwL
ATgy/N/7bRvoaTrceUyMP2PmnB0nYEsh/2nu023KDCcl7WsPxU12bBCsw2p0owjS
NQm0QZp4fLMrnYKXQVMZ4Yqa9hj1yp2gslJAOL8Tl65zlEpRT+ACfRaxY5wi1I9w
BHVCBdH6YZ2Pegsha1KHkHQTS5iuW2HXESU61GbyU9TRrrwEHAkFfse+yvEeopX5
MWBxEjUMg2LKyu3/ND5aAHIbtxbh3jIxflbSp9vARE8eF4bTemEuc5bBiRnlxjxB
a4J6sxsZVGU2FoT3O4vCCFg9PyPMXlduMwxMNa4DwkpljkOiL8DmRZ48sHff7UwB
IFZvkKcUHvRblxMb6EJswJD4IyH6Maqc0c8XuDgyE9uXjJS/xszPhHpTceOuLnn0
ew9IsbAkzxuWbQsBbZ3kEqBMx+74+g7mRGz9NpLZ5HGAsXJ9ucrOQKZW+QODfZhu
UD0gd8PTU1rNTSeFXROeC0PkKKH1zHrd9mc1+TvmZ1yRgyC4ayrSS4xgjYNmqTAL
YHqvEy962GCahznxD5GYCoE9iip2wovcTDhMbC2vx2uhNt6qBXopsZjPNH4U8FoP
E8Jn20HQnZW5M5OpCCYd
=1OLL
-----END PGP SIGNATURE-----
|
|
From: Henry B. <hb...@pi...> - 2015-12-12 12:51:40
|
Interesting!
I once did a similar thing with the Ada programming language. Ada -- like most programming languages -- didn't allow arbitrary characters in its variable names, so I had to come up with an encoding system that could encode any extended ASCII (8 bits/char) character in an Ada variable name. The good news: Ada allowed for extremely long variable names -- just like Lisp in that regard.
At 11:17 AM 12/11/2015, Roland Salz 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 users 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 sw
itches 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 users 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 users possibility to easily create sets of short and consistent variable names for his purposes.
>
>Best regards,
>Roland
|
|
From: Gunter K. <gu...@pe...> - 2015-12-12 17:49:37
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 12.12.2015 18:34, Richard Fateman wrote:
> On 12/12/2015 12:30 AM, Gunter Königsmann wrote:
>> 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,
>
> If the encoding is always legal in Maxima, then why should there be
> a problem?
This is a good idea. The original post contained something like a{e}
for a with e as subscript. Or at least I was convinced that it did
this - and this I found both elegant and dangerous as it would make
wxMaxima's notation incompatible to maxima, when subscripts were used.
> A symbol that looks like
>
> M_Bold should be ok in xmaxima.
It should be OK and if both wxMaxima and xMaxima use the same notation
here - the projects would set a standard the others might follow.
What I would still be slightly afraid of in case we decide to use
subscripts in a notation that is currently legal in maxima is: Nothing
makes all maxima-related projects use the same notation - so there is
the possibility they can grow apart in some details of the notation.
If maxima would implement this notation first its notation would
automatically set the standard everybody has to adhere to.
> I'm not sure what one might want, e.g. a variables superscript
> M_Bold_script[1,2,nil,nil] ?
>
> Axiom allows 4 subscript positions, sub super, pre-super and
> pre-sub...
LaTeX also provides the bbm package that provides letters like the N
with three vertical lines instead of two that marks the natural
numbers... ...if we start adding new notations we should perhaps first
think about how fast we want to go and where we want to stop.
Kind regards,
Gunter.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQJ8BAEBCgBmBQJWbF4kXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ1M0YwNDdDRTY2QjkxQjBGNzI0QzU0NUQ1
Qzg2QzBFNDIxMUQ1QjhFAAoJEFyGwOQhHVuOVocP/23IBPrEwdChOUiCb1mhscUu
dlGtMYg4gp4AnO3gpIqBsLkluF2gXIq3DtL+tPzLlHVAZfa+CcbOcpDea/zSzYa5
7WwxDSCBLCcFAmBlKVgM52VRAxL34CeK2ErXiHMtnu/5JivPzFAGWg9YExRHI0Hv
uogLWWZ1Dydb7foWwmfr+CP2wa6WyqWUwCQbRw9WYFWfcZ1dE+xKa3nIQx1mi8Qn
v6cydL9ao5LrKvqcSJL6cveWBHTWZ4CvE52X/FoYOB2NRtkBPAAqFPF5e9SOWWpU
7UF83vMYnNF1FfGyzrI6wJg1sitJp5oJS1FN1S4imgcRjs8pMy/Bpo5xMArcjLDD
A6tmYZHXKJmBojvU2yPgqrJZXgWwUz5MO+XHocmJwTmCtxl6/NQZEQHcOVuFFpcH
mnSimglGqF5Ys4Ft0EqvZlQFTo+NcICrn23Zi56Qt1cZEhLR4zn6ErgYg/ZAWYBf
0PydEGNplMBNmxbfa8O0Tsoux4e3n686AuqLScC4vodpX1UXm/h+KPN3UFc+pNVo
XqG3j690ot9Q/kmiOuH+W8IK5NBsk3xwuf7qxrAM3cn5kJqUAoxpO136tibkJ4ym
DEDMqgagHXcnLijOXXneTMt6YyNQLWdodiQMNpO0vJm22S8b4dBErusBBwJA1LIG
N7WyVVf+ig2reh29ZfRi
=YQta
-----END PGP SIGNATURE-----
|
|
From: Richard F. <fa...@be...> - 2015-12-12 20:10:38
|
On 12/12/2015 9:49 AM, Gunter Königsmann wrote:
...
>
> What I would still be slightly afraid of in case we decide to use
> subscripts in a notation that is currently legal in maxima is: Nothing
> makes all maxima-related projects use the same notation -
Maxima provides facilities for extending the syntax, so a user could, in
principle, add operators
like &&&.
by
infix("&&&");
a&&&b:= a^3+b^3;
I point this out so you consider: people can already have incompatible
syntax extensions,
so two users working in isolation can have
(incompatible) function names -- re-use with different definitions
(incompatible) definitions of operators
different assumptions on variable names
(etc).
A package system can address some of these issues, but at least my
experience
with the common lisp package system, is that it can be painful to use.
Maxima documentation has
only vague guidance about what names mean when they are bound locally,
or implicitly like in sum(...., i...) or integrate, or by patterns,
or by declarations.
You can still do something useful, even if a user might mess up. He can
already mess up.
\
Richard
|
|
From: Robert D. <rob...@gm...> - 2015-12-12 19:32:58
|
On 2015-12-12, Gunter Königsmann <gu...@pe...> wrote: > resolving a few incompatibilities (for example numericalio won't > accept a[1] as a parameter that is to be fitted to a curve) Hmm, can you explain more about this? best, Robert Dodier |
|
From: Robert D. <rob...@gm...> - 2015-12-12 21:26:25
|
It occurs to me that another approach to generalized placement of indices is to continue with trailing square brackets to indicate indices, but then declare that some indices go before instead of after, and some are above instead of below. So a variable with indices in all four places would be entered as A[k, l, m, n] or whatever and then there would be put (A, '[subscript, superscript, presubscript, presuperscript], 'display_indices); or something like that. Of course not all indices need be present, e.g.: put (B, '[presubscript, subscript], 'display_indices); for a two-index B[m, n], let's say. Pretty-printing display programs (e.g. 2-d display in Maxima or wxMaxima's XML stuff or TeX) would look for those properties and make use of them if present. Computational code would have no idea such properties exist, as we would hope. Readable output (i.e. 'grind') would be unaffected, again as we would hope. I think a scheme like this would actually be pretty easy to implement. best Robert Dodier |
|
From: Stavros M. (Σ. Μ. <mac...@al...> - 2015-12-12 23:01:25
|
I agree that we should be able to define a generic scheme for display of
function calls, probably going beyond just the four surrounding positions.
The display scheme should be general enough to allow the user to define the
display of
hypergeometric ([a1, ..., ap],[b1, ... ,bq], x)
as
[image: Inline image 1]
or
[image: Inline image 2]
In particular, this means that the scheme should cover the case where some
of the display properties are *calculated* (p and q above are redundant:
they are just the lengths of the a[i] and b[i] lists).
-s
On Sat, Dec 12, 2015 at 4:26 PM, Robert Dodier <rob...@gm...>
wrote:
> It occurs to me that another approach to generalized placement of
> indices is to continue with trailing square brackets to indicate
> indices, but then declare that some indices go before instead of after,
> and some are above instead of below. So a variable with indices in all
> four places would be entered as A[k, l, m, n] or whatever and then there
> would be
>
> put (A, '[subscript, superscript, presubscript, presuperscript],
> 'display_indices);
>
> or something like that. Of course not all indices need be present, e.g.:
>
> put (B, '[presubscript, subscript], 'display_indices);
>
> for a two-index B[m, n], let's say. Pretty-printing display programs
> (e.g. 2-d display in Maxima or wxMaxima's XML stuff or TeX) would look
> for those properties and make use of them if present. Computational code
> would have no idea such properties exist, as we would hope. Readable
> output (i.e. 'grind') would be unaffected, again as we would hope.
>
> I think a scheme like this would actually be pretty easy to implement.
>
> best
>
> Robert Dodier
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>
|
|
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
>
>
|
|
From: Roland S. <ma...@ro...> - 2015-12-13 22:55:56
|
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
|
|
From: Richard F. <fa...@be...> - 2015-12-14 03:49:12
|
To some extent you are asking Maxima to support what is, in my opinion,
bad practice. That is, using the same name (M) to mean different things.
If a student did this in a programming class, using the same name for
objects of different types in related contexts, he/she would be told that
it is poor practice.
In mathematics it is not so rare to use the same symbol x for multiple
purposes, e.g. *x *for a vector of something, *X *for a matrix x_i for
some element of something. But it seems you are asking for M[i]
(exactly the same)
to mean two different things. So the simple solution to your
problems is: don't do it.
For your information, Maxima allows the same name to be used as
a global variable and a local one.
It is also possible to use local declarations ..... block([m],
local(m), m(x):=something, ....)
and sum(f(m),m,1,10) is another m, I think.
A simple way to eliminate this source of confusion is to not re-use
names if possible.
RJF
On 12/13/2015 2:55 PM, Roland Salz wrote:
>
> 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...
> <mailto: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...
> <mailto:Max...@li...>
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>
>
>
> ------------------------------------------------------------------------------
>
>
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
|
|
From: Michel T. <ta...@lp...> - 2015-12-14 09:16:50
|
Le 13/12/2015 23:55, Roland Salz a écrit : > 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. In my opinion Maxima is a program for doing symbolic (and possibly numeric) computations, and not a program to format nicely the input or the output of these computations. For doing such computations it is not necessary, and it is frequently inconvenient to complicate notation by using subscripts, boldface and so on. For example what do you lose by writing M1 or M_1 instead of M subscript 1 ? At the end of the day you write a paper with the result of those computations, and by necessity you have to write it in TeX, and thus edit by hand those results. All the people i know who make heavy use of symbolic computation (be it in maxima, maple or mathematica) use the following workflow: type the command in a text editor (vi, emacs, etc.) copy paste in a console running the computation, modify the command in the editor if one is not happy with the result, and iterate. This is the way to get a clean copy of all the steps involved. Sometimes the computation will run for hours or even days, you don't want to be at the mercy of a bug in the windowing system. This means that for such serious use, things such as wxmaxima, maple spreadsheets, etc. are more a hindrance that an asset. I agree that it is easier to examine a long result when is is nicely formatted in TeX form than in the standard 2d display. There is always the possibility to run the maxima session under emacs and imaxima to do that. I know several physicists who still prefer using reduce, which is very good for the computations they are doing (apparently far better than maple or mathematica) and outputs all the results in TeX form. Anyways if your result is a big fraction with very long numerator and denominator, you will be screwed because there is no way to display the fraction on a line (although imaxima works hard to fit the result on lines). -- Michel Talon |
|
From: Roland S. <ma...@ro...> - 2015-12-14 15:55:17
|
Michel, I get your point clearly. Most of you are professional users of maxima and the last thing I want is to create problems to your work. Up to now I did not know how professionals use maxima precisely, so now my understanding is better. From what you said I assume that you would not use wxmaxima at all as a user interface. On the other hand I believe that a large number of users of maxima are students who don't use it professionally as you do but to learn mathematics. (So do I, by the way.) For instance, to my knowledge maxima is widely used in high-schools in Germany, because it is powerful, fairly easy to learn (at least the basics) and it is free. Lately I read a mail in German in maxima-discuss, that seemed to me to have been posted by a high-school student. Of course students will use maxima differently: for them a nicely formatted output like the one from wxmaxima is worth a lot. They can solve their exercises, print out the worksheet with the results and give them to their teacher. They will not want to transform their output by tex or anything. Let's not underestimate the use of maxima even for this kind of users: who for instance today wants to do matrix multiplication or inversion by hand, even in school? That's almost like trying to divide two rational numbers with a sheet of paper and a pencil. So let's take the perspective of such a student. He works with vectors and matrices for example. He gets a specific basis of an E3-vector space called <g bold subscript 1>, <g bold subscript 2> and <g bold subscript 3> and his task is to calculate the dual basis <g bold superscript 1>, <g bold superscript 2>, <g bold superscript 3>. None of these sub-/superscripts denote any components of the vectors! Maybe <g non-bold> is also used. Maybe metric tensors are involved, too: <g subscript ij> and <g superscript ij>. Next he has to calculate a matrix <A subscript .j superscript i>, and so on. Of course he can encode all that as (if he does not want to end up with extremely long names) for example gb1, gbu2, g, gij, guij, A\.jui, etc. But two days after he coded it this way, he will no longer be able to understand his own notation. He would, however, if he could encode this stuff in maxima in the same way as it was written in the exercise he got, that is, using bold and having easy to enter, element-independent subscripts and superscripts at hand. And everyone else in his class would, too. It's only for this type of application that my original proposal was meant for. That's why my original idea was to keep the whole matter within wxmaxima and not touch maxima itself and the other interfaces. The proposed matters are only user-interface matters of this specific interface wxmaxima. Actually, I would not consider it so much of a problem if such features would be limited to wxmaxima. As long as they don't create conflicts within wxmaxima itself, I think it should be ok. Such features could be marked clearly in the documentation as only being applicable to wxmaxima. The purposes of the different user interfaces are different, so I think a certain amount of discrepancy would be tolerable. Best regards, Roland > -----Original Message----- > From: Michel Talon [mailto:ta...@lp...] > Sent: Monday, December 14, 2015 10:16 AM > To: max...@li... > Subject: Re: [Maxima-discuss] Encoding of bold, underscored, subscripted > and superscripted identifiers by wxmaxima > > In my opinion Maxima is a program for doing symbolic (and possibly > numeric) computations, and not a program to format nicely the input or the > output of these computations. For doing such computations it is not > necessary, and it is frequently inconvenient to complicate notation by using > subscripts, boldface and so on. For example what do you lose by writing M1 > or M_1 instead of M subscript 1 ? At the end of the day you write a paper > with the result of those computations, and by necessity you have to write it > in TeX, and thus edit by hand those results. All the people i know who make > heavy use of symbolic computation (be it in maxima, maple or mathematica) > use the following > workflow: type the command in a text editor (vi, emacs, etc.) copy paste in a > console running the computation, modify the command in the editor if one is > not happy with the result, and iterate. This is the way to get a clean copy of > all the steps involved. Sometimes the computation will run for hours or even > days, you don't want to be at the mercy of a bug in the windowing system. > This means that for such serious use, things such as wxmaxima, maple > spreadsheets, etc. are more a hindrance that an asset. I agree that it is easier > to examine a long result when is is nicely formatted in TeX form than in the > standard 2d display. There is always the possibility to run the maxima session > under emacs and imaxima to do that. I know several physicists who still > prefer using reduce, which is very good for the computations they are doing > (apparently far better than maple or mathematica) and outputs all the results > in TeX form. Anyways if your result is a big fraction with very long numerator > and denominator, you will be screwed because there is no way to display the > fraction on a line (although imaxima works hard to fit the result on lines). > > -- > Michel Talon > > > ---------------------------------------------------------------------------- -- > _______________________________________________ > Maxima-discuss mailing list > Max...@li... > https://lists.sourceforge.net/lists/listinfo/maxima-discuss |
|
From: Michel T. <ta...@lp...> - 2015-12-14 20:29:11
|
Le 14/12/2015 16:55, Roland Salz a écrit : > It's only for this type of application that my original proposal was meant > for. That's why my original idea was to keep the whole matter within > wxmaxima and not touch maxima itself and the other interfaces. The proposed > matters are only user-interface matters of this specific interface wxmaxima. > Actually, I would not consider it so much of a problem if such features > would be limited to wxmaxima. As long as they don't create conflicts within > wxmaxima itself, I think it should be ok. Such features could be marked > clearly in the documentation as only being applicable to wxmaxima. The > purposes of the different user interfaces are different, so I think a > certain amount of discrepancy would be tolerable. I completely agree with what you say. If the problem is to tweak wxmaxima in order to get more beautiful notation in wxmaxima, this is perfect, and of course it may be useful for students. I am still perplexed that you are using formal computation in high school in Germany. Either all your young people at school are geniuses, or they are skipping the step where you learn the basics, how you multiply small matrices by hand, etc. before handing the task to a computer without having any idea what the computer does. Of course, at a higher level, namely at university, it is very important to become familiar with symbolic computation, because it is necessary for doing very complex computations without error (as a matter of fact, mathematicians of the 19 century were able to perform extremely complex computations by hand, e.g. Jacobi, Sylvester, Kowalevsky etc. did computations that are hard to reproduce with a computer), but in this case notation is a secondary aspect. -- Michel Talon |
|
From: Gunter K. <gu...@pe...> - 2015-12-14 06:23:32
|
-----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----- |
|
From: Raymond T. <toy...@gm...> - 2015-12-14 16:53:14
|
>>>>> "Michel" == Michel Talon <ta...@lp...> writes:
Michel> Le 13/12/2015 23:55, Roland Salz a écrit :
>> 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.
Michel> In my opinion Maxima is a program for doing symbolic (and possibly
Michel> numeric) computations, and not a program to format nicely the input or
Michel> the output of these computations. For doing such computations it is not
Michel> necessary, and it is frequently inconvenient to complicate notation by
Michel> using subscripts, boldface and so on. For example what do you lose
Michel> by writing M1 or M_1 instead of M subscript 1 ? At the end of the day
Michel> you write a paper with the result of those computations, and by
Michel> necessity you have to write it in TeX, and thus edit by hand those
Michel> results. All the people i know who make heavy use of symbolic
I agree with this approach. I want maxima to be simple and not do all
that much formatting. Let wxMaxima and other frontends do all the
pretty stuff. Even then, it's not always what I want for publication
so I have to do lots of work anyway to get it done nicely. Things
like 1 + x^2 vs x^2 + 1 depend on context and convention.
I don't have any objection if wxmaxima wants to take user input and
massage that into some kind of encoded variable name that maxima can
manipulate and that wxmaxima can decode to display things nicely.
Just don't make it a mess for users who don't use wxmaxima.
--
Ray
|
|
From: Kris K. <kat...@gm...> - 2015-12-14 19:14:18
|
On Mon, Dec 14, 2015 at 08:52:54AM -0800, Raymond Toy wrote: > >>>>> "Michel" == Michel Talon <ta...@lp...> writes: > > Michel> Le 13/12/2015 23:55, Roland Salz a écrit : > >> 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. > > Michel> In my opinion Maxima is a program for doing symbolic (and possibly > Michel> numeric) computations, and not a program to format nicely the input or > Michel> the output of these computations. For doing such computations it is not > Michel> necessary, and it is frequently inconvenient to complicate notation by > Michel> using subscripts, boldface and so on. For example what do you lose > Michel> by writing M1 or M_1 instead of M subscript 1 ? At the end of the day > Michel> you write a paper with the result of those computations, and by > Michel> necessity you have to write it in TeX, and thus edit by hand those > Michel> results. All the people i know who make heavy use of symbolic > > I agree with this approach. I want maxima to be simple and not do all > that much formatting. Let wxMaxima and other frontends do all the > pretty stuff. Even then, it's not always what I want for publication > so I have to do lots of work anyway to get it done nicely. Things > like 1 + x^2 vs x^2 + 1 depend on context and convention. > > I don't have any objection if wxmaxima wants to take user input and > massage that into some kind of encoded variable name that maxima can > manipulate and that wxmaxima can decode to display things nicely. > Just don't make it a mess for users who don't use wxmaxima. I vehemently agree. Cheers, Kris Katterjohn |
|
From: Richard F. <fa...@be...> - 2015-12-14 17:25:40
|
My experience with most math students is that they want to learn as little as possible about the computer system -- just enough to get the job done. Learning extra syntax is considered extra work, and who wants to spend time on extra work unless they get extra credit or it is on the midterm. And many people have trouble with knowing the precedence of a+b*c So I doubt that typesetting subscripts is high on the list of learning objectives for students who just want to get a passing grade on a required course, and the wish to forget all about math. Sad, but that's my experience. Richard On 12/14/2015 7:55 AM, Roland Salz wrote: > Michel, I get your point clearly. Most of you are professional users of > maxima and the last thing I want is to create problems to your work. Up to > now I did not know how professionals use maxima precisely, so now my > understanding is better. From what you said I assume that you would not use > wxmaxima at all as a user interface. > > On the other hand I believe that a large number of users of maxima are > students who don't use it professionally as you do but to learn mathematics. > (So do I, by the way.) For instance, to my knowledge maxima is widely used > in high-schools in Germany, because it is powerful, fairly easy to learn (at > least the basics) and it is free. Lately I read a mail in German in > maxima-discuss, that seemed to me to have been posted by a high-school > student. Of course students will use maxima differently: for them a nicely > formatted output like the one from wxmaxima is worth a lot. They can solve > their exercises, print out the worksheet with the results and give them to > their teacher. They will not want to transform their output by tex or > anything. Let's not underestimate the use of maxima even for this kind of > users: who for instance today wants to do matrix multiplication or inversion > by hand, even in school? That's almost like trying to divide two rational > numbers with a sheet of paper and a pencil. > > So let's take the perspective of such a student. He works with vectors and > matrices for example. He gets a specific basis of an E3-vector space called > <g bold subscript 1>, <g bold subscript 2> and <g bold subscript 3> and his > task is to calculate the dual basis <g bold superscript 1>, <g bold > superscript 2>, <g bold superscript 3>. None of these sub-/superscripts > denote any components of the vectors! Maybe <g non-bold> is also used. Maybe > metric tensors are involved, too: <g subscript ij> and <g superscript ij>. > Next he has to calculate a matrix <A subscript .j superscript i>, and so on. > Of course he can encode all that as (if he does not want to end up with > extremely long names) for example gb1, gbu2, g, gij, guij, A\.jui, etc. But > two days after he coded it this way, he will no longer be able to understand > his own notation. He would, however, if he could encode this stuff in maxima > in the same way as it was written in the exercise he got, that is, using > bold and having easy to enter, element-independent subscripts and > superscripts at hand. And everyone else in his class would, too. > > It's only for this type of application that my original proposal was meant > for. That's why my original idea was to keep the whole matter within > wxmaxima and not touch maxima itself and the other interfaces. The proposed > matters are only user-interface matters of this specific interface wxmaxima. > Actually, I would not consider it so much of a problem if such features > would be limited to wxmaxima. As long as they don't create conflicts within > wxmaxima itself, I think it should be ok. Such features could be marked > clearly in the documentation as only being applicable to wxmaxima. The > purposes of the different user interfaces are different, so I think a > certain amount of discrepancy would be tolerable. > > Best regards, > > Roland > >> -----Original Message----- >> From: Michel Talon [mailto:ta...@lp...] >> Sent: Monday, December 14, 2015 10:16 AM >> To: max...@li... >> Subject: Re: [Maxima-discuss] Encoding of bold, underscored, subscripted >> and superscripted identifiers by wxmaxima >> >> In my opinion Maxima is a program for doing symbolic (and possibly >> numeric) computations, and not a program to format nicely the input or the >> output of these computations. For doing such computations it is not >> necessary, and it is frequently inconvenient to complicate notation by > using >> subscripts, boldface and so on. For example what do you lose by writing M1 >> or M_1 instead of M subscript 1 ? At the end of the day you write a paper >> with the result of those computations, and by necessity you have to write > it >> in TeX, and thus edit by hand those results. All the people i know who > make >> heavy use of symbolic computation (be it in maxima, maple or mathematica) >> use the following >> workflow: type the command in a text editor (vi, emacs, etc.) copy paste > in a >> console running the computation, modify the command in the editor if one > is >> not happy with the result, and iterate. This is the way to get a clean > copy of >> all the steps involved. Sometimes the computation will run for hours or > even >> days, you don't want to be at the mercy of a bug in the windowing system. >> This means that for such serious use, things such as wxmaxima, maple >> spreadsheets, etc. are more a hindrance that an asset. I agree that it is > easier >> to examine a long result when is is nicely formatted in TeX form than in > the >> standard 2d display. There is always the possibility to run the maxima > session >> under emacs and imaxima to do that. I know several physicists who still >> prefer using reduce, which is very good for the computations they are > doing >> (apparently far better than maple or mathematica) and outputs all the > results >> in TeX form. Anyways if your result is a big fraction with very long > numerator >> and denominator, you will be screwed because there is no way to display > the >> fraction on a line (although imaxima works hard to fit the result on > lines). >> -- >> Michel Talon >> >> >> > ---------------------------------------------------------------------------- > -- >> _______________________________________________ >> Maxima-discuss mailing list >> Max...@li... >> https://lists.sourceforge.net/lists/listinfo/maxima-discuss > > ------------------------------------------------------------------------------ > _______________________________________________ > Maxima-discuss mailing list > Max...@li... > https://lists.sourceforge.net/lists/listinfo/maxima-discuss |
|
From: Barton W. <wi...@un...> - 2015-12-14 18:57:03
|
Would something like http://reference.wolfram.com/language/ref/Subscript.html be a start? I'd guess users would want things like diff(subscript(x,k), subscript(x,l)) --> kron_delta(k,l) |
|
From: Gunter K. <gu...@pe...> - 2015-12-14 19:15:31
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 In the meantime Andrej did some lisp magic that makes wxMaxima display x_y as a subscripted variable if y is a integer, only one char long or if this has been defined by a rather fain-grained control => We have a easy - and quite readable way to input subscripted variables. Kind regards, Gunter. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJWbxVDXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ1M0YwNDdDRTY2QjkxQjBGNzI0QzU0NUQ1 Qzg2QzBFNDIxMUQ1QjhFAAoJEFyGwOQhHVuOIKkP/1DdM92ZM8oya1u18eqH2RUm FHDBJmK96UMUgF1bpCXiHkewtBiGW2FZVMnX7MdNa2lJg0zvjLPwzTeMiaOzXTLk /eMt7EZpDbuh5IKWWO/SPlPS1Gasy4KOhDIp2yBEg1pWnmu+oNpGc+9SP3oV6Dio bFjtqLAy4Jf1Aw0Ix9DQUo7Syb6EQ5IIn/zkc+MFhd7SO0ZLiYe4lewbWE+FRxPd hMYmAjW+qT7Emid+t92z0by4Nj3TdKX9VvYeWuMa9I2waL0eC5RA5hJxRQP5RV8z FVseEAnPxHlUMsLn9gw5KWm1OagWq4TRb8Uadd8jlGFuhbHy1shMrcHOlanuUa1K bekCEwuMTIea1V5qLzCJGmYg1JTIOcTHN3Z1Ug8dq6ocN4hM8v0br7C/+SRJ8SGu ACP2KU97Qh3vnkBi/za5FNbRPfQcgbPs4liOvtrx5nYFN0vvkbFkvr95uIUzi7PK 10Ygf77T4vnZRQ7aabV3VKhboQeHEs+dn92+LODZJUwca3/BRvQYA6PpTDBNTNw0 lrvMLYhORbjZSWNAOC5sXISintn65HyGhkbUFtTXCydJvxmHP3BsSBRXppN8Kbo9 n8tnqdlbHwjeFtCg8Yq2JBe5gKMO0AkPPEZGFw18QOfYzVLKcB3ygh9WiQe9CoXd U6/D9mS/GwXyd/Iu+xAd =91C4 -----END PGP SIGNATURE----- |
|
From: Gunter K. <gu...@pe...> - 2015-12-15 06:32:42
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 @Roland: Andrej has added a new feature to the current nightly build of wxMaxima that allows to input subscripts in a TeX-like manner. I think it should solve the original problem. At least it does for an engineer like me. Kind regards, Gunter. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJWb7P/XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ1M0YwNDdDRTY2QjkxQjBGNzI0QzU0NUQ1 Qzg2QzBFNDIxMUQ1QjhFAAoJEFyGwOQhHVuOXaIP/inh7aPMA1wIoklYq60IGT6B G5n6cexN7rqzcBdG1tmMFI2rZhQFEdJsi3SXj0rOk6IYwdfM/pzhtVP6qotPeFzT b1EhDU2I60tYLcKK2bME4Fcp2V/Kv6wbZzTpifsI7tTCKvCuu2txVBX6npu84kVL Bo5EonZ2OhrxqSLQWMtiQCLvPn9971cYIaxc6mjrqCbh2fveyOdWWKOsyTKrGPwQ j6thUadm/46ZkwlMpWAeVySUv9PYn+Mcen70KCLNsIZQpbtK8JRMxJEkaoAWNKq/ KQmO36nB3gilgLuCUUzNekhYxELlOlZQeGmDdelt4JQ9EfoV/C0I0fzJBoqWJZl8 mSfc6cfn7y7+rbCpHvVInitAnuVyuxyzrFx2OH0++yBy9COKJrTsX/38tj/us5G0 58CEfxJhTMgYqrO1JnoT2yVUIEvJjS/8CNcgbaSgGmv7nC5/qqmcsmFgyqhJvZrE kzpXM6yu3BTiumAg60Qg0Nw0Z3s1y0FR/rzHQSC+TMZc8Jj4xeX+pwBpzODnASZo CBs/c/fqagd1E6Jjc/qgkzyf2SJPky07fYi6Pdvr6DjwK5c2zyHiOFh7A6zjcZM0 IdLpA5OhEltG6l4AucMXVKU3ILyqje6kqhTG3ymLIVlCNFDjfNFgxbuKhClC6New mPl8SU/BL4RuVrwmX2M7 =wBwE -----END PGP SIGNATURE----- |
Thanks for helping keep SourceForge clean.
X