I'm trying to obtain the real part of the result of an operation which involves an undefined variable (let's say x).
How can I have Mathematica return x when I execute Re[x] if I know that x will never be a complex number? I think this involves telling Mathematica that x is a real, but I don't know how.
In my case the expression for which I want the real part is more complicated than a simple variable, but the concept will remain the same.
Some examples:
INPUT OUTPUT DESIRED RESULT
----- ------ --------------
Re[x] Re[x] x
Re[1] 1 1
Re[Sin[x]] Re[Sin[x]] Sin[x]
Re[1+x+I] 1 + Re[x] 1+x
Re[1 + x*I] 1-Im[x] 1
You can use for example the input Simplify[Re[x], x \[Element] Reals] which will give x as output.
Use ComplexExpand. It assumes that the variables are real unless you indicate otherwise. For example:
In[76]:= ComplexExpand[Re[x]]
Out[76]= x
In[77]:= ComplexExpand[Re[Sin[x]]]
Out[77]= Sin[x]
In[78]:= ComplexExpand[Re[1+x+I]]
Out[78]= 1+x
Two more possibilities:
Assuming[x \[Element] Reals, Refine[Re[x]]]
Refine[Re[x], x \[Element] Reals]
Both return x.
It can at times be useful to define UpValues for a symbol. This is far from robust, but it nevertheless can handle a number of cases.
Re[x] ^= x;
Im[x] ^= 0;
Re[x]
Re[1]
Re[1 + x + I]
Re[1 + x*I]
x
1
1 + x
1
Re[Sin[x]] does not evaluate as you desire, but one of the transformations used by FullSimplify does place it in a form that triggers Re[x]:
Re[Sin[x]] // FullSimplify
Sin[x]
Related
Say that x and y are real numbers and y > 0. And say that I want to find for which values of A do (A + x + y > 0) and (A + x - y > 0) always hold, as long as x, y are in the domain.
How would I specify that on Wolfram Alpha? (Note: obviously these equations have no solution, but I just used it as an example.)
Or, if not on Wolfram, what software/website could I use?
I tried to write: solve for A: [input my first equation], y>0
but that didn't work, as it only gave integer solutions for when A, x, and y vary, instead of finding values of A such that it always holds no matter what x, y are.
https://www.wolframalpha.com/input?i=%28A+%2B+x+%2B+y+%3E+0%29+and+%28A+%2B+x+-+y+%3E+0%29+
[x>-A, -A - x<y<A + x]
I'm facing this problem, I want to derivate an expression with respect to a variable depending on another variable (not the actual expressions I'm using, they're way more long and complex):
y := x^2 + x + 1;
z := sqrt[y];
D[z, y]
General::ivar: 1+x+x^2 is not a valid variable.
I saw I can solve the problem if I expand the variables like this
D[sqrt[1 + x + x^2], x]
but for long expressions it doesn't seem viable. Is there a simpler way to solve this problem?
Thank you.
You are not consistent with your notations. If you replace D[z, y] by D[z, x], you will get the desired answer.
y := x^2 + x + 1;
z := Sqrt[y];
D[z, x]
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.
I'm to ask a question, which answers are solving this task:
Which right-angled triangles can be constructed by choosing three sides out of six segments of length being integers from 1 to 6
So, I'm thinking this is essential:
between(1,6,X),
between(1,6,Y),
between(1,6,Z),
Then we have to make sure it fits Pythagoras statement, so I'm trying this, adding to the above sentence:
(X^2 = Y^2 + Z^2 ;
Y^2 = X^2 + Z^2 ;
Z^2 = X^2 + Y^2)
Also I have been trying to replace X^2 with X*X, but it returns false every time. Why is that?
From my understanding, I need it to work like this:
Choose three sides from range 1-6, and make sure they fit Pythagoras statement. (Is triangle disparity also required here? I mean X>Y+Z,Y>X+Z,Z>X+Y ?
Check the prolog manual regarding the different comparators, etc. They mean and do various things. =:=/2 is specifically evaluates arithmetic expressions on either side and checks for equality of results. =/2 is not an equality operator; it performs prolog unification. It's important to know the difference. In your example, limiting all results to maximum of 6, then permutations of 3,4,5 are the only positive integer solutions to the right triangle.
?- between(1,6,X), between(1,6,Y), between(1,6,Z), Z^2 =:= X^2 + Y^2.
X = 3,
Y = 4,
Z = 5 ;
X = 4,
Y = 3,
Z = 5 ;
false.
This is an algorithm question that I've been struggling with. I figured I could get some insight here. I need to make the following function in Haskell:
Declare the type and define a function that takes two numbers as input and finds their product by addition. That is, add the first number, as many times as second number, to itself.
My problem is that this is basically just multiplying two numbers together, but it says that I need to do it with addition. Does anyone have any clue on how to do this?
This is all I can come up with (it's not right): (x + x) * y
Thank you
if a is the first number and b the second
sum $ take a $ cycle [b]
should do ot
mult (x, y):
sum = 0
for 1 to y:
sum = sum + x
return sum
This is just the algorithm. I do not know Haskell. So the lambda expression in the other answer may be more appropriate. Also, I use an intermediate variable.
PS: forget the previous embarrassing recursive algorithm
Work it out by induction.
We know the answer to one simple (the simplest) problem: multiplying anything by 0 yields 0. So we write:
mul x 0 = 0
Now, the inductive step: we can build a solution to a bigger problem, if we know a solution to the smaller problem; that way we can always reduce any big problem to the smallest problem, for which we know the solution. So, for any y, the solution for y+1 can be found by adding x to the solution for y: mul x (y+1) = x + (mul x y). In Haskell we can't write (y+1) on the left hand side, so we write equivalently:
mul x y = x + (mul x (y-1))
This function will keep adding x until y is zero.
Try this also
multiply::(Num a,Eq a) => a -> a -> a
multiply a 0 = 0
multiply a b = a + multiply a (b - 1)
main = print $ multiply 5 7