Re: [julia-users] All packages for numerical math
Hi, John.
No, I didn't. I didn't find it and it seems to be not what i need:
no method quadgk(Array{Float64,1}, Array{Float64,1})
quadgk(f,a,b,...) expects a function as its first argument but I mean the
case when y = f(x), but i don't have f, e.g. obtained experimental data, so
x and y are 1-D arrays of floats.
On Tue, Apr 22, 2014 at 7:49 PM, John Myles White
johnmyleswh...@gmail.comwrote:
Have you tried the quadgk function?
-- John
On Apr 22, 2014, at 7:32 AM, Evgeny Shevchenko e...@ya.ru wrote:
Hi
Is there a package for numeric integration of obtained arrays, say x and
y? Couldn't find one, the led me to use @pyimport and numpy.trapz.
--
pupoque@IRC
[julia-users] Carriage return without new line
I would like to periodically output a progress percentage but don't want a huge list of numbers cluttering the rest of the outputs. How can this be accomplished? print(hello) print(\rworld) This doesn't work because \r adds a new line.
Re: [julia-users] Carriage return without new line
Not on my machine julia print(hello);print(\rworld!) world! Which operation system and which version of Julia are you running? 2014-04-23 10:00 GMT+02:00 RecentConvert giz...@gmail.com: I would like to periodically output a progress percentage but don't want a huge list of numbers cluttering the rest of the outputs. How can this be accomplished? print(hello) print(\rworld) This doesn't work because \r adds a new line. -- Med venlig hilsen Andreas Noack Jensen
Re: [julia-users] Carriage return without new line
Julia Version 0.2.1 Commit e44b593* (2014-02-11 06:30 UTC) Platform Info: System: Windows (x86_64-w64-mingw32) Windows 7
Re: [julia-users] Carriage return without new line
I can confirm this behavior under 0.3 prerelease on windows. The following works however julia print(hello);print(\b\b\b\b\bworld!) world! I think this should be filed as an issue at https://github.com/JuliaLang/julia Am Mittwoch, 23. April 2014 10:35:09 UTC+2 schrieb RecentConvert: Julia Version 0.2.1 Commit e44b593* (2014-02-11 06:30 UTC) Platform Info: System: Windows (x86_64-w64-mingw32) Windows 7
Re: [julia-users] Carriage return without new line
print(hello);print(\b\b\b\ b\bworld!) This works in the basic terminal but *not* in Julia Studio.
Re: [julia-users] Carriage return without new line
Julia Studio is an entirely different issue as they might have implemented their own REPL (terminal). The issue should be reported here: https://github.com/forio/julia-studio/issues. Am Mittwoch, 23. April 2014 11:39:48 UTC+2 schrieb RecentConvert: print(hello);print(\b\b\b\ b\bworld!) This works in the basic terminal but *not* in Julia Studio.
Re: [julia-users] Carriage return without new line
Pkg.add(ProgressMeter) --Tim On Wednesday, April 23, 2014 01:00:50 AM RecentConvert wrote: I would like to periodically output a progress percentage but don't want a huge list of numbers cluttering the rest of the outputs. How can this be accomplished? print(hello) print(\rworld) This doesn't work because \r adds a new line.
[julia-users] julia nightlies current version
Is the Julia nightlies update every day as it used to do around January/February? I don't receive updates for a long time now, and I want to investigate whether it is a failed Xubuntu upgrade that killed the Sources, or the package really don't update. Thanks versioninfo() Julia Version 0.3.0-prerelease Platform Info: System: Linux (i686-linux-gnu) CPU: Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz WORD_SIZE: 32 BLAS: libblas.so.3 LAPACK: liblapack.so.3 LIBM: libopenlibm
Re: [julia-users] Carriage return without new line
Awesome! Did not know that. Am Mittwoch, 23. April 2014 12:22:25 UTC+2 schrieb Tim Holy: Pkg.add(ProgressMeter) --Tim On Wednesday, April 23, 2014 01:00:50 AM RecentConvert wrote: I would like to periodically output a progress percentage but don't want a huge list of numbers cluttering the rest of the outputs. How can this be accomplished? print(hello) print(\rworld) This doesn't work because \r adds a new line.
Re: [julia-users] julia nightlies current version
I think you are running Xubuntu Raring, which reached end of life, and so they stopped building nightly for that OS. I am on Trusty and am getting the nightly for Saucy. On 04/23/2014 06:26 PM, Földes László wrote: Is the Julia nightlies update every day as it used to do around January/February? I don't receive updates for a long time now, and I want to investigate whether it is a failed Xubuntu upgrade that killed the Sources, or the package really don't update. Thanks versioninfo() Julia Version 0.3.0-prerelease Platform Info: System: Linux (i686-linux-gnu) CPU: Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz WORD_SIZE: 32 BLAS: libblas.so.3 LAPACK: liblapack.so.3 LIBM: libopenlibm
Re: [julia-users] All packages for numerical math
The trapezoidal rule (http://en.wikipedia.org/wiki/Trapezoidal_rule) would
probably be almost trivial to implement.
function trapz{T:Real}(x::Vector{T}, y::Vector{T})
if (length(y) != length(x))
error(Vectors must be of same length)
end
sum( (x[2:end] .- x[1:end-1]).*(y[2:end].+y[1:end-1]) ) / 2
end
x = [0:0.01:pi]
y = sin(x)
trapz(x,y) # 1.820650436642
This, of course, only currently works on vectors of real numbers, but it's
easy to extend it if you want.
And there might be more accurate methods as well, of course (see
e.g. http://en.wikipedia.org/wiki/Simpson%27s_rule) but this one's often
good enough.
// T
On Wednesday, April 23, 2014 8:43:48 AM UTC+2, Evgeny Shevchenko wrote:
Hi, John.
No, I didn't. I didn't find it and it seems to be not what i need:
no method quadgk(Array{Float64,1}, Array{Float64,1})
quadgk(f,a,b,...) expects a function as its first argument but I mean the
case when y = f(x), but i don't have f, e.g. obtained experimental data, so
x and y are 1-D arrays of floats.
On Tue, Apr 22, 2014 at 7:49 PM, John Myles White
johnmyl...@gmail.comjavascript:
wrote:
Have you tried the quadgk function?
-- John
On Apr 22, 2014, at 7:32 AM, Evgeny Shevchenko eu...@ya.ru javascript:
wrote:
Hi
Is there a package for numeric integration of obtained arrays, say x and
y? Couldn't find one, the led me to use @pyimport and numpy.trapz.
--
pupoque@IRC
[julia-users] Inconsistency with single-line use of the do keyword?
I noticed that the do keyword behaves weirdly when trying to use it on a
single line, e.g. in the REPL:
When the do keyword is used to create a function with one or more
arguments everything works fine.
julia map([1,2,3]) do x 1+x end
map([1,2,3]) do x 1+x end
3-element Array{Int64,1}:
2
3
4
Without arguments, multi-line usage works fine ...
julia cd(c:/tmp) do
cd(c:/tmp) do
println(1)
end
1
... but single line usage fails ...
julia cd(c:/tmp) do println(1) end
cd(c:/tmp) do println(1) end
ERROR: syntax: malformed function arguments (call println 1)
... and a ; cannot be used to fix it:
julia cd(c:/tmp) do; println(1) end
cd(c:/tmp) do; println(1) end
ERROR: syntax: unexpected ;
Is this an actual inconsistency in the parsing or am I getting something
wrong about how julia handles single-line code? So far it is the first
example where I found a line-break to be both significant and not
replaceable by a semi-colon.
I am using the julia-0.2.1-win64 binary release.
Re: [julia-users] Inconsistency with single-line use of the do keyword?
Oops: https://github.com/JuliaLang/julia/issues/new – that's what I get for
entering URLs by hand.
On Wed, Apr 23, 2014 at 10:09 AM, Stefan Karpinski ste...@karpinski.orgwrote:
Would you mind opening an issue about it?
https://github.com/JuliaLang/issues/new
On Wed, Apr 23, 2014 at 8:46 AM, Klaus-Dieter Bauer
bauer.klaus.die...@gmail.com wrote:
I noticed that the do keyword behaves weirdly when trying to use it on
a single line, e.g. in the REPL:
When the do keyword is used to create a function with one or more
arguments everything works fine.
julia map([1,2,3]) do x 1+x end
map([1,2,3]) do x 1+x end
3-element Array{Int64,1}:
2
3
4
Without arguments, multi-line usage works fine ...
julia cd(c:/tmp) do
cd(c:/tmp) do
println(1)
end
1
... but single line usage fails ...
julia cd(c:/tmp) do println(1) end
cd(c:/tmp) do println(1) end
ERROR: syntax: malformed function arguments (call println 1)
... and a ; cannot be used to fix it:
julia cd(c:/tmp) do; println(1) end
cd(c:/tmp) do; println(1) end
ERROR: syntax: unexpected ;
Is this an actual inconsistency in the parsing or am I getting something
wrong about how julia handles single-line code? So far it is the first
example where I found a line-break to be both significant and not
replaceable by a semi-colon.
I am using the julia-0.2.1-win64 binary release.
Re: [julia-users] Inconsistency with single-line use of the do keyword?
Would you mind opening an issue about it?
https://github.com/JuliaLang/issues/new
On Wed, Apr 23, 2014 at 8:46 AM, Klaus-Dieter Bauer
bauer.klaus.die...@gmail.com wrote:
I noticed that the do keyword behaves weirdly when trying to use it on a
single line, e.g. in the REPL:
When the do keyword is used to create a function with one or more
arguments everything works fine.
julia map([1,2,3]) do x 1+x end
map([1,2,3]) do x 1+x end
3-element Array{Int64,1}:
2
3
4
Without arguments, multi-line usage works fine ...
julia cd(c:/tmp) do
cd(c:/tmp) do
println(1)
end
1
... but single line usage fails ...
julia cd(c:/tmp) do println(1) end
cd(c:/tmp) do println(1) end
ERROR: syntax: malformed function arguments (call println 1)
... and a ; cannot be used to fix it:
julia cd(c:/tmp) do; println(1) end
cd(c:/tmp) do; println(1) end
ERROR: syntax: unexpected ;
Is this an actual inconsistency in the parsing or am I getting something
wrong about how julia handles single-line code? So far it is the first
example where I found a line-break to be both significant and not
replaceable by a semi-colon.
I am using the julia-0.2.1-win64 binary release.
[julia-users] output sharing memory with input
Ok, so I've got not hits on this question. Let me try to make it more concrete: Is there a command which can tell me the variables `a` and `b` in the following commands are refering to the same space in memory: a = rand(2,2) b = vec(a) The command is(a,b) returns false. The documentation for vec doesn't give an indication that `a` and `b` are coupled. The reason I ask is that as array-views get implimented, I'm worried that functions like diagm, hcat and transpose will return values which are subtly coupled with the arguments used to call these functions. To avoid this sutle coupling between varibales in my code, do I need to append `copy` each time I call these? At the very least it would be nice to have something like whos() which can show me which variables are coupled in my current namespace. Thanks, Ethan
[julia-users] Re: output sharing memory with input
On Wednesday, April 23, 2014 12:11:50 PM UTC-4, Ethan Anderes wrote: Ok, so I've got not hits on this question. Let me try to make it more concrete: Is there a command which can tell me the variables `a` and `b` in the following commands are refering to the same space in memory: a = rand(2,2) b = vec(a) The command is(a,b) returns false. pointer(a) == pointer(b) returns true.
[julia-users] Re: output sharing memory with input
Thanks Steven. That helps. So I can infer that no two variables can share overlapping memory without their pointers being the same?
Re: [julia-users] output sharing memory with input
No, that is not necessarily true. For example, a subarray could point somewhere inside the array, and most objects don't have a pointer method. The easiest assumption (which is probably also typically correct) is that the output of all functions share part of the memory of its inputs. Therefore, after passing an object into a function, it is generally best to make a copy if you want to mutate the object. The ! convention perhaps actually indicates the opposite: after the function call you maintain full freedom to mutate the input arguments. On Wednesday, April 23, 2014, Ethan Anderes ethanande...@gmail.com wrote: Thanks Steven. That helps. So I can infer that no two variables can share overlapping memory without their pointers being the same?
Re: [julia-users] output sharing memory with input
Still, if you're using Arrays, then under typical conditions there is absolutely no overlap between a and b unless pointer(a)==pointer(b). You can violate that yourself if you want to (using pointer_to_array), but in such circumstances you presumably know what you are doing. --Tim On Wednesday, April 23, 2014 02:17:07 PM Jameson Nash wrote: No, that is not necessarily true. For example, a subarray could point somewhere inside the array, and most objects don't have a pointer method. The easiest assumption (which is probably also typically correct) is that the output of all functions share part of the memory of its inputs. Therefore, after passing an object into a function, it is generally best to make a copy if you want to mutate the object. The ! convention perhaps actually indicates the opposite: after the function call you maintain full freedom to mutate the input arguments. On Wednesday, April 23, 2014, Ethan Anderes ethanande...@gmail.com wrote: Thanks Steven. That helps. So I can infer that no two variables can share overlapping memory without their pointers being the same?
Re: [julia-users] output sharing memory with input
Ok, I'm trying to reconcile Jameson's suggestion to generally assume an overlap, and Tim's to expect no overlap with arrays if pointer(a) != pointer(b). Doesn't this imply that pointer(input) == pointer(output) a typical array function? With subarray's I fully expect sharing memory, just by the type of the output. I guess I had hoped that vec would have returned an array-view type or sub-array type to indicate what is happening. Side note: I've been preaching Julia to everyone I meet. I usually start the sermon with when you start using Julia it will initially behave/feel very much like R or Matlab, but then when you need the full power of a fast modern language it is there for you. Can I really say the first part of the sermon if I need to tell them to generally expect outputs sharing memory with inputs (which, to my knowledge, is very different from how matlab and R behave)? I hope I'm not sounding critical (cuz I love the language). Mainly, I want to really understand how things work so I can better sell it to students and colleagues. Cheers, Ethan
Re: [julia-users] output sharing memory with input
Jameson said if you're using subarrays, you can't count on it; I said if
they're both arrays, then you can rely on it (unless you've done something
sneaky). So depending on the types, either could be true.
In my personal opinion, the risk of memory sharing is quite a lot lower, in
practice, than Jameson's comment might have suggested. Unless I'm missing
something, in common usage there are three main situations where this is an
issue:
- reshaping (reshape, vec, etc)
- reinterpret
- allocation, e.g., mistakenly initializing a Vector{Vector{T}} with the same
underlying array for each element.
The first two don't currently return views, presumably because views don't
currently have the performance we want them to have. But I agree it might
become less confusing when we can return a view. Of course, once we switch to
returning views from indexing operations (rather than copies, like we
currently do), there will be new cases that might cause confusion.
--Tim
On Wednesday, April 23, 2014 11:51:56 AM Ethan Anderes wrote:
Ok, I'm trying to reconcile Jameson's suggestion to generally assume an
overlap, and Tim's to expect no overlap with arrays if pointer(a) !=
pointer(b). Doesn't this imply that pointer(input) == pointer(output) a
typical array function? With subarray's I fully expect sharing memory, just
by the type of the output. I guess I had hoped that vec would have returned
an array-view type or sub-array type to indicate what is happening.
Side note: I've been preaching Julia to everyone I meet. I usually start the
sermon with when you start using Julia it will initially behave/feel very
much like R or Matlab, but then when you need the full power of a fast
modern language it is there for you. Can I really say the first part of
the sermon if I need to tell them to generally expect outputs sharing
memory with inputs (which, to my knowledge, is very different from how
matlab and R behave)?
I hope I'm not sounding critical (cuz I love the language). Mainly, I want
to really understand how things work so I can better sell it to students
and colleagues.
Cheers,
Ethan
Re: [julia-users] output sharing memory with input
While Julia shares a lot with Matlab in terms of syntax, there are several differences. So I cannot see being different a drawback. For me it is more important that Julia scales well to large projects and using array views can help reducing the memory consumption in several situations. But you are of course right that it can be a little confusing for beginners. By the way, for a Numpy user Julias memory sharing concept is not surprising. Am Mittwoch, 23. April 2014 20:51:56 UTC+2 schrieb Ethan Anderes: Ok, I'm trying to reconcile Jameson's suggestion to generally assume an overlap, and Tim's to expect no overlap with arrays if pointer(a) != pointer(b). Doesn't this imply that pointer(input) == pointer(output) a typical array function? With subarray's I fully expect sharing memory, just by the type of the output. I guess I had hoped that vec would have returned an array-view type or sub-array type to indicate what is happening. Side note: I've been preaching Julia to everyone I meet. I usually start the sermon with when you start using Julia it will initially behave/feel very much like R or Matlab, but then when you need the full power of a fast modern language it is there for you. Can I really say the first part of the sermon if I need to tell them to generally expect outputs sharing memory with inputs (which, to my knowledge, is very different from how matlab and R behave)? I hope I'm not sounding critical (cuz I love the language). Mainly, I want to really understand how things work so I can better sell it to students and colleagues. Cheers, Ethan
Re: [julia-users] Re: How to use GLPK.exact ?
Right, it works. Thank you.
If I don't call GLPKMathProgInterface, does JuMP use an internal solver ?
Le mardi 22 avril 2014 23:25:07 UTC+2, Carlo Baldassi a écrit :
Note that you can still use GLPK.exact with JuMP, you just need to add
change the m=Model() line to this:
using GLPKMathProgInterface
m = Model(solver=GLPKSolverLP(method=:Exact))
while all the rest stays the same.
As an aside, it's really kind of annoying that GLPK.exact uses (basically)
Rational{BigInt} internally, but the interface does not allow to access
this. Seems a waste.
On Tuesday, April 22, 2014 8:28:01 PM UTC+2, Stéphane Laurent wrote:
Miles, I have successfully installed JuMP and GLPKMathProgInterface on
Windows 32-bit.
Your code works very well, this is really awesome !! However the result
is not as precise as the one given by *GLPK.exact*.
using JuMP
mu = [1/7, 2/7, 4/7]
nu = [1/4, 1/4, 1/2]
n = length(mu)
m = Model()
@defVar(m, p[1:n,1:n] = 0)
@setObjective(m, Min, sum{p[i,j], i in 1:n, j in 1:n; i != j})
for k in 1:n
@addConstraint(m, sum(p[k,:]) == mu[k])
@addConstraint(m, sum(p[:,k]) == nu[k])
end
solve(m)
julia println(Optimal objective value is:, getObjectiveValue(m))
Optimal objective value is:0.10714285714285715
julia 3/28
0.10714285714285714
Le jeudi 10 avril 2014 01:28:41 UTC+2, Miles Lubin a écrit :
When we have a simplex solver (either in Julia or external) that
supports rational inputs, we could consider making this work with JuMP, but
for now JuMP stores all data as floating-point as well.
Stephane, nice work. LP definitely needs more exposure in the
probability community. Please please write your LPs algebraically, there's
really no excuse not to do this in Julia when your original model is in
this form.
Compare this:
using JuMP
m = Model()
@defVar(m, p[1:n,1:n] = 0)
@setObjective(m, Max, sum{p[i,j], i in 1:n; i != j})
for k in 1:n
@addConstraint(m, sum(p[k,:]) == μ[k])
@addConstraint(m, sum(p[:,k]) == ν[k])
end
solve(m)
println(Optimal objective value is:, getObjectiveValue(m))
with the matrix gymnastics that you had to do to use the low-level GLPK
interface. Writing down a linear programming problem shouldn't be that
hard! (Note: I haven't tested that JuMP code).
Miles
On Wednesday, April 9, 2014 11:18:26 PM UTC+1, Carlo Baldassi wrote:
About GLPK.exact it is not possible to get the rational number 3/28
instead of a decimal approximation ?
No, unfortunately. Also, for that to happen/make sense, you'd also need
to be able to pass all the *inputs* as exact rational values, i.e. as
1//7 instead of 1/7. This would be possible if we had a native generic
Julia linear programming solver, but it's not possible with GLPK, which
can
only use exact arithmetic internally.
[julia-users] Error: type non-boolean (BitArray(1)) used in boolean context
Hi All, I am a new Julia-user and meet a problem when I transfer the Matlab code to Julia. I always get the error:type non-boolean (BitArray(1)) used in boolean context. Can anyone help me check the code and solve this problem? The codes have been attached. I am using the julia-0.3.0-win64 binary release. Any suggestions and comments would be highly appreciated. Cheers, Isaac http://www.google.nl/url?sa=trct=jq=esrc=ssource=webcd=1ved=0CCsQFjAAurl=http%3A%2F%2Fforum.wordreference.com%2Fshowthread.php%3Ft%3D2248185%26langid%3D22ei=Ih9YU4-UJM3JOaCjgKAPusg=AFQjCNHQ9d3MxWGbJ6kVa5WXzgnDQ1VBRQsig2=fFKs_1zFpZD67HrDPpH8Mg sample.jl Description: Binary data main (2).jl Description: Binary data
Re: [julia-users] output sharing memory with input
Thanks everyone... it's super helpful to read your comments. @Tim: ok, that makes sense and is clear. I think I was worried the language would have a jumble of commands (not just in those categories you list) which subtly fused variables in memory. Your comment helps me reason about it. @Tobias: Yep, I agree the scalability of the language is key. I was just hoping that we could do this while also keeping the ability of non-programmers to start reasoning about Julia code immediately. I definitely don't want to suggesting Julia look like Matlab or R ... I just want variable assignment and functions (at the high-level prototype stage) to behave in a way that a scientist/mathematician/statistician would expect. BTW: when I first tried to break from Matlab and use Numpy I spent a full two days on a small project that ended up being completely wrong because of the shared memory issue that I didn't realize at first. I was scarred, hence my sensitivity to the issue:) Again, thanks a ton and keep up the good work.
[julia-users] Re: Error: type non-boolean (BitArray(1)) used in boolean context
In general, Julia is much more picky about what types of things can be used in if statements and or || conditions than Matlab is. They must be Bools in Julia, whereas Matlab tries to convert things to a scalar logical value. Crazily enough, one of the things that Matlab converts to a scalar logical value (albeit not in or || expressions) is a logical mask. In Julia, you must explicitly convert the mask (a BitArray) to a Bool by calling `all` (Matlab's behavior) or `any`. Check main, line 49. See the documentation for more details: http://docs.julialang.org/en/latest/manual/control-flow/?highlight=bool#man-conditional-evaluation Also note that braces don't denote scope, but rather create Any-typed arrays. You don't want to be using them within your if blocks. On Wednesday, April 23, 2014 4:16:52 PM UTC-4, Isaac wrote: Hi All, I am a new Julia-user and meet a problem when I transfer the Matlab code to Julia. I always get the error:type non-boolean (BitArray(1)) used in boolean context. Can anyone help me check the code and solve this problem? The codes have been attached. I am using the julia-0.3.0-win64 binary release. Any suggestions and comments would be highly appreciated. Cheers, Isaac http://www.google.nl/url?sa=trct=jq=esrc=ssource=webcd=1ved=0CCsQFjAAurl=http%3A%2F%2Fforum.wordreference.com%2Fshowthread.php%3Ft%3D2248185%26langid%3D22ei=Ih9YU4-UJM3JOaCjgKAPusg=AFQjCNHQ9d3MxWGbJ6kVa5WXzgnDQ1VBRQsig2=fFKs_1zFpZD67HrDPpH8Mg
Re: [julia-users] Error: type non-boolean (BitArray(1)) used in boolean context
In Matlab, arrays of booleans can be used in conditionals and are, I believe, considered true if all the values in them are true and false otherwise. In Julia only actual boolean values (true or false) can be used in conditionals. You're using a 1-d boolean array somewhere in a conditional. Not sure where – I took a quick look, but nothing popped out at me. On Wed, Apr 23, 2014 at 4:16 PM, Isaac dux...@gmail.com wrote: Hi All, I am a new Julia-user and meet a problem when I transfer the Matlab code to Julia. I always get the error:type non-boolean (BitArray(1)) used in boolean context. Can anyone help me check the code and solve this problem? The codes have been attached. I am using the julia-0.3.0-win64 binary release. Any suggestions and comments would be highly appreciated. Cheers, Isaac http://www.google.nl/url?sa=trct=jq=esrc=ssource=webcd=1ved=0CCsQFjAAurl=http%3A%2F%2Fforum.wordreference.com%2Fshowthread.php%3Ft%3D2248185%26langid%3D22ei=Ih9YU4-UJM3JOaCjgKAPusg=AFQjCNHQ9d3MxWGbJ6kVa5WXzgnDQ1VBRQsig2=fFKs_1zFpZD67HrDPpH8Mg
Re: [julia-users] Re: How to use GLPK.exact ?
On Wednesday, April 23, 2014 3:40:02 PM UTC-4, Stéphane Laurent wrote: If I don't call GLPKMathProgInterface, does JuMP use an internal solver ? If a solver isn't specified, JuMP (actually MathProgBase) will search for an available solver and pick one by default. JuMP does not have an internal solver. By the way, future discussions on linear programming etc. should take place on the julia-opt mailing list: https://groups.google.com/forum/#!forum/julia-opt. Thanks, Miles
Re: [julia-users] All packages for numerical math
Or you can use the non-vectorized version and save the overhead of the
temporary arrays being created by the addition and multiplication steps.
function trapz{T:Real}(x::Vector{T}, y::Vector{T})
local len = length(y)
if (len != length(x))
error(Vectors must be of same length)
end
r = 0.0
for i in 2:len
r += (x[i] - x[i-1]) * (y[i] + y[i-1])
end
r/2.0
end
BTW, another possibility is to use a spline interpolation on the original
data and integrate the spline evaluation with quadgk(). (Ideally,
integrations can be incorporated into a spline interface.) This could be
useful depending on the functional shape between the grid points.
Cameron
On Wed, Apr 23, 2014 at 7:52 AM, Tomas Lycken tomas.lyc...@gmail.comwrote:
The trapezoidal rule (http://en.wikipedia.org/wiki/Trapezoidal_rule)
would probably be almost trivial to implement.
function trapz{T:Real}(x::Vector{T}, y::Vector{T})
if (length(y) != length(x))
error(Vectors must be of same length)
end
sum( (x[2:end] .- x[1:end-1]).*(y[2:end].+y[1:end-1]) ) / 2
end
x = [0:0.01:pi]
y = sin(x)
trapz(x,y) # 1.820650436642
This, of course, only currently works on vectors of real numbers, but it's
easy to extend it if you want.
And there might be more accurate methods as well, of course (see e.g.
http://en.wikipedia.org/wiki/Simpson%27s_rule) but this one's often good
enough.
// T
On Wednesday, April 23, 2014 8:43:48 AM UTC+2, Evgeny Shevchenko wrote:
Hi, John.
No, I didn't. I didn't find it and it seems to be not what i need:
no method quadgk(Array{Float64,1}, Array{Float64,1})
quadgk(f,a,b,...) expects a function as its first argument but I mean the
case when y = f(x), but i don't have f, e.g. obtained experimental data, so
x and y are 1-D arrays of floats.
On Tue, Apr 22, 2014 at 7:49 PM, John Myles White
johnmyl...@gmail.comwrote:
Have you tried the quadgk function?
-- John
On Apr 22, 2014, at 7:32 AM, Evgeny Shevchenko eu...@ya.ru wrote:
Hi
Is there a package for numeric integration of obtained arrays, say x and
y? Couldn't find one, the led me to use @pyimport and numpy.trapz.
--
pupoque@IRC
Re: [julia-users] Surprising range behavior
On Wednesday, April 23, 2014 10:50:57 PM UTC-4, Steven G. Johnson wrote: On Wednesday, April 23, 2014 10:17:23 PM UTC-4, Simon Kornblith wrote: pi*(0:0.01:1) or similar should work. Actually, that may not work because of https://github.com/JuliaLang/julia/issues/6364 ...which of course you know about because you submitted that bug report, sorry. (People should just use their Github usernames everywhere, rather than polluting the namespace with all of these real name aliases.)
Re: [julia-users] Surprising range behavior
(Simon, you may also be amused to learn that Google thinks that your post is written in Latin and offers to translate it. Mirabile dictu!)
[julia-users] Re: Surprising range behavior
I think it's correct because the next value in the range would exceed PI. If you try 0:pi/101:pi, you would get 3.14 again. On Thursday, April 24, 2014 5:59:10 AM UTC+8, Peter Simon wrote: The first three results below are what I expected. The fourth result surprised me: julia (0:pi:pi)[end] 3.141592653589793 julia (0:pi/2:pi)[end] 3.141592653589793 julia (0:pi/3:pi)[end] 3.141592653589793 julia (0:pi/100:pi)[end] 3.1101767270538954 Is this behavior correct? Version info: julia versioninfo() Julia Version 0.3.0-prerelease+2703 Commit 942ae42* (2014-04-22 18:57 UTC) Platform Info: System: Windows (x86_64-w64-mingw32) CPU: Intel(R) Core(TM) i7 CPU 860 @ 2.80GHz WORD_SIZE: 64 BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY) LAPACK: libopenblas LIBM: libopenlibm --Peter
Re: [julia-users] output sharing memory with input
Hi Tobias: My 'hard to find bug' statement should really have read 'hard to find bug from a newbie perspective'. These bugs would be obvious to someone familiar with basic programming. My numpy example is too big to give now but here is a simple metropolis hasting markov chain short example: theta_curr = 0.0 for k=1:10_000 theta_prop = theta_curr theta_prop += randperturbation() likelihoodratio = computelr(theta_prop, theta_curr) if rand() minimum([1,likelihoodratio]) theta_curr = theta_prop else theta_curr = theta_curr end end The variable theta_prop is only supposed to be set to theta_curr if the first conditional is true. I guess in python += acts inplace, so that line 3 actually changes theta_curr, which would be a bug. In my numpy excursion, once I realized this (after many more lines of code) my stomach turned and I suddenly decided I didn't know what the heck I was doing and ended up running back to safe matlab. I had a similar feeling with vec(a) where after learning the output was the same as input I suddenly had to review all my code that used vec(a) to make sure I wasn't spuriously fusing variables. The thing about Julia that I like is that I could start out reasoning about code immediately (if I avoided functions with ! at the end) and then slowly venture into the more modern techniquesbut the point is I was scientifically productive immediate without knowing much about programing. I definitely agree that the suffix ! works well. In fact I like it so much I was just hoping that there would be something similar to indicate when output shared input member. I was thinking there would be reshape(A,dims), reshape!(A,dims) and reshape*(A,dims) where reshape(A,dims) returned a copy, reshape!(A,dims) mutated A and reshape*(A,dims) left the arguments alone but returned a variable which shared memory with A. Anyway, that suggestion now seems silly after hearing Tim say that there are really only corner, easy to understand, cases where I need to worry about it. Again, thanks all for the discussion! Ethan
Re: [julia-users] output sharing memory with input
Jameson: Yes, the Matlab choice is slow and doesn't scale, but it's very easy to reason about. I think it was instructive for me to try and think of a real life bug that realized my worries. I came to realize that most of the code where I was using vec() was embedded in a chain of function calls like b = M * exp(vec(a)) so I see your point about fast easily composible functions when output and input share memory. I recently had a discussion with a colleague that commented that R was essentially developed by statisticians which is why it doesn't scale well (not sure if that is actually true but thats beside my point). On the other hand, things like python are written by CS folks which hinders access for mathy-science folks who just want to prototype an idea every now and again without investing the time to upgrade their programming skills. I think julia can have the best of both: easy to learn + modern CS.
Re: [julia-users] Surprising range behavior
Thanks, Simon, that construct works nicely to solve the problem I posed. I have to say, though, that I find Matlab's colon range behavior more intuitive and generally useful, even if it isn't as exact as Julia's. --Peter On Wednesday, April 23, 2014 7:17:23 PM UTC-7, Simon Kornblith wrote: pi*(0:0.01:1) or similar should work. On Wednesday, April 23, 2014 7:12:58 PM UTC-4, Peter Simon wrote: Thanks for the explanation--it makes sense now. This question arose for me because of the example presented in https://groups.google.com/d/msg/julia-users/CNYaDUYog8w/QH9L_Q9Su9YJ : x = [0:0.01:pi] used as the set of x-coordinates for sampling a function to be integrated (ideally over the interval (0,pi)). But the range defined in x has a last entry of 3.14, which will contribute to the inaccuracy of the integral being sought in that example. As an exercise, I was trying to implement the interpolation solution described later in that thread by Cameron McBride: BTW, another possibility is to use a spline interpolation on the original data and integrate the spline evaluation with quadgk(). It seems that one cannot use e.g. linspace(0,pi,200) for the x values, because CoordInterpGrid will not accept an array as its first argument, so you have to use a range object. But the range object has a built-in error for the last point because of the present issue. Any suggestions? Thanks, --Peter On Wednesday, April 23, 2014 3:24:10 PM UTC-7, Stefan Karpinski wrote: The issue is that float(pi) 100*(pi/100). The fact that pi is not rational – or rather, that float64(pi) cannot be expressed as the division of two 24-bit integers as a 64-bit float – prevents rational lifting of the range from kicking in. I worried about this kind of issue when I was working on FloatRanges, but I'm not sure what you can really do, aside from hacks where you just decide that things are close enough based on some ad hoc notion of close enough (Matlab uses 3 ulps). For example, you can't notice that pi/(pi/100) is an integer – because it isn't: julia pi/(pi/100) 99.99 One approach is to try to find a real value x such that float64(x/100) == float64(pi)/100 and float64(x) == float64(pi). If any such value exists, it makes sense to do a lifted FloatRange instead of the default naive stepping seen here. In this case there obviously exists such a real number – π itself is one such value. However, that doesn't quite solve the problem since many such values exist and they don't necessarily all produce the same range values – which one should be used? In this case, π is a good guess, but only because we know that's a special and important number. Adding in ad hoc special values isn't really satisfying or acceptable. It would be nice to give the right behavior in cases where there is only one possible range that could have been intended (despite there being many values of x), but I haven't figured out how determine if that is the case or not. The current code handles the relatively straightforward case where the start, step and stop values are all rational. On Wed, Apr 23, 2014 at 5:59 PM, Peter Simon psimo...@gmail.com wrote: The first three results below are what I expected. The fourth result surprised me: julia (0:pi:pi)[end] 3.141592653589793 julia (0:pi/2:pi)[end] 3.141592653589793 julia (0:pi/3:pi)[end] 3.141592653589793 julia (0:pi/100:pi)[end] 3.1101767270538954 Is this behavior correct? Version info: julia versioninfo() Julia Version 0.3.0-prerelease+2703 Commit 942ae42* (2014-04-22 18:57 UTC) Platform Info: System: Windows (x86_64-w64-mingw32) CPU: Intel(R) Core(TM) i7 CPU 860 @ 2.80GHz WORD_SIZE: 64 BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY) LAPACK: libopenblas LIBM: libopenlibm --Peter
