Can I change the way Maxima displays the transpose operator? The (default) of just printing "transpose" uses very much space and makes the formulae harder to read.
When I enter:
transpose(M)
I would like it to print something like
MT.
I use Maxima through wxMaxima.
PS. There is no tag for wxMaxima on SO.
This is a great question. Unfortunately there isn't a way to handle it within Maxima itself, but if it's OK to do a little Lisp programming, we can solve it.
(%i1) :lisp (defun dimension-transpose (expr stuff) (dimension-superscript `((mexpt) ,(cadr expr) |$t|) stuff))
DIMENSION-TRANSPOSE
(%i1) :lisp (setf (get '%transpose 'dimension) 'dimension-transpose)
DIMENSION-TRANSPOSE
(%i1) transpose(A.B);
T T
(%o1) B . A
Essentially we just define a display function which constructs an MEXPT (i.e. "^") expression and displays that, and then tell Maxima to use the new function to display transpose expressions.
Be careful to copy the punctuation exactly as it is shown. Be careful to distinguish backtick from single quote.
EDIT: The above works for command-line Maxima. For wxMaxima probably there is some similar procedure, but I don't know it.
Related
I was just thinking about the different mapping functions in common-lisp as described in the hyperspec. I am pretty much used to mapcar and think it is the easiest to understand. But what is a real world example of using mapc? The example in the hyperspec uses it for a side-effect as far as I get it. But why does it return the list argument?
Is there a general rule when such a mapping is favourable over an iteration using loop etc.?
What is a real world example of using mapc?
(mapc #'print my-list) is clearer than (dolist (x my-list) (print x))
Why does it return the list argument?
The functional heritage imposes the thinking that every function should return something useful; for mapc it is the original list.
I think mapc returns its list argument for the same reason print does - to simplify debugging by sprinkling your code with output. E.g., suppose you do something like
(mapcar #'important-processing
list-with-weird-elements)
You want to see what's inside the list while preserving the logic:
(mapcar #'important-processing
(mapc #'show-weird-object list-with-weird-elements))
Also, a lot of things in CL are for "hysterical reasons".
Is there a general rule when such a mapping is favourable over an iteration using loop etc.?
Only if you already have a function which does what you need, like print above.
I would write a function which can parse the multiplication of 2 algebraic expressions in GF(2), i.e any variable in the expression only take on 2 possible values 0 or 1, so a^2 = a,(0^2 = 0, 1^2 = 1)
As an example, if we expand (a+b)*(a+c) in GF(2), we should get
(a + b)*(a + c) = a^2 + a*b + a*c + b*c = a + a*b + a*c + b*c.
However, I am not sure how to start about the parsing of 2 algebraic expressions using strings. Any suggestion/ help is appreciated. Thanks!
I would recommend taking a look at OMeta, by Alex Warth, and/or PetitParser, by Lucas Rengli. Both are excellent frameworks for writing parsers. The first one is for JS, the second for Smalltalk.
Here are some few initial lines of code showing how to write your parser in PetitParser. Every fragment is a method of your own subclass of PPCompositeParser.
constant
ˆ$0 asParser / $1 asParser
variable
^#letter asParser
timesOp
^#blank asParser star , $* asParser, #blank asParser star
sumOp
^#blank asParser star, $* asParser, #blank asParser star
element
^self constant / self variable
term
^self element , (self timesOp , self element) star
etc.
I'm not saying this is trivial. I'm only saying that this is where I would start. Note also that once you have your grammar in place you might want to subclass it so you can generate more appropriate productions, etc.
Writing parsers for big complicated languages can be hard. But writing parsers for algebraic expressions (GF(2) or otherwise) is pretty easy.
See my SO answer on how to write such parsers easily: Is there an alternative for flex/bison that is usable on 8-bit embedded systems?
The GF(2) bit is about semantic interpretation of what such a formula means. It doesn't matter at all for parsing, which is purely about syntax.
Where meaning comes into play is when you want to interpret the formula.
At some point, you may want to evaluate the expression using values for the variables. To do that, you have to capture the formula as a data structure (usually called an (abstract) syntax tree), and then walk that tree to compute the desired result. That link also discusses how to do that.
If you want to manipulate the formula symbolically, you're in an entirely different ball game. Parsing is still easy, but formula manipulation is not, and you'll want to use tools that are designed to do such symbolic manipulation; they generally define thier own parsing machinery (and make it easy to use) to ensure that the captured parse can be manipulated. And of course, you'll have to define what the rules of you symbolic manipulation are.
You can see an example of how to write something pretty close to your needs at Symbolic Algebra with a program transformation system. (This a tool that my company builds).
Design at-0. The function consumes a list of functions from numbers to numbers and produces the list of results of applying these functions to 0.
Actually, the straightforward solution I can think of uses map, not local. Now, of course, if you're using a student language that doesn't support map, that's a different story. Anyway, here's a skeletal solution for you:
(define (at-0 funcs)
(map (lambda <???>
(<???> <???>))
funcs))
I need to convert a math formula written in the Latex style to the function of a C/C++ code.
For example:
y = sin(x)^2 would become something like
double y = sin(x) * sin(x);
or
double y = pow(sin(x), 2);
where x is a variable defined somewhere before.
I mean that it should convert the latex formula to the C/C++ syntax. So that if there is a function y = G(x, y)^F(x) it doesn't matter what is G(x,y) and F(x),
it is a problem of the programmer to define it. It will just generate
double y = pow(G(x, y), F(x));
When the formula is too complicated it will take some time to make include it in the C/C++ formula. Is there any way to do this conversion?
Emacs' built-in calculator calc-mode can do this (and much more). Your examples can be converted like this:
Put the formula in some emacs buffer
$ y = sin(x)^2 $
With the cursor in the formula, activate calc-embedded mode
M-x calc-embedded
Switch the display language to C:
M-x calc-c-language
There you are:
$ y == pow(sin(x), 2) $
Note that it interprets the '=' sign in latex as an equality, which results in '==' for C. The latex equivalent to Cs assignment operator '=' would be '\gets'.
More on this topic on Turong's blog
I know the question is too old, but I'll just add a reply anyway as a think it might help someone else later. The question popped up a lot for me in my searches.
I'm working on a tool that does something similar, in a public git repo
You'll have to put some artificial limitations on your latex input, that's out of question.
Currently the tool I wrote only supports mul, div, add, sub, sqrt, pow, frac and sum as those are the only set of operations I need to handle, and the imposed limitations can be a bit loose by providing a preprocessor (see preproc.l for an [maybe not-so-good] example) that would clean away the raw latex input.
A mathematical equation, such as the ones in LaTeX, and a C expression are not interchangeable. The former states a relation between two terms, the latter defines an entity that can be evaluated, unambiguously yielding one value. a = b in C means 'take the value in variable b and store it in variable a', wheres in Math, it means 'in the current context, a and b are equal'. The first describes a computation process, the second describes a static fact. Consequently, the Math equation can be reversed: a = b is equivalent to b = a, but doing the same to the C equation yields something quite different.
To make matters worse, LaTeX formulae only contain the information needed to render the equations; often, this is not enough to capture their meaning.
Of course some LaTeX formulae, like your example, can be converted into C computations, but many others cannot, so any automated way of doing so would only make limited sense.
I'm not sure there is a simple answer, because mathematical formulaes (in LaTeX documents) are actually ambiguous, so to automate their translation to some code requires automating their understanding.
And the MathML standard has, IIRC, two forms representing formulaes (one for displaying, another for computing) and there is some reason for that.
I'm trying to parse a syntax using the Shunting Yard (SY) algorithm. The syntax includes the following commands (they're are many many others though!)
a + b // a and b are numbers
setxy c d //c,d can be numbers
setxy c+d b+a //all numbers
Essentially, setxy is a function but it doesn't expect any function argument separators. This makes it very difficult (impossible?) to do via SY due to the lack of parens and function argument separators.
Any idea if SY can be used to parse a parentheses-less/function argument separator-less function or should I move on to a different parsing algorithm? If so, which one would you recommend?
Thanks!
djs22
Having defined correct grammar you can make http://www.antlr.org/ generate parser for you. Whether it is appropriate solution depends on your homework "requirements".
At least you can generate it and look inside for some hints.
I don't fully understand what you are trying to do, but perhaps you could use some regex? what are you trying to do write a simple command line program?