I was going to write a SymPy function which takes a natural number and returns the step number of Collatz conjecture of the arg. The Python version is here:
def collatz(n: int):
step = 0
while n != 1:
n = n // 2 if n % 2 == 0 else 3 * n + 1
step += 1
return step
print(collatz(27))
It prints 111.
How about SymPy version? I feel sympy.Lambda() should have a recursive feature, similar to recursive call of procedual programming. Is there a good way?
Just calling collatz() with a sympy.Symbol() instance (obviously) went into iloop.
sympy.series.sequences.RecursiveSeq() does only backward reference with constant decrements.
Let f(x) be the symbolic collatz result. Do a substitution followed by a replacement to replace any non-symbolic results:
>>> f=Function('f')
>>> eq = f(x)
>>> eq.subs(x, 270)
f(270)
>>> _.replace(lambda x: x.func == f and x.args[0].is_Integer, lambda x: collatz(x.args[0]))
42
If you don't want to do it like this and want automatic evaluation, then you will have to write a SymPy class deriving from Function that has an eval method that detects when the input is an Integer. You can look at any function to see how this is implemented, e.g. see the source code for cos.
Related
I the following code
f = lambda x: 2**(x+1)
f_sym = f(sympy.symbol.symbols('x'))
print f_sym.args
The output is (2, x+1).
Why the output is not x?
I have some functions composed with functions like the previous one and the final expressions do not simplify:
f = lambda x, y: (x/y)**.5
f_sym = f(sympy.symbol.symbols('x'), sympy.symbol.symbols('y'))
symbols = f_sym.free_symbols
aux = np.asarray([sympy.derive_by_array(f_sym, symbol) for symbol in [symbols]])
uc_matrix = np.diag(sympy.symbols(','.join(['u_{%s}'%symbol for symbol in symbols])))**2
uf = ((np.dot(np.dot(aux,uc_matrix), aux.T))**.5)[0][0]
y = uf/f_sym
print (y**2).expand().simplify()
In SymPy terms, f_sym is the expression
Pow(Integer(2), Add(Symbol('x'), Integer(1)))
as you can find from srepr(f_sym). So, the function is "raising to power" and the arguments of that function are 2 and x+1.
If you want specifically the exponent, f_sym.args[1] will return that.
It's important to recognize that f_sym is not a function. It does not take any arguments and does not return anything. It's a SymPy expression. There is no special meaning of x+1 within this expression: it's just one of its parts, like the number 2 is.
To answer your follow-up question: the expression will simplify to
u_{x}**2/(4*x**2) + u_{y}**2/(4*y**2)
if you use the rational number sympy.Rational(1, 2) instead of floating-point number .5 in the exponent. Floating point numbers are poison for SymPy. Other ways to achieve the same effect, with less to type:
use sympy.sqrt function instead of raising to power 1/2.
write sympy.S(1)/2 which creates the same Rational object because 1 is turned into a SymPy object prior to division.
Reference: Python numbers vs. SymPy Numbers
I've been experimenting with various prime sieves in Julia with a view to finding the fastest. This is my simplest, if not my fastest, and it runs in around 5-6 ms on my 1.80 GHz processor for n = 1 million. However, when I add a simple 'if' statement to take care of the cases where n <= 1 or s (the start number) > n, the run-time increases by a factor of 15 to around 80-90 ms.
using BenchmarkTools
function get_primes_1(n::Int64, s::Int64=2)::Vector{Int64}
#=if n <= 1 || s > n
return []
end=#
sieve = fill(true, n)
for i = 3:2:isqrt(n) + 1
if sieve[i]
for j = i ^ 2:i:n
sieve[j]= false
end
end
end
pl = [i for i in s - s % 2 + 1:2:n if sieve[i]]
return s == 2 ? unshift!(pl, 2) : pl
end
#btime get_primes_1(1_000_000)
Output with the 'if' statement commented out, as above, is:
5.752 ms (25 allocations: 2.95 MiB)
Output with the 'if' statement included is:
86.496 ms (2121646 allocations: 35.55 MiB)
I'm probably embarrassingly ignorant or being terminally stupid, but if someone could point out what I'm doing wrong it would be very much appreciated.
The problem of this function is with Julia compiler having problems with type inference when closures appear in your function. In this case the closure is a comprehension and the problem is that if statement makes sieve to be only conditionally defined.
You can see this by moving sieve up:
function get_primes_1(n::Int64, s::Int64=2)::Vector{Int64}
sieve = fill(true, n)
if n <= 1 || s > n
return Int[]
end
for i = 3:2:isqrt(n) + 1
if sieve[i]
for j = i ^ 2:i:n
sieve[j]= false
end
end
end
pl = [i for i in s - s % 2 + 1:2:n if sieve[i]]
return s == 2 ? unshift!(pl, 2) : pl
end
However, this makes sieve to be created also when n<1 which you want to avoid I guess :).
You can solve this problem by wrapping sieve in let block like this:
function get_primes_1(n::Int64, s::Int64=2)::Vector{Int64}
if n <= 1 || s > n
return Int[]
end
sieve = fill(true, n)
for i = 3:2:isqrt(n) + 1
if sieve[i]
for j = i ^ 2:i:n
sieve[j]= false
end
end
end
let sieve = sieve
pl = [i for i in s - s % 2 + 1:2:n if sieve[i]]
return s == 2 ? unshift!(pl, 2) : pl
end
end
or avoiding an inner closure for example like this:
function get_primes_1(n::Int64, s::Int64=2)::Vector{Int64}
if n <= 1 || s > n
return Int[]
end
sieve = fill(true, n)
for i = 3:2:isqrt(n) + 1
if sieve[i]
for j = i ^ 2:i:n
sieve[j]= false
end
end
end
pl = Int[]
for i in s - s %2 +1:2:n
sieve[i] && push!(pl, i)
end
s == 2 ? unshift!(pl, 2) : pl
end
Now you might ask how can you detect such problems and make sure that some solution solves them? The answer is to use #code_warntype on a function. In your original function you will notice that sieve is Core.Box which is an indication of the problem.
See https://github.com/JuliaLang/julia/issues/15276 for details. In general this is in my perception the most important issue with performance of Julia code which is easy to miss. Hopefully in the future the compiler will be smarter with this.
Edit: My suggestion actually doesn't seem to help. I missed your output annotation, so the return type appears to be correctly inferred after all. I am stumped, for the moment.
Original answer:
The problem isn't that there is an if statement, but that you introduce a type instability inside that if statement. You can read about type instabilities in the performance section of the Julia manual here.
An empty array defined like this: [], has a different type than a vector of integers:
> typeof([1,2,3])
Array{Int64,1}
> typeof([])
Array{Any,1}
The compiler cannot predict what the output type of the function will be, and therefore produces defensive, slow code.
Try to change
return []
to
return Int[]
This is a homework. OCaml seems to be made by a psychopath.
let prime : int -> bool
= fun n ->
if n > 2 then
let a = n - 1 in
let rec divisor n a =
if a > 1 && n mod a = 0 then false
else if a = 2 && n mod a <> 0 then true
else divisor n a-1 ;;
else if n = 2 then true
else if n = 1 then false
I am not good at coding and I know that my isPrime algorithm is wrong.
But I wonder where in my code is the mistake that produces the syntax error.
Also is there any way to define the isPrime function in a recursive form?
Example:
let rec prime n = ~
You'll get better responses from experts if you don't gratuitously insult their language :-) But I'm an easygoing guy, so I'll take a stab at your syntax error.
There are quite a few problems in this code. Here are 3 that I see right off:
The symbol ;; is used to tell the interpreter that you've entered a full expression that you want it to evaluate. It's definitely out of place in the middle of a function declaration.
Your second let doesn't have an associated in. Every let must have an in after it. The only exception is for defining values at the top level of a module (like your prime function).
The expression divisor n a-1 is parsed as (divisor n a) - 1. You want parentheses like this: divisor a (n - 1).
What would be the most efficient algorithm to solve a linear equation in one variable given as a string input to a function? For example, for input string:
"x + 9 – 2 - 4 + x = – x + 5 – 1 + 3 – x"
The output should be 1.
I am considering using a stack and pushing each string token onto it as I encounter spaces in the string. If the input was in polish notation then it would have been easier to pop numbers off the stack to get to a result, but I am not sure what approach to take here.
It is an interview question.
Solving the linear equation is (I hope) extremely easy for you once you've worked out the coefficients a and b in the equation a * x + b = 0.
So, the difficult part of the problem is parsing the expression and "evaluating" it to find the coefficients. Your example expression is extremely simple, it uses only the operators unary -, binary -, binary +. And =, which you could handle specially.
It is not clear from the question whether the solution should also handle expressions involving binary * and /, or parentheses. I'm wondering whether the interview question is intended:
to make you write some simple code, or
to make you ask what the real scope of the problem is before you write anything.
Both are important skills :-)
It could even be that the question is intended:
to separate those with lots of experience writing parsers (who will solve it as fast as they can write/type) from those with none (who might struggle to solve it at all within a few minutes, at least without some hints).
Anyway, to allow for future more complicated requirements, there are two common approaches to parsing arithmetic expressions: recursive descent or Dijkstra's shunting-yard algorithm. You can look these up, and if you only need the simple expressions in version 1.0 then you can use a simplified form of Dijkstra's algorithm. Then once you've parsed the expression, you need to evaluate it: use values that are linear expressions in x and interpret = as an operator with lowest possible precedence that means "subtract". The result is a linear expression in x that is equal to 0.
If you don't need complicated expressions then you can evaluate that simple example pretty much directly from left-to-right once you've tokenised it[*]:
x
x + 9
// set the "we've found minus sign" bit to negate the first thing that follows
x + 7 // and clear the negative bit
x + 3
2 * x + 3
// set the "we've found the equals sign" bit to negate everything that follows
3 * x + 3
3 * x - 2
3 * x - 1
3 * x - 4
4 * x - 4
Finally, solve a * x + b = 0 as x = - b/a.
[*] example tokenisation code, in Python:
acc = None
for idx, ch in enumerate(input):
if ch in '1234567890':
if acc is None: acc = 0
acc = 10 * acc + int(ch)
continue
if acc != None:
yield acc
acc = None
if ch in '+-=x':
yield ch
elif ch == ' ':
pass
else:
raise ValueError('illegal character "%s" at %d' % (ch, idx))
Alternative example tokenisation code, also in Python, assuming there will always be spaces between tokens as in the example. This leaves token validation to the parser:
return input.split()
ok some simple psuedo code that you could use to solve this problem
function(stinrgToParse){
arrayoftokens = stringToParse.match(RegexMatching);
foreach(arrayoftokens as token)
{
//now step through the tokens and determine what they are
//and store the neccesary information.
}
//Use the above information to do the arithmetic.
//count the number of times a variable appears positive and negative
//do the arithmetic.
//add up the numbers both positive and negative.
//return the result.
}
The first thing is to parse the string, to identify the various tokens (numbers, variables and operators), so that an expression tree can be formed by giving operator proper precedences.
Regular expressions can help, but that's not the only method (grammar parsers like boost::spirit are good too, and you can even run your own: its all a "find and recourse").
The tree can then be manipulated reducing the nodes executing those operation that deals with constants and by grouping variables related operations, executing them accordingly.
This goes on recursively until you remain with a variable related node and a constant node.
At the point the solution is calculated trivially.
They are basically the same principles that leads to the production of an interpreter or a compiler.
Consider:
from operator import add, sub
def ab(expr):
a, b, op = 0, 0, add
for t in expr.split():
if t == '+': op = add
elif t == '-': op = sub
elif t == 'x': a = op(a, 1)
else : b = op(b, int(t))
return a, b
Given an expression like 1 + x - 2 - x... this converts it to a canonical form ax+b and returns a pair of coefficients (a,b).
Now, let's obtain the coefficients from both parts of the equation:
le, ri = equation.split('=')
a1, b1 = ab(le)
a2, b2 = ab(ri)
and finally solve the trivial equation a1*x + b1 = a2*x + b2:
x = (b2 - b1) / (a1 - a2)
Of course, this only solves this particular example, without operator precedence or parentheses. To support the latter you'll need a parser, presumable a recursive descent one, which would be simper to code by hand.
Hey,
So I have a maple program which does bisection method and I have to convert it to C++. I tried converting it according to what the code generation help on the maple forums said but it kept throwing out errors. I would appreciate some help in this.
Thanks,
Here is the code for maple
Use the bisection method to solve the following mathematical problem:
a. smallest positive root of equation
f(x):=evalf(1/x-evalf(Pi)*cos(evalf(Pi)*x));
with delta = 10^-5 and eps = 10^-6
plot(f(x),x=.05..10.0);
From graph above we can conclude that given equation has smallest positive real root located between 0.0 and 2.0
To get their values with accuracy required we invoke bisection method with root isolation interval (0.01,2.0):
Bisect:=proc(funct_equation,ai,bi,Mi,epsfi,deltaxi) local k,M,a,b,u,v,w,c,e,epsf,deltax,feq, notsolved: M:=Mi: feq:=funct_equation: a:=ai: b:=bi: epsf:=epsfi: deltax:=deltaxi: notsolved:=true: u:=evalf(subs(x=a,feq)): v:=evalf(subs(x=b,feq)): printf("a=%+9.6f %+12.6e\nb=%+9.6f %+12.6e\n\n",a,u,b,v); e:=b-a; if (sign(u)<>sign(v)) then printf(" n x f\n"); for k from 1 by 1 while (k<M and notsolved) do:
e:=0.5*e;
c:=a+e;
w:=evalf(subs(x=c,feq)):
printf("%2d %+9.6f %+12.6e\n",k,c,w);
if (abs(e)<deltax or abs(w)<epsf) then
notsolved:=false:
else
if (sign(w) <> sign(u)) then
b:=c: v:=w:
else
a:=c: u:=w:
fi:
fi: od: printf("Root = %+9.6f function = %+12.6e\n",0.5*(a+b),evalf(subs(x=0.5*(a+b),feq))); fi: end: with(plots):
Warning, the name change coords has been redefined
Bisect(f(x),0.01,2.0,30,1.0e-6,1.0e-5):
You won't need that subs call, if you keep your feq as a procedure.
restart:
Bisect:=proc(func::procedure,ai,bi,Mi,epsfi,deltaxi)
local k::integer,
M::integer,
a,b,u,v,
w::float,
c,e,
epsf::float,
deltax,
notsolved;
M:=Mi:
a:=ai: b:=bi: epsf:=epsfi:
deltax:=deltaxi: notsolved:=true:
u:=func(a);
v:=func(b);
printf("a=%+9.6f %+12.6e\nb=%+9.6f %+12.6e\n\n",a,u,b,v);
e:=b-a;
if (sign(u)<>sign(v)) then
printf(" n x f\n");
for k from 1 by 1 while (k<M and notsolved) do
e:=0.5*e;
c:=a+e;
w:=func(c);
printf("%2d %+9.6f %+12.6e\n",k,c,w);
if (abs(e)<deltax or abs(w)<epsf) then
notsolved:=false:
else
if (sign(w) <> sign(u)) then
b:=c: v:=w:
else
a:=c: u:=w:
fi:
fi:
od:
printf("Root = %+9.6f function = %+12.6e\n",0.5*(a+b),func(0.5*(a+b),feq));
fi:
0.5*(a+b);
end:
with(plots):
f:=subs(Pi=evalf[16](Pi),proc(x::float) 1/x-Pi*cos(Pi*x); end proc);
Bisect(f,0.01,2.0,30,1.0e-6,1.0e-5);
f(%);
CodeGeneration[C](f);
CodeGeneration[C](Bisect);
Also, if you start with an expression for f, you can always turn it into an operator (a sort of procedure, but which too can be code-generated) using the unapply command.
For example, I could also have created the procedure f in the following ways. (Note that one of these produces a default 10-digits approximation to Pi in the generated C code, and the other a 16-digit approximation.)
f_expression := 1/x-Pi*cos(Pi*x);
f:=unapply(f_expression, [x::float]);
CodeGeneration[C](f);
f:=subs(Pi=evalf[16](Pi),unapply(f_expression, [x::float]));
CodeGeneration[C](f);