An idiosyncrasy, in how Maxima evaluates parameters.

One of the facts which I had written about Maxima in an earlier posting was, that it seems to have a number of functions, the purpose of which in English seemed to be, ‘Take a parameter or expression as input, but give me the value of this parameter.’ And what I had actually written was, that this availability of more than one similar function, could confuse me at one point in time, into not actually knowing what one specific function does. Yet, reflecting on the question outside the exercise that I was doing, brought back the gist of what that function really does. In the previous context, it was the function ‘ev()’.

A context which some other people have noticed instead, is that they’d like to use the Maxima ‘tex()’ function, in order to convert some expression into LaTeX, for another application to typeset, but in some cases the other users wanted to use previous lines of input directly, rather than to use previous lines of output. And what they found was, that the LaTeX version of what they had input, was a ‘verbatim’ block, different according to LaTeX, from what needs to be typeset as Math.

Both issues arise somewhere, because Maxima itself has been programmed in the language LISP. And, most of the time, LISP just seems to produce correct results, according to the way some people tend to interpret the meaning of the LISP function call. But in certain cases, people who either program in, or use LISP, need to form a mental, step-by-step picture of what the LISP interpreter actually does. LISP evaluates both atoms and lists, the latter of which could represent Mathematical expressions, but the former of which represent variables, in situations where their values are being referred to, and not the atom itself. At any point in the computation, LISP will actually evaluate an atom or a list, according to the same semantics. Given an atom, its value is returned, which could be another atom as easily as a list. And, given a list, to return its value means, to execute that list once.

The modern way to refer to what I’ve called an Atom here, is as a “Symbol”, which is really the name of a (LISP) Variable, that also has a value, at a given instant in time.

The way LISP generally defines lists, each of their elements may either be an atom or another list, ‘nested’ within its parent list. In LISP, lists are slightly more common, the first element of which is an atom, just because in such a case, this first element states which function is to be called on the remaining elements. But, in LISP, data is also represented as either a list or an atom, and then, in the case of a list, there is no specific need for the first element to be an atom, or one that represents a defined LISP function. (:1)

Obviously, most other Computing languages, including the one which Maxima interprets, states the function-name first, followed by one set of parentheses, around any argument-list, or around a parameter-list, in the case where the function is being defined. Infix operators are usually also represented internally, as predicates, in whatever data-format those can be represented. One major exception to this takes the form of ‘stack-based languages’, such as ‘FORTH’, and another exception exists in Assembler.

Aside: ‘Prolog’ represents both data and programming as an n-graph, meaning that in this language, each node of a tree may have an arbitrary number of branches, including zero, but additionally, an atomic predicate, stating whichever relationship between the other branches is to be satisfied.

The total number of times LISP evaluates a parameter is tightly defined, so that, if an atom represents a variable, which in turn has a list as its value, that item will result, but not be executed, unless the command is given explicitly, to evaluate the result of the previous evaluation. In LISP, the function which gives such an explicit command, is called ‘EVAL’, and the way to give that instruction, in any context where the variable ‘X’ is instantiated, is like so:

(EVAL X)

Because of the way LISP generally evaluates lists, since ‘X’ does not have a tick – a single quote – in front of it, ‘X’ was already evaluated once, before being passed to ‘EVAL’. And then, ‘EVAL’ evaluates whatever value ‘X’ had, a second time. Even according to Human thought, the fact that ‘X’ represented a value, can seem to disappear, so that Humans will also think, ‘Whatever is being referred to as X, evaluate that.’

Well, the way this works can be revealed, in certain uses of Maxima, such as, if the ‘tex()’ function is being called on an input identifier, when most of the time, it was meant to be used either, on an expression that has been parsed into a LISP structure, or, on a variable, which already evaluated to such an expression, before ‘tex()’ went to work on it.

Yet, because some people want to obtain the LaTeX representation of text, which they previously input, from Maxima, the following text-log displays where an extra step needs to be inserted, in order to accomplish this:

(Updated 7/14/2020, 22h15… )

Continue reading An idiosyncrasy, in how Maxima evaluates parameters.