While attempting to enter any complex number in julia console e.g. 2+3im and then pressing the enter key, the output is same as the input, i.e. 2 + 3im. But upon entering the input is in rational form i.e. 1//2+1//5im, and upon pressing the enter key julia outputs 1//2 - 1//5*im.
kindly help
i am on ubuntu 18.
This happens because juxtaposition binds tighter than (almost?) all operators, so your input is parsed as
julia> 1//2 + 1//(5im)
1//2 - 1//5*im
instead of the
julia> 1//2 + (1//5)im
1//2 + 1//5*im
you wanted. That gives the opposite sign from what you expected, because of course im^(-1) == -im.
You need something to indicate that it is the rational number 1//5 which is imaginary and not just the 5.
julia> 1//2 + (1//5)im
1//2 + 1//5*im
julia> 1//2 + 1//5*im
1//2 + 1//5*im
whereas
julia> 1//2 + 1//(5*im)
1//2 - 1//5*im
Related
In Mathematica, if I do the following
Roots[x^3 - 2 == 0, x]
I get
x=(-1)^(2/3) 2^(1/3) || x=(-2)^(1/3) || x = 2^(1/3)
I want to do something similar in Sagemath
sage: F1.<x> = PolynomialRing(CC)
sage: f=x^3 - 2
sage: f.roots()
[(1.25992104989487, 1),
(-0.629960524947437 - 1.09112363597172*I, 1),
(-0.629960524947437 + 1.09112363597172*I, 1)]
Is there a way in sagemath to see it either as radicals or as ^(1/n) or something similar?
Is there a reason you need this computation to take place within a complex polynomial ring? I'm not an expert in computer algebra and I'm sure I'm oversimplifying or something, but I believe that is the root of this behavior; Sage treats the complex numbers as an inexact field, meaning that it stores the coefficients a and b in a+b*I as (default 53-bit) floats rather than as symbolic constants. Basically, what you are asking for is a type error, any object defined over the ComplexField (or ComplexDoubleField, or presumably any inexact field) will have floats as its coefficients. On the other hand, the corresponding behavior in the symbolic ring (where the token x lives by default) seems to be exactly what you are looking for; more specifically, evaluating var("t"); solve(t^3-2==0,t) returns [t == 1/2*I*sqrt(3)*2^(1/3) - 1/2*2^(1/3), t == -1/2*I*sqrt(3)*2^(1/3) - 1/2*2^(1/3), t == 2^(1/3)].
I typed the following in Julia's REPL:
julia> 6÷2(1+2)
1
julia> 6÷2*(1+2)
9
Why are the different results output?
Presh Talwalkar says 9 is correct in the movie
6÷2(1+2) = ? Mathematician Explains The Correct Answer - YouTube
YouTube notwithstanding, there is no correct answer. Which answer you get depends on what precedence convention you use to interpret the problem. Many of these viral "riddles" that go around periodically are contentious precisely because they are intentionally ambiguous. Not a math puzzle really, it's just a parsing problem. It's no deeper than someone saying a sentence with two interpretations. What do you do in that case in real life? You just ask which one they meant. This is no different. For this very reason, the ÷ symbol isn't often used in real mathematical notation—fraction notation is used instead, which clearly disambiguates this as either:
6
- (1 + 2) = 9
2
or as
6
--------- = 1
2 (1 + 2)
Regarding Julia specifically, this precedence behavior is documented here:
https://docs.julialang.org/en/v1/manual/integers-and-floating-point-numbers/#man-numeric-literal-coefficients
Specifically:
The precedence of numeric literal coefficients is slightly lower than that of unary operators such as negation. So -2x is parsed as (-2) * x and √2x is parsed as (√2) * x. However, numeric literal coefficients parse similarly to unary operators when combined with exponentiation. For example 2^3x is parsed as 2^(3x), and 2x^3 is parsed as 2*(x^3).
and the note:
The precedence of numeric literal coefficients used for implicit multiplication is higher than other binary operators such as multiplication (*), and division (/, \, and //). This means, for example, that 1 / 2im equals -0.5im and 6 // 2(2 + 1) equals 1 // 1.
Everything I've read about Elixir says that assignment should be thought of as pattern matching. If so then why does x = x + 1 work in Elixir? There is no value of x for which x = x + 1.
Everything I've read about Elixir says that assignment should be thought of as pattern matching.
In Elixir, = is called the pattern match operator, but it does not work the same way as the pattern match operator in Erlang. That's because in Elixir variables are not single assignment like they are in Erlang. Here's the way Erlang works:
~/erlang_programs$ erl
Erlang/OTP 20 [erts-9.3] [source] [64-bit] [smp:4:4] [ds:4:4:10] [async-threads:10] [hipe] [kernel-poll:false]
Eshell V9.3 (abort with ^G)
1> X = 15.
15
2> X = 100.
** exception error: no match of right hand side value 100
3> X.
15
4>
Therefore, in Erlang this fails:
4> X = X + 1.
** exception error: no match of right hand side value 16
Things are pretty simple with Erlang's single assignment: because X already has a value, the line X = X + 1 cannot be an attempt to assign a new value to X, so that line is an attempt to pattern match (15 = 15 + 1), which will always fail.
On the other hand, in Elixir variables are not single assignment:
Interactive Elixir (1.6.6) - press Ctrl+C to exit (type h() ENTER for help)
iex(1)> x = 15
15
iex(2)> x = 100
100
iex(3)> x
100
iex(4)>
The fact that variables are not single assignment in Elixir means that Elixir needs to make a choice when you write:
x = 10
x = x + 1 #or even x = 15
Choice 1) Should the second line be interpreted as assignment to x?
Choice 2) Should the second line be interpreted as an attempt to pattern match (i.e. 10 = 11)?
Elixir goes with Choice 1. That means that actually performing a pattern match with the so called pattern match operator in Elixir is more difficult: you have to use the pin operator(^) in conjunction with the match operator(=):
x = 10
^x = x + 1
Now, the second line will always fail. There is also a trick that will work in some situations if you want to perform pattern matching without using the pin operator:
x = 10
12 = x
In the second line, you put the variable on the right hand side. I think the rule can be stated like this: On the right hand side of the pattern match operator(=), variables are always evaluated, i.e. replaced with their values. On the left hand side variables are always assigned to--unless the pin operator is used, in which case a pinned variable is replaced by its current value and then pattern matched against the right hand side. As a result, it's probably more accurate to call Elixir's = operator a hybrid assignment/pattern match operator.
You can imagine x = x + 1 being rewritten by the compiler to something like x2 = x1 + 1.
This is pretty close to how it works. It's not a simple index number like I used here, but the concept is the same. The variables seen by the BEAM are immutable, and there is no rebinding going on at that level.
In Erlang programs, you'll find code like X2 = X1 + 1 all over. There are downsides to both approaches. José Valim made a conscious choice to allow rebinding of variables when he designed Elixir, and he wrote a blog post comparing the two approaches and the different bugs you run the risk of:
http://blog.plataformatec.com.br/2016/01/comparing-elixir-and-erlang-variables/
During the pattern matching, the values on the right of the match are assigned to their matched variables on the left:
iex(1)> {x, y} = {1, 2}
{1, 2}
iex(2)> x
1
iex(3)> y
2
On the right hand side, the values of the variables prior to the match are used. On the left, the variables are set.
You can force the left side to use a variable's value too, with the ^ pin operator:
iex(4)> x = 1
1
iex(5)> ^x = x + 1
** (MatchError) no match of right hand side value: 2
This fails because it's equivalent to 1 = 1 + 1, which is the failure condition you were expecting.
while working in julia programming, for creating an array instead of using a=[1:1:20...] i used a=[1:1:20] and it created an array saying "1-element Array{StepRange{Int64,Int64},1}".
What does this "1-element Array{StepRange{Int64,Int64},1}" mean? what StepRange means?
From the documentation of StepRange (type ?StepRange in the Julia REPL to see this):
StepRange{T, S} <: OrdinalRange{T, S}
Ranges with elements of type T with spacing of type S. The step
between each element is constant, and the range is defined in terms
of a start and stop of type T and a step of type S. Neither T nor S
should be floating point types. The syntax a:b:c with b > 1 and a,
b, and c all integers creates a StepRange.
So, for example
julia> typeof(1:1:20)
StepRange{Int64,Int64}
and
julia> [1:1:20]
1-element Array{StepRange{Int64,Int64},1}:
1:1:20
thus constructs a Vector (1D Array) containing one StepRange. If you want to materialize the lazy StepRange I would recommend collect(1:1:20) instead of using splatting ([1:1:20...]).
You can access start / step / stop fields of a StepRange using:
julia> r = 1:1:20
julia> r.start
1
julia> r.stop
20
julia> r.step
1
I've run across a little problem when trying to solve a Project Euler problem in Julia. I've basically written a recursive function which produces fractions with increasingly large numerators and denominators. I don't want to post the code for obvious reasons, but the last few fractions are as follows:
1180872205318713601//835002744095575440
2850877693509864481//2015874949414289041
6882627592338442563//4866752642924153522
At that point I get an OverflowError(), presumably because the numerator and/or denominator now exceeds 19 digits. Is there a way of handling 'Big' fractions in Julia (i.e. those with BigInt-type numerators and denominators)?
Addendum:
OK, I've simplified the code and disguised it a bit. If anyone wants to wade through 650 Project Euler problems to try to work out which question it is, good luck to them – there will probably be around 200 better solutions!
function series(limit::Int64, i::Int64=1, n::Rational{Int64}=1//1)
while i <= limit
n = 1 + 1//(1 + 2n)
println(n)
return series(limit, i + 1, n)
end
end
series(50)
If I run the above function with, say, 20 as the argument it runs fine. With 50 I get the OverflowError().
Julia defaults to using machine integers. For more information on this see the FAQ: Why does Julia use native machine integer arithmetic?.
In short: the most efficient integer operations on any modern CPU involves computing on a fixed number of bits. On your machine, that's 64 bits.
julia> 9223372036854775805 + 1
9223372036854775806
julia> 9223372036854775805 + 2
9223372036854775807
julia> 9223372036854775805 + 3
-9223372036854775808
Whoa! What just happened!? That's definitely wrong! It's more obvious if you look at how these numbers are represented in binary:
julia> bitstring(9223372036854775805 + 1)
"0111111111111111111111111111111111111111111111111111111111111110"
julia> bitstring(9223372036854775805 + 2)
"0111111111111111111111111111111111111111111111111111111111111111"
julia> bitstring(9223372036854775805 + 3)
"1000000000000000000000000000000000000000000000000000000000000000"
So you can see that those 63 bits "ran out of space" and rolled over — the 64th bit there is called the "sign bit" and signals a negative number.
There are two potential solutions when you see overflow like this: you can use "checked arithmetic" — like the rational code does — that ensures you don't silently have this problem:
julia> Base.Checked.checked_add(9223372036854775805, 3)
ERROR: OverflowError: 9223372036854775805 + 3 overflowed for type Int64
Or you can use a bigger integer type — like the unbounded BigInt:
julia> big(9223372036854775805) + 3
9223372036854775808
So an easy fix here is to remove your type annotations and dynamically choose your integer types based upon limit:
function series(limit, i=one(limit), n=one(limit)//one(limit))
while i <= limit
n = 1 + 1//(1 + 2n)
println(n)
return series(limit, i + 1, n)
end
end
julia> series(big(50))
#…
1186364911176312505629042874//926285732032534439103474303
4225301286417693889465034354//3299015554385159450361560051