I try to understand several weeks the principles of operation with clang
AST, but meanwhile I did not answer the main issue: how to walk on this
tree?
I read all guides which I found, studied doxygen documentation and even
watched couple of lectures on YouTube, however the understanding did not
come.
That I understood:
1) AST of a tree has no general type of nodes
2) For movement on a tree it is offered to use either RecursiveASTVisitor,
or matcher. The first recursively realizes bypass in depth, and the second
allows to look for those nodes which are interesting.
The problem is in what part of a tree I am in what in one of two options I
cannot learn. I do not know how to define at what moment my visitor passed
to other branch and at what moment continues to move to depth.
Ideally it would be desirable to know depth of the node visited by me. It is
possible?
I very much like a dump() function output because in it communications
between nodes are accurately shown. However how to receive it in pure form
(but not as the text) I do not know.
Generally, the question is as follows: whether I can construct the tree on
the basis of AST, but with uniform type of nodes and how to make it?
I have a huge problem. I need to solve a non linear sistem of 3 equations in 3 variables with a C++ function or class. I thought about using Newton-Raphson method to perform the solution. Unlukily I didn't find a source code that can do that for me. There would be someone that knows a program like that? I'm near deciding to build it myself. Thanks
A 3x3 system is not huge; it's actually a very small problem. People routinely solve nonlinear systems of equations with thousands (and more) of variables and constraints.
Given that your system is 3x3 and possibly nasty, a more appropriate choice of method would be a line search method. You get global convergence to a local minimum of the residual this way; it's very easy to make straight Newton's method diverge.
Steepest descent with backtracking line search is the simplest line search method possible. You might try implementing it first.
First, see related questions What good libraries are there for solving a system of non-linear equations in C++? and https://stackoverflow.com/questions/4914967/could-you-explain-how-newton-raphson-for-a-set-of-equations-works-code-inside. Also, try to use boost.
Consider this cozy C++ library
I sunk about a month of full time into a native C++ equation parser. It works, except it is slow (between 30-100 times slower than a hard-coded equation). What can I change to make it faster?
I read everything I could find on efficient code. In broad strokes:
The parser converts a string equation expression into a list of "operation" objects.
An operation object has two function pointers: a "getSource" and a "evaluate".
To evaluate an equation, all I do is a for loop on the operation list, calling each function in turn.
There isn't a single if / switch encountered when evaluating an equation - all conditionals are handled by the parser when it originally assigned the function pointers.
I tried inlining all the functions to which the function pointers point - no improvement.
Would switching from function pointers to functors help?
How about removing the function pointer framework, and instead creating a full set of derived "operation" classes, each with its own virtual "getSource" and "evaluate" functions? (But doesn't this just move the function pointers into the vtable?)
I have a lot of code. Not sure what to distill / post. Ask for some aspect of it, and ye shall receive.
In your post you don't mention that you have profiled the code. This is the first thing I would do if I were in your shoes. It'll give you a good idea of where the time is spent and where to focus your optimization efforts.
It's hard to tell from your description if the slowness includes parsing, or it is just the interpretation time.
The parser, if you write it as recursive-descent (LL1) should be I/O bound. In other words, the reading of characters by the parser, and construction of your parse tree, should take a lot less time than it takes to simply read the file into a buffer.
The interpretation is another matter.
The speed differential between interpreted and compiled code is usually 10-100 times slower, unless the basic operations themselves are lengthy.
That said, you can still optimize it.
You could profile, but in such a simple case, you could also just single-step the program, in the debugger, at the level of individual instructions.
That way, you are "walking in the computer's shoes" and it will be obvious what can be improved.
Whenever I'm doing what you're doing, that is, providing a language to the user, but I want the language to have fast execution, what I do is this:
I translate the source language into a language I have a compiler for, and then compile it on-the-fly into a .dll (or .exe) and run that.
It's very quick, and I don't need to write an interpreter or worry about how fast it is.
The very first thing is: Profile what actually went wrong. Is the bottleneck in parsing or in evaluation? valgrind offers some tools that can help you here.
If it's in parsing, boost::spirit might help you. If in evaluation, remember that virtual functions can be pretty slow to evaluate. I've made pretty good experiences with recursive boost::variant's.
You know, building an expression recursive descent parser is really easy, the LL(1) grammar for expressions is only a couple of rules. Parsing then becomes a linear affair and everything else can work on the expression tree (while parsing basically); you'd collect the data from the lower nodes and pass it up to the higher nodes for aggregation.
This would avoid altogether function/class pointers to determine the call path at runtime, relying instead of proven recursivity (or you can build an iterative LL parser if you wish).
It seems that you're using a quite complicated data structure (as I understand it, a syntax tree with pointers etc.). Thus, walking through pointer dereference is not very efficient memory-wise (lots of random accesses) and could slow you down significantly. As Mike Dunlavey proposed, you could compile the whole expression at runtime using another language or by embedding a compiler (such as LLVM). For what I know, Microsoft .Net provides this feature (dynamic compilation) with Reflection.Emit and Linq.Expression trees.
This is one of those rare times that I'd advise against profiling just yet. My immediate guess is that the basic structure you're using is the real source of the problem. Profiling the code is rarely worth much until you're reasonably certain the basic structure is reasonable, and it's mostly a matter of finding which parts of that basic structure can be improved. It's not so useful when what you really need to do is throw out most of what you have, and basically start over.
I'd advise converting the input to RPN. To execute this, the only data structure you need is a stack. Basically, when you get to an operand, you push it on the stack. When you encounter an operator, it operates on the items at the top of the stack. When you're done evaluating a well-formed expression, you should have exactly one item on the stack, which is the value of the expression.
Just about the only thing that will usually give better performance than this is to do like #Mike Dunlavey advised, and just generate source code and run it through a "real" compiler. That is, however, a fairly "heavy" solution. If you really need maximum speed, it's clearly the best solution -- but if you just want to improve what you're doing now, converting to RPN and interpreting that will usually give a pretty decent speed improvement for a small amount of code.
Is there any good tutorials on how to do a playfair encryption and decryption in C++?
regards,
newbie
This is one of the rare questions where we can reasonably say no, there's no such thing.
Playfair encryption is not cryptographically safe. You would be able to find tutorials for modern, complex algorithms which are safe. However, you're learning C++, so a simple algorithm is indeed a better exercise.
Now, how should you approach such a problem then? The first thing to do is perform the task manually. If you can't do it yourself, there's no point in trying to "explain" the algorithm to a computer.
The second task is to identify the parts of a C++ program in the algorithm. Clearly, the "square" in the algorithm is a core data structure, and there are many functions that you perfrom with it. The conclusion is that the square should be the main class for your application. The square is initialized with a codeword, so the class constructor should take a string. Make a list of other well-defined tasks; those become methods of the class. E.g. the insertion of X to separate duplicate characters is one clear task. (And you need a special case to separate XX). If you're using the 5x5 algorithm, removing the 26th letter is another function.
I created a program using dev-cpp and wxwidgets which solves a puzzle.
The user must fill the operations blocks and the results blocks, and the program will solve it. I'm solving it using brute force, I generate all non-repeated 9 length number combinations using a recursive algorithm. It does it pretty fast.
Up to here all is great!
But the problem is when my program operates depending the character on the blocks. Its extremely slow (it never gets the answer), because of the chars comparation against +, -, *, etc. I'm doing a CASE.
Is there some way or some programming language which allows dynamic creation of operators? So I can define the operator ROW1COL2 to be a +, and the same way to all other operations.
I leave a screenshot of the app, so its easier to understand how the puzzle works.
http://www.imageshare.web.id/images/9gg5cev8vyokp8rhlot9.png
PD: The algorithm works, I tried it with a trivial puzzle, and solved it in a second.
Not sure that this is really what you're looking for but..
Any Object Oriented language such as C++ or C# will allow you to create an "Operator" base class and then to derive from this base class a "PlusOperator" or "MinusOperator" etc'. this is the standard way to avoid such case statements.
However I am not sure this will solve your performance problem.
Using plain brute force for such a problem will result you in an exponential solution. this will seem to work fast for small input - say completing all the numbers. But if you want to complete the operations its a much larger problem with alot more possibilities.
So its likely that even without the CASE your program is not going to be able to solve it.
The right way to try to solve this kind of problems is using some advanced search methods which use some Heuristic function. See the A* (A-star) algorithm for example.
Good luck!
You can represent the numbers and operators as objects, so the parsing is done only once in the beginning of the solving.