In data structures, I get converting in order and pre-order formula conversions into trees. However, I'm not so good with post-order.
For the given formula x y z + a b - c * / -
I came up with
-
/ \
* / (divide)
/ \ / \
x + - c
/ \ /\
y z a b
For the most part, this seems to fit, except the * in the left subtree is the joker in the deck. In post order traversal, the last character is the top node of the tree, everything else branches down. Now I take the / and * operators to mean that they should be on opposing nodes. However, when traversing tree, everything fits except for the *, since the left subtree has to work up to the node prior to the root, then switch over to the right subtree.
A nudge in the right direction is appreciated.
Go in order. First, write out the entire stack again:
x y z + a b - c * / -
Now, starting at the left, look for the first operator. Replace it and the previous two operands, right there in the stack, with a little in-order bit:
x (y + z) a b - c * / -
Continue with the next operator:
x (y + z) (a - b) c * / -
Then the next:
x (y + z) ((a - b) * c) / -
x ((y + z) / ((a - b) * c)) -
x - ((y + z) / ((a - b) * c))
Now, to make it a tree, just start at the middle (which you already know as it's the last element in the original stack), and hang parenthesized subexpressions from it, outside-to-inside.
Actually, it's easier to write a program that parses a post-order expression than one that parses it in-order, because you don't have to check the priorities of operations.
Try this: make a stack, and add to it the operands as you find them (left to right). When you find an operation, extract the number of operands it expects from the stack and put back a small tree. When you finish it, you'll have only one result in the stack : the final graph.
Ex:
x y z + -> x +
/ \
y z
Related
Prove the correctness of the following recursive algorithm to multiply two natural numbers, for all integer constants c ≥ 2.
function multiply(y,z) comment Return the product yz.
1. if z = 0 then return(0) else
2. return(multiply(cy, z/c) + y · (z mod c))
I saw this algorithm in “Algorithm Design Manual”.
I know why it works correctly, but I want to know how this algorithm came to be. Is that a good way to think of multiply two natural number with a constant c?
(multiply(cy, z/c) + y · (z mod c))
When c is the base of your representation (like decimal), then this is how multiplication can be done "manually". It's the "shift and add" method.
In c-base cy is a single shift of y to the left (i.e. adding a zero at the right); and z/c is a single shift of z to the right: the right most digit is lost.
That lost digit is actually z mod c, which is multiplied with y separately.
Here is an example with c = 10, where the apostrophe signifies the value of variables in a recursive call.
We perform the multiplication with y for each separate digit of z (retrieved with z mod c). Each next product found in this way is written shifted one more place to the left. Usually the 0 is not padded at the right of this shifted product, but it is silently assumed:
354 y
x 29 z
----
3186 y(z mod c) = 354·9 = 3186
+ 708 y'(z' mod c) = yc(z/c mod c) = 3540·2 = 7080
------
10266
So the algorithm just relies on the mathematical basis for this "shift and add" method in a given c-base.
We need to find the all possible subsets assuming the element used will be deleted.
test case
a=4 b=5
a b b
a b b
a a b
hence the answer is 3
Is there a general formula for doing this?
Let's say we have a = x and b = z. If we want to maximize the amount of groups we can make, we will want to pick 2 from the letter that we have most of. Let's say z > x. While this holds true, we will want to pick 2 from z and 1 from x.
Eventually 2 things can happen: either x got to 0, in which case we made x groups in total or x = z. If x = z, we can alternate taking 2 from one and 1 from the other until either both are 1 or both are 0. If both are 0, that means we used all z + x letters, so we made (z + x) / 3 groups. If both are 1, we used (z + x - 2) letters, so we made (z + x - 2 / 3) groups. Both these cases can be handled by floor((x + z) / 3).
So we have min(x, floor((x + z) / 3)) and if you assume x > z, you will also have to consider that x never got equal to z so you made z groups, thus leaving us with min(x, z, floor((x + z) / 3))
How could I implement a program that takes in the two sides of a trig equation (could be generalized to anything but for now I'll leave it at just trig identities) and the program will output the steps to transform one side into another (or transform them both) to show that they are in fact equal. The program will assume that they are equal in the first place. I am quite stumped as to how I might implement an algorithm to do this. My first thought was something to do with graphs, but I couldn't think of anything beyond this. From there, I thought that I should first parse both sides of the equation into trees. For example (cot x * sin) / (sin x + cos x) would look like this:
division
/ \
* +
/ \ / \
cot sin sin cos
After this, I had two similar ideas, both of which have problems. The first idea was to pick the side with the least number of leaves and try to manipulate it into the other side by using equivalencies that would be represented by "tree regexs." Examples of these "tree regexs" would be csc = 1 / sin or cot = cos / sin (in tree form of course), etc. My second idea would be to pick the side with more leaves and try to find some expression that when multiplied by that expression would equal the other side. Using reciprocals this wouldn't be too bad, however, I would then have to prove that the thing I multiplied by equals 1. Again I am back to this "tree regex" thing.
The major flaw with both of these is in what order/how could I apply these substitutions. Will it just have to be a big mess of if statements or is there a more elegant solution? Is there actually a graph-based solution that I'm not seeing. What (if any) might be a good algorithm to prove trig identities.
To be clear I am not talking about the "solve for x" type problem such as tan(x)sin(x) = 5, find all values of x but rather prove that sqrt((1 + sin x) / (1 - sin x)) = sec x + tan x
This is a simple algorithm for deciding trigonometric identities that can be brought into the form polynomial(sin x, cos x) = 0 :
Get rid of tan x, cot x, sec x, ..., sin 2x, ... by the obvious substitutions (tan x -> (sin x)/(cos x), ..., sin 2x -> 2 (sin x) (cos x), ...)
Transform identity to polynomial by squaring (isolated) roots (getting rid of multiple roots in an identity can be tricky, though), multiplying with denominators and bringing all expanded terms to one side
Replace all terms cos^2 x in the polynomial (cos^3 x = (cos^2 x)(cos x), cos^4 x = (cos^2 x)(cos^2 x), ...) by 1 - sin^2 x and expand the polynomial.
Finally a polynomial without cos^2 x is computed. If it is identical to 0 the identity is proven, otherwise the identity does not hold.
Your example sqrt((1 + sin x)/(1 - sin x)) = sec x + tan x:
Using the substitutions sec x -> 1/(cos x) and tan x -> (sin x)/(cos x) we get
sqrt((1 + sin x)/(1 - sin x)) = 1/(cos x) + (sin x)/(cos x).
For brevity let us write s instead of sin x and c instead of cos x, which gives us:
sqrt((1 + s)/(1 - s)) = 1/c + s/c
Squaring the equation and multiplying both sides with (1 - s)c^2 we get
(1 + s)c^2 = (1 + s)^2(1 - s).
Expanding the parenthesis and bringing everthing to one side we get
c^2 - sc^2 + s^3 + s^2 - s - 1 = 0
Substituting c^2 = 1 - s^2 into the polynomial we get
(1 - s^2) - s(1 - s^2) + s^3 + s^2 - s - 1 which expands to 0.
Hence the identity is proven.
Look out for texts on computer algebra (which I haven't), I'm sure you'll find clever ideas there.
My approach would be a graph-based search, as I doubt that a linear application of transformations will reliably lead to a solution.
Express the whole equation as an expression-tree the way you already started, but including an "equals" node above.
For the search-graph view, take one expression-tree as one search-state. The search-target is a decidable expression-tree like 1=1 or 1=0. When searching (expanding a search-state), create the child states by applying equivalence transformations on your expression (regex-like sounds quite plausible to me). Define an evaluation function that counts the overall complexity of an expression (e.g. number of nodes in the expression-tree). Do a directed search minimizing the evaluation function (expanding the lowest-complexity expression first), thus simplifying the expression until you reach a decidable form.
Depending on the expressions, it's quite possible that an unrestricted search never terminates. I don't know how you'd handle that, maybe by limiting the allowed complexity of expressions to some multiple of the original one. That would reduce the risk of running indefinitely, but leave you with undecided cases.
I was reading the code of the implementation of (^) of the standard haskell library :
(^) :: (Num a, Integral b) => a -> b -> a
x0 ^ y0 | y0 < 0 = errorWithoutStackTrace "Negative exponent"
| y0 == 0 = 1
| otherwise = f x0 y0
where -- f : x0 ^ y0 = x ^ y
f x y | even y = f (x * x) (y `quot` 2)
| y == 1 = x
| otherwise = g (x * x) ((y - 1) `quot` 2) x
-- g : x0 ^ y0 = (x ^ y) * z
g x y z | even y = g (x * x) (y `quot` 2) z
| y == 1 = x * z
| otherwise = g (x * x) ((y - 1) `quot` 2) (x * z)
Now this part where g is defined seems odd to me why not just implement it like this:
expo :: (Num a ,Integral b) => a -> b ->a
expo x0 y0
| y0 == 0 = 1
| y0 < 0 = errorWithoutStackTrace "Negative exponent"
| otherwise = f x0 y0
where
f x y | even y = f (x*x) (y `quot` 2)
| y==1 = x
| otherwise = x * f x (y-1)
But indeed plugging in say 3^1000000 shows that (^) is about 0,04 seconds faster than expo.
Why is (^) faster than expo?
As the person who wrote the code, I can tell you why it's complex. :)
The idea is to be tail recursive to get loops, and also to perform the minimum number of multiplications. I don't like the complexity, so if you find a more elegant way please file a bug report.
A function is tail-recursive if the return value of a recursive call is returned as-is, without further processing. In expo, f is not tail-recursive, because of otherwise = x * f x (y-1): the return value of f is multiplied by x before it is returned. Both f and g in (^) are tail-recursive, because their return values are returned unmodified.
Why does this matter? Tail-recursive functions can implemented much more efficiently than general recursive functions. Because the compiler doesn't need to create a new context (stack frame, what have you) for a recursive call, it can reuse the caller's context as the context of the recursive call. This saves a lot of the overhead of calling a function, much like in-lining a function is more efficient than calling the function proper.
Whenever you see a bread-and-butter function in the standard library and it's implemented weirdly, the reason is almost always "because doing it like that triggers some special performance-critical optimization [possibly in a different version of the compiler]".
These odd workarounds are usually to "force" the compiler to notice that some specific, important optimization is possible (e.g., to force a particular argument to be considered strict, to allow worker/wrapper transformation, whatever). Typically some person has compiled their program, noticed it's epicly slow, complained to the GHC devs, and they looked at the compiled code and thought "oh, GHC isn't seeing that it can inline that 3rd worker function... how do I fix that?" The result is that if you rephrase the code just slightly, the desired optimization then fires.
You say you tested it and there's not much speed difference. You didn't say for what type. (Is the exponent Int or Integer? What about the base? It's quite possible it makes a significant difference in some obscure case.)
Occasionally functions are also implemented weirdly to maintain strictness / laziness guarantees. (E.g., the library spec says it has to work a certain way, and implementing it the most obvious way would make the function more strict / less strict than the spec claims.)
I don't know what's up with this specific function, but I would suggest #chi is probably onto something.
While I'm still struggling to find a solution for this question, i have another one which maybe is easier. The following is the insert function of Okasaki red-black tree implementation. What I want to do is to keep the data unsorted as i insert into the tree. So the data always go to the leftmost/bottom-most leaf everytime i insert. There is no need to compare for x < y, x > y or x == y. It seems pretty straightforward at first by just removing these guards and only do: ins s#(T color a y b) = balance color (ins a) y b. The behaviour seems to be that the tree is kept balanced but the coloring becomes a bit messed up. And eventually that affects future inserts.. Any idea how this can be achieved? I think this could possibility my first step to my previous question. I just started playing with Haskell, so I am not getting it right straightforward. Thanks a lot.
insertSet x s = T B a y b
where ins E = T R E x E
ins s#(T color a y b) =
if x < y then balance color (ins a) y b
else if x > y then balance color a y (ins b)
else s
['d','a','s','f'] s
/\
a f
/
d (unsorted tree)
you can use my RBTree implementation in haskellDB,
http://hackage.haskell.org/package/RBTree
using the insert function:
insert :: (a -> a -> Ordering) -> RBTree a -> a -> RBTree a
feed it a (\_ _ -> LT) function, then you can always put new element into left-most place.