[julia-users] Re: Setting RNG seeds for parallel computing
Another way would be to just initialize a `MersenneTwister` stream on each
process, and seed them differently. Since the streams are process local,
there shouldn't be any communication overhead, and streams with different
seeds should be independent.
// T
On Wednesday, July 16, 2014 7:07:09 AM UTC+2, James Delaney wrote:
If your goal is that each call to rand(), regardless of process,
sequentially pulls a number from the RNG stream, then perhaps you just need
to create a MersenneTwister([seed]) object.
mystream = MersenneTwister(1)
## Parallel execution
srand(1)
parfor = @parallel (vcat) for i=1:4
rand(mystream)
end
Intuitively, this seems like it must come with some communication overhead.
It seems likely that there should be a way to avoid this overhead with
pmap().
Jim
On Tuesday, July 15, 2014 6:25:11 PM UTC-4, Gray Calhoun wrote:
Hi everyone, I'm trying to start using Julia for some Monte Carlo
simulations
(not MCMC) which I'd like to parallelize. I haven't found any
documentation
for setting the RNG's seed for parallelization. The naive approach gives
different results than non-parallel execution (which is not surprising).
Starting with `julia -p 4` and executing:
## Sequential execution
srand(1)
seqfor = Array(Float64,4)
for i=1:4
seqfor[i] = rand()
end
## Parallel execution
srand(1)
parfor = @parallel (vcat) for i=1:4
rand()
end
[sort(parfor) sort(seqfor)]
gives
4x2 Array{Float64,2}:
0.346517 0.00790928
0.346517 0.236033
0.662369 0.312707
0.914194 0.346517
and re-running the parallel code can give different results even after
re-seeding. If we start julia without `-p 4` then both loops give the
same results. If it matters, I'm using Julia version 0.3.0-rc1+28
from source (commit 79e4771).
Is there documentation on the right way to parallelize simulations in
Julia? If not, should my next step be to carefully read the parallel
computing documentation?
[julia-users] Unexpected type of result
I came across a behavior that leaves me a bit puzzled, here is example: v = mapslices(var,randn(1000, 3, 19), [1]) [v[1,1,j] for j=1:19] I would expect the resulting Vector to be Float64, not Any. Can anybody tell me if I am doing something wrong or why it should be expected to be Any? Thanx.
[julia-users] Re: Unexpected type of result
Are you doing this in the REPL, or inside a function? Type inference isn't
great in the global scope, at least partly because Julia can't know that
the types won't change in the future, and therefore can't make as tight
inferences as it would otherwise.
I tried wrapping your code in a function, but to my surprise still got the
same resutls:
```julia
julia function foo()
v = mapslices(var,randn(1000,3,19),[1])
[v[1,1,j] for j = 1:19]
end
foo (generic function with 1 method)
julia foo()
19-element Array{Any,1}:
0.994972
0.961816
...
```
A quick-fix is easy - just annotate the element type:
```julia
julia v = mapslices(var,randn(1000,3,19),[1]); eltype(v)[v[1,1,j] for j =
1:19]
19-element Array{Float64,1}:
0.969605
1.00223
...
```
but I don't think this should be needed inside a function. Someone more
knowledgeable will have to expand on the details here.
// T
On Wednesday, July 16, 2014 11:08:31 AM UTC+2, Tomas Krehlik wrote:
I came across a behavior that leaves me a bit puzzled, here is example:
v = mapslices(var,randn(1000, 3, 19), [1])
[v[1,1,j] for j=1:19]
I would expect the resulting Vector to be Float64, not Any. Can anybody
tell me if I am doing something wrong or why it should be expected to be
Any?
Thanx.
[julia-users] question about GSL.jl package usage
Hi!
I want to use the function interpolation suite from the GSL library. I came
across the GSL.jl package which wraps the entire GSL library (which is
awesome).
I am stuck with setting up the interpolation object and wanted to reach out
for help. my issue is described here in greater
detail: https://github.com/jiahao/GSL.jl/issues/19
basically I don't know what to put in place of *T::Ptr{gsl_interp_type} in*
*spline_alloc(T::Ptr{gsl_interp_type},size::Integer)*
which is the function used to allocate a spline object. If I just do pS =
interp_alloc(interp_linear,n) or pS = interp_alloc(interp_cspline,n) it
rightly says interp_linear not defined. How can I get a pointer to a GSL
interpolation type? I cannot find any function that returns such a pointer.
thanks!
[julia-users] ways to improve performance of a non-integer power?
i'm looking for ways to improve the performance of ^ as in f(x) = x^1.4 I found this thread on integer powers, and it seems there are some benefits of calling system pow() functions (sometimes). https://github.com/JuliaLang/julia/issues/2741 is there anything related for non-integer powers or am I just stuck here? thanks!
[julia-users] Replacing modules that extend methods doesn't replace extensions
If a I import a function explicitly into a module and extend it with new methods, Julia seems to become quite confused when I replace the module, adding more methods with exactly the same signatures as the ones already there. I have a complete gist outlining the problem https://gist.github.com/tlycken/ea7781b2eaedccfef12a (just put all three files in the same folder and execute julia demo.jl) but in summary, the oddness is shown if you call methods on the extended function after a few inclusions: julia methods(Foo.bar) # 8 methods for generic function bar: bar(q::Qux) at /home/tlycken/coding/Julia/Baz.jl:11 bar(q::Qux) at /home/tlycken/coding/Julia/Baz.jl:11 bar(q::Qux) at /home/tlycken/coding/Julia/Baz.jl:11 bar(q::Qux) at /home/tlycken/coding/Julia/Baz.jl:11 bar(q::Qux) at /home/tlycken/coding/Julia/Baz.jl:11 bar(q::Qux) at /home/tlycken/coding/Julia/Baz.jl:11 bar(q::Qux) at /home/tlycken/coding/Julia/Baz.jl:11 bar(x) at /home/tlycken/coding/Julia/Foo.jl:6 It still seems to work in this case - bar(Qux(3)) does what it should - but I’m having trouble in my real application (where I’m extending layer from Gadfly.jl) because I’m getting MethodErrors for signatures that methods say are there. Is this a known problem? I couldn’t find anything in the issue list on Github, but I admit that I found it quite difficult to figure out what to search for… // T
[julia-users] build-in function to find inverse of a matrix
sorry if it's a stupid question. But I cannot find one in the online doc. Thanks
Re: [julia-users] build-in function to find inverse of a matrix
It's inv, but I was struggling to find it too: http://docs.julialang.org/en/latest/stdlib/linalg/#Base.inv but note that if you want to solve a linear system Ax =b use x = A\b On Wed, 2014-07-16 at 13:39, Alan Chan szelok.c...@gmail.com wrote: sorry if it's a stupid question. But I cannot find one in the online doc. Thanks
[julia-users] Re: build-in function to find inverse of a matrix
`inv` will do that for you. http://docs.julialang.org/en/latest/stdlib/linalg/#Base.inv It's a little unfortunate that the help text is Matrix inverse, yet searching for that exact phrase yields no results at all. Is it possible to make documentation search be full-text for help text as well? // T On Wednesday, July 16, 2014 2:39:53 PM UTC+2, Alan Chan wrote: sorry if it's a stupid question. But I cannot find one in the online doc. Thanks
[julia-users] Re: build-in function to find inverse of a matrix
But apropos does find it: julia apropos(matrix inverse) INFO: Loading help data... Base.inv(M) On Wednesday, July 16, 2014 2:59:05 PM UTC+2, Tomas Lycken wrote: `inv` will do that for you. http://docs.julialang.org/en/latest/stdlib/linalg/#Base.inv It's a little unfortunate that the help text is Matrix inverse, yet searching for that exact phrase yields no results at all. Is it possible to make documentation search be full-text for help text as well? // T On Wednesday, July 16, 2014 2:39:53 PM UTC+2, Alan Chan wrote: sorry if it's a stupid question. But I cannot find one in the online doc. Thanks
[julia-users] Re: Replacing modules that extend methods doesn't replace extensions
I think I managed to gain some futher understanding here, but I'm really uncertain if this is correct, so I'd really appreciate if someone who actually understands what's going on would confirm or correct this: What I *think* happens, is that each time the file is included, a *new* type with the same (fully qualified) name is defined, and a method is added to the function for the new type. For most functions, since the function is also replaced, this doesn't really constitute a problem, but since this code is extending a function from somewhere else, the function isn't replaced, and so methods are just added on top of each other. The main reason it's so confusing is that all the types have the same fully qualified names, so there is really no way for me as a user to know which one of them is the latest version. I think I've seen an issue about this on the tracker, but now I can't find it. Does this seem like a possible explanation of the behavior above? My original problem could then be that I was keeping old variables, of old versions of the type, around - does that also seem reasonable? Thanks, // Tomas On Wednesday, July 16, 2014 1:15:23 PM UTC+2, Tomas Lycken wrote: If a I import a function explicitly into a module and extend it with new methods, Julia seems to become quite confused when I replace the module, adding more methods with exactly the same signatures as the ones already there. I have a complete gist outlining the problem https://gist.github.com/tlycken/ea7781b2eaedccfef12a (just put all three files in the same folder and execute julia demo.jl) but in summary, the oddness is shown if you call methods on the extended function after a few inclusions: julia methods(Foo.bar) # 8 methods for generic function bar: bar(q::Qux) at /home/tlycken/coding/Julia/Baz.jl:11 bar(q::Qux) at /home/tlycken/coding/Julia/Baz.jl:11 bar(q::Qux) at /home/tlycken/coding/Julia/Baz.jl:11 bar(q::Qux) at /home/tlycken/coding/Julia/Baz.jl:11 bar(q::Qux) at /home/tlycken/coding/Julia/Baz.jl:11 bar(q::Qux) at /home/tlycken/coding/Julia/Baz.jl:11 bar(q::Qux) at /home/tlycken/coding/Julia/Baz.jl:11 bar(x) at /home/tlycken/coding/Julia/Foo.jl:6 It still seems to work in this case - bar(Qux(3)) does what it should - but I’m having trouble in my real application (where I’m extending layer from Gadfly.jl) because I’m getting MethodErrors for signatures that methods say are there. Is this a known problem? I couldn’t find anything in the issue list on Github, but I admit that I found it quite difficult to figure out what to search for… // T
[julia-users] Re: Setting RNG seeds for parallel computing
On Wednesday, July 16, 2014 12:07:09 AM UTC-5, James Delaney wrote:
If your goal is that each call to rand(), regardless of process,
sequentially pulls a number from the RNG stream, then perhaps
you just need to create a MersenneTwister([seed]) object.
mystream = MersenneTwister(1)
## Parallel execution
srand(1)
parfor = @parallel (vcat) for i=1:4
rand(mystream)
end
Thanks for the reply. This is probably close to what I'll end up
doing. The execution time of each simulation is long enough that it
should dwarf any communication overhead, and I'd (ideally) like the
results to be independent of the number of processors used, which this
accomplishes.
Unfortunately the code doesn't work as written. With four processors,
it returns
julia parfor
4-element Array{Float64,1}:
0.236033
0.236033
0.236033
0.236033
I'll look into what's going on more carefully, because it would be
nice to have an approach like this work. (I assume `mystream` is
copied into each process, which `pmap` should be able to avoid.)
--Gray
--
Gray Calhoun Assistant Professor of Economics, Iowa State University
http://gray.clhn.co // (515) 294-6271 // 467 Heady Hall
[julia-users] Re: Setting RNG seeds for parallel computing
On Wednesday, July 16, 2014 2:09:41 AM UTC-5, Tomas Lycken wrote: Another way would be to just initialize a `MersenneTwister` stream on each process, and seed them differently. Since the streams are process local, there shouldn't be any communication overhead, and streams with different seeds should be independent. My understanding is that streams with different seeds are not guaranteed to be independent, but there are some RNGs for which they are. --Gray
Re: [julia-users] Re: Replacing modules that extend methods doesn't replace extensions
Yes, I think you've got the right idea. Really there's Qux, QuxOld, QuxOldOld, QuxOldOldOld, etc., but it's not showing you those Old parts of the name. Regarding variables of old types: yep, that's frequently a source of confusion. The example at the end of the FAQ section shows an example: http://docs.julialang.org/en/latest/manual/faq/#how-can-i-modify-the-declaration-of-a-type-immutable-in-my-session --Tim On Wednesday, July 16, 2014 07:46:14 AM Tomas Lycken wrote: I think I managed to gain some futher understanding here, but I'm really uncertain if this is correct, so I'd really appreciate if someone who actually understands what's going on would confirm or correct this: What I *think* happens, is that each time the file is included, a *new* type with the same (fully qualified) name is defined, and a method is added to the function for the new type. For most functions, since the function is also replaced, this doesn't really constitute a problem, but since this code is extending a function from somewhere else, the function isn't replaced, and so methods are just added on top of each other. The main reason it's so confusing is that all the types have the same fully qualified names, so there is really no way for me as a user to know which one of them is the latest version. I think I've seen an issue about this on the tracker, but now I can't find it. Does this seem like a possible explanation of the behavior above? My original problem could then be that I was keeping old variables, of old versions of the type, around - does that also seem reasonable? Thanks, // Tomas On Wednesday, July 16, 2014 1:15:23 PM UTC+2, Tomas Lycken wrote: If a I import a function explicitly into a module and extend it with new methods, Julia seems to become quite confused when I replace the module, adding more methods with exactly the same signatures as the ones already there. I have a complete gist outlining the problem https://gist.github.com/tlycken/ea7781b2eaedccfef12a (just put all three files in the same folder and execute julia demo.jl) but in summary, the oddness is shown if you call methods on the extended function after a few inclusions: julia methods(Foo.bar) # 8 methods for generic function bar: bar(q::Qux) at /home/tlycken/coding/Julia/Baz.jl:11 bar(q::Qux) at /home/tlycken/coding/Julia/Baz.jl:11 bar(q::Qux) at /home/tlycken/coding/Julia/Baz.jl:11 bar(q::Qux) at /home/tlycken/coding/Julia/Baz.jl:11 bar(q::Qux) at /home/tlycken/coding/Julia/Baz.jl:11 bar(q::Qux) at /home/tlycken/coding/Julia/Baz.jl:11 bar(q::Qux) at /home/tlycken/coding/Julia/Baz.jl:11 bar(x) at /home/tlycken/coding/Julia/Foo.jl:6 It still seems to work in this case - bar(Qux(3)) does what it should - but I’m having trouble in my real application (where I’m extending layer from Gadfly.jl) because I’m getting MethodErrors for signatures that methods say are there. Is this a known problem? I couldn’t find anything in the issue list on Github, but I admit that I found it quite difficult to figure out what to search for… // T
[julia-users] Re: Setting RNG seeds for parallel computing
Yeah, sorry - I suspected there might be something I was missing. According to the wikipedia page about the MT http://en.wikipedia.org/wiki/Mersenne_twister one of its disadvantages is just that: It can take a long time to turn a non-random initial state—particularly an initial state with many zeros—into output that passes randomness tests http://en.wikipedia.org/wiki/Randomness_tests. A consequence of this is that *two instances of the generator, started with initial states that are almost the same, will output nearly the same sequence for many iterations before eventually diverging.* So you should probably not do this without significant warm-up, or in some other way make sure that the seeds are different enough. If you don’t need randoms very often, you’re probably better off with James’ approach. // T On Wednesday, July 16, 2014 4:54:07 PM UTC+2, Gray Calhoun wrote: On Wednesday, July 16, 2014 2:09:41 AM UTC-5, Tomas Lycken wrote: Another way would be to just initialize a `MersenneTwister` stream on each process, and seed them differently. Since the streams are process local, there shouldn't be any communication overhead, and streams with different seeds should be independent. My understanding is that streams with different seeds are not guaranteed to be independent, but there are some RNGs for which they are. --Gray
[julia-users] Re: my first julia function
With the latest Julia, you can do this by
sumabs2(x)
Dahua
On Wednesday, July 16, 2014 9:57:54 AM UTC-5, Neal Becker wrote:
As a first exercise, I wanted to code magnitude squared of a complex
1-d array. Here is what I did:
mag_sqr{T} (x::Array{Complex{T},1}) =
sum(real(x).*real(x)+imag(x).*imag(x))
Is this a good approach? I'm wondering if it's not very efficient,
since I
expect it would compute matrixes of element-wise products first, rather
than
doing the sum as a running summation (like a loop in c++).
Can you suggest something better?
[julia-users] Re: my first julia function
Dahua Lin wrote:
With the latest Julia, you can do this by
sumabs2(x)
Dahua
On Wednesday, July 16, 2014 9:57:54 AM UTC-5, Neal Becker wrote:
As a first exercise, I wanted to code magnitude squared of a complex
1-d array. Here is what I did:
mag_sqr{T} (x::Array{Complex{T},1}) =
sum(real(x).*real(x)+imag(x).*imag(x))
Is this a good approach? I'm wondering if it's not very efficient,
since I
expect it would compute matrixes of element-wise products first, rather
than
doing the sum as a running summation (like a loop in c++).
Can you suggest something better?
Not exactly answering my question, as I was looking for a learning opportunity.
But this raises another question:
In [2]:
help(sumabs2)
INFO: Loading help data...
sumabs2 (generic function with 2 methods)
Why is the help data not being shown? (this is ipython notebook interface)
Re: [julia-users] Re: my first julia function
To follow up on Dahua's comment:
If you're interested in using the fastest code, the code that Dahua posted is
the fastest since it uses several clever tricks to get the absolute best speed.
If you're interested in writing a faster implementation than the one you wrote,
you need to avoid allocating temporary arrays. You'd be better off with a loop
like:
function mag_sqr{T}(x::Vector{Complex{T}})
res = similar(x, T)
for i in 1:length(x)
res[i] = real(x[i]) * real(x[i]) + imag(x[i]) * imag(x[i])
end
return res
end
That way you only allocate the amount of memory required to produce the desired
output.
-- John
On Jul 16, 2014, at 11:28 AM, Dahua Lin linda...@gmail.com wrote:
With the latest Julia, you can do this by
sumabs2(x)
Dahua
On Wednesday, July 16, 2014 9:57:54 AM UTC-5, Neal Becker wrote:
As a first exercise, I wanted to code magnitude squared of a complex
1-d array. Here is what I did:
mag_sqr{T} (x::Array{Complex{T},1}) = sum(real(x).*real(x)+imag(x).*imag(x))
Is this a good approach? I'm wondering if it's not very efficient, since I
expect it would compute matrixes of element-wise products first, rather than
doing the sum as a running summation (like a loop in c++).
Can you suggest something better?
Re: [julia-users] Re: my first julia function
Help data is hand-written; if no one has documented a function yet, then it
just tells you how many methods there are. `methods(sumabs2)` would show
you the method signatures.
If you want to add to the help documentation, you can edit this file:
https://github.com/JuliaLang/julia/blob/master/doc/helpdb.jl (You can
either use the github interface to edit it online, or, if you have the
Julia source, edit the file locally and make a pull request.)
-- Leah
On Wed, Jul 16, 2014 at 10:36 AM, Neal Becker ndbeck...@gmail.com wrote:
Dahua Lin wrote:
With the latest Julia, you can do this by
sumabs2(x)
Dahua
On Wednesday, July 16, 2014 9:57:54 AM UTC-5, Neal Becker wrote:
As a first exercise, I wanted to code magnitude squared of a complex
1-d array. Here is what I did:
mag_sqr{T} (x::Array{Complex{T},1}) =
sum(real(x).*real(x)+imag(x).*imag(x))
Is this a good approach? I'm wondering if it's not very efficient,
since I
expect it would compute matrixes of element-wise products first, rather
than
doing the sum as a running summation (like a loop in c++).
Can you suggest something better?
Not exactly answering my question, as I was looking for a learning
opportunity.
But this raises another question:
In [2]:
help(sumabs2)
INFO: Loading help data...
sumabs2 (generic function with 2 methods)
Why is the help data not being shown? (this is ipython notebook interface)
[julia-users] Re: my first julia function
On Wednesday, July 16, 2014 11:28:12 AM UTC-4, Dahua Lin wrote: sumabs2(x) That's cheating! Neal, I think what you wrote will work just fine, and sumabs2 will work even better. It's a little tough to see what all is being done in its implementation because the base library is trying to eek every last ounce of performance out of the code, and do so generically for many operations. Some of the optimizations may include: 1. Using an explicit loop. Unlike other languages (Matlab/Python/R), Julia's for loops are faster than its vectorized alternatives. That's because it needs to allocate an entire copy of an array for every operation. Something like this will get you most of the way there: s = zero(T) # Use a real zero of the same type as the complex number so it doesn't change type for xi in x s += real(xi)*real(xi)+imag(xi)*imag(xi) end 2. But for arrays, we can do better. Iteratively summing like that has major floating point issues; if you're summing lots of small numbers, `s` slowly becomes so large that the rest of the small numbers get lost within the precision. The base implementation of sum for arrays is smarter — it sums things pairwise. Instead of summing everything into one large pot, it sums things into small pots, then sums those together, and so on. This requires an array as not all iterables support random access. I think those two things will get you most of the way to being competitive with the base algorithm.
Re: [julia-users] Re: my first julia function
For me at least (using v0.3.0-rc1), sumabs2 is not an exported function. Usually those do not have any associated help. You can still call it as Base.sumabs2, but non-exported functions may not have a stable interface. --Tim On Wednesday, July 16, 2014 11:36:57 AM Neal Becker wrote: Why is the help data not being shown? (this is ipython notebook interface)
Re: [julia-users] my first julia function
It was exported after rc1 and will be available in the next rc (hopefully with docs!). Cheers, Kevin On Wednesday, July 16, 2014, Tim Holy tim.h...@gmail.com wrote: For me at least (using v0.3.0-rc1), sumabs2 is not an exported function. Usually those do not have any associated help. You can still call it as Base.sumabs2, but non-exported functions may not have a stable interface. --Tim On Wednesday, July 16, 2014 11:36:57 AM Neal Becker wrote: Why is the help data not being shown? (this is ipython notebook interface)
[julia-users] Re: build-in function to find inverse of a matrix
I think that one of the main reasons it is so difficult to find is that inv should generally be avoided. As Mauro wrote, if you can, rephrase your problem so that you can use x = A\b.
[julia-users] Re: Jupyter project
On Tuesday, July 15, 2014 3:46:49 PM UTC-4, Sam L wrote: I haven't heard of it before, but if I understand correctly, the Jupyter project is about splitting the language-agnostic parts of IPython out into its own project. Looks interesting! IPython was already split into language-agnostic front-ends (e.g. the notebook) and a language-specific Python backend. IJulia is based on this: it just replaces the Python backend with a Julia backend. The rebranding of the front-end(s) as Jupyter is a (welcome) acknowledgement of this reality, rather than a substantial change in direction.
[julia-users] Re: Call for Unicode julia source examples
Hi Ben,
That character is probably defined as a unicode 6 math symbol. UTF8proc
is a library that julia uses to do Unicode normalization and it currently
does not support unicode 6 characters. Luckily it seems like Steven
Johnson is on a quest to make every possible unicode symbol available in
Julia so this should be fixed soon.
Jake
On Wednesday, July 16, 2014 3:40:31 PM UTC-4, Ben Arthur wrote:
i'm not sure whether i'm doing something wrong, or whether this is the
expected behavior, but it might be an error:
julia const ∪ = union
Warning: imported binding for ∪ overwritten in module Main
union (generic function with 7 methods)
julia ∪([1 2 3],[3 4 5])
5-element Array{Int64,1}:
1
2
3
4
5
julia !(true)
false
julia const ¬ = !
ERROR: syntax: invalid character ¬
julia (¬)(x::Bool) = !x
ERROR: syntax: invalid character ¬
this is with today's version of julia, on both os x and linux.
ben
[julia-users] Re: Call for Unicode julia source examples
On Wednesday, July 16, 2014 3:40:31 PM UTC-4, Ben Arthur wrote: julia const ∪ = union ∪ is already defined to union in Julia. julia const ¬ = ! ERROR: syntax: invalid character ¬ The ¬ character (U+00AC) is in category Sm (math symbols), and Julia does not allow all possible math symbols as identifier characters. The reason is that, for each math symbol, we need to individually decide whether it will be parsed as part of an identifier or as an operator. And, if it is parsed as an operator, we need to decide the precedence. In consequence, there is a whitelist of math symbols allowed in identifiers https://github.com/JuliaLang/julia/blob/master/src/flisp/julia_extensions.c#L51-L93 and another whitelist of symbols treated as operators https://github.com/JuliaLang/julia/blob/master/src/julia-parser.scm#L6-L22 Both of these lists will probably grow over time. In the case of ¬, I think it would make sense to parse it as a prefix operator (with the same precedence as !), and probably to define const ¬ = ! I actually thought about ¬ when I recently whitelisted a bunch of unicode math symbols in Julia. My hesitation was that I'm not sure what useful purpose ¬ would serve in Julia code, other than as a synonym for !. It's not any shorter than !, and in general in Julia we have tried to avoid introducing redundant syntax (e.g. and and or synonyms for and ||). Following the when in doubt, leave it out philosophy, I therefore left ¬ out of the patch. However, if an argument can be made for the utility of ¬ in Julia, it would be easy to include. --SGJ
[julia-users] Re: Call for Unicode julia source examples
On Wednesday, July 16, 2014 3:56:49 PM UTC-4, Jake Bolewski wrote: That character is probably defined as a unicode 6 math symbol. (No, ¬ has been in Unicode since at least Unicode 4, and probably earlier.)
[julia-users] Re: Call for Unicode julia source examples
Here is a small argument: in SymPy the negation prints with that character. So to match the output I was hoping to utilize (U+00AC) as ! for input. Easy to work around, but it might be nice to have. On Wednesday, July 16, 2014 4:04:07 PM UTC-4, Steven G. Johnson wrote: On Wednesday, July 16, 2014 3:40:31 PM UTC-4, Ben Arthur wrote: julia const ∪ = union ∪ is already defined to union in Julia. julia const ¬ = ! ERROR: syntax: invalid character ¬ The ¬ character (U+00AC) is in category Sm (math symbols), and Julia does not allow all possible math symbols as identifier characters. The reason is that, for each math symbol, we need to individually decide whether it will be parsed as part of an identifier or as an operator. And, if it is parsed as an operator, we need to decide the precedence. In consequence, there is a whitelist of math symbols allowed in identifiers https://github.com/JuliaLang/julia/blob/master/src/flisp/julia_extensions.c#L51-L93 and another whitelist of symbols treated as operators https://github.com/JuliaLang/julia/blob/master/src/julia-parser.scm#L6-L22 Both of these lists will probably grow over time. In the case of ¬, I think it would make sense to parse it as a prefix operator (with the same precedence as !), and probably to define const ¬ = ! I actually thought about ¬ when I recently whitelisted a bunch of unicode math symbols in Julia. My hesitation was that I'm not sure what useful purpose ¬ would serve in Julia code, other than as a synonym for !. It's not any shorter than !, and in general in Julia we have tried to avoid introducing redundant syntax (e.g. and and or synonyms for and ||). Following the when in doubt, leave it out philosophy, I therefore left ¬ out of the patch. However, if an argument can be made for the utility of ¬ in Julia, it would be easy to include. --SGJ
Re: [julia-users] Re: Jupyter project
Also, it gave them a chance to design a snazzy new website! The logo with sun and planets a la Galileo is just brilliant. On Wed, Jul 16, 2014 at 12:15 PM, Steven G. Johnson stevenj@gmail.com wrote: On Tuesday, July 15, 2014 3:46:49 PM UTC-4, Sam L wrote: I haven't heard of it before, but if I understand correctly, the Jupyter project is about splitting the language-agnostic parts of IPython out into its own project. Looks interesting! IPython was already split into language-agnostic front-ends (e.g. the notebook) and a language-specific Python backend. IJulia is based on this: it just replaces the Python backend with a Julia backend. The rebranding of the front-end(s) as Jupyter is a (welcome) acknowledgement of this reality, rather than a substantial change in direction.
[julia-users] Re: Call for Unicode julia source examples
On Wednesday, July 16, 2014 4:12:05 PM UTC-4, j verzani wrote: Here is a small argument: in SymPy the negation prints with that character. So to match the output I was hoping to utilize (U+00AC) as ! for input. Easy to work around, but it might be nice to have. Another argument is simply that we already parse the other logic operators, e.g. ∧ (\wedge) and ∨ (\vee), as operators, so it is a bit perverse not to complete the set and parse ¬ as an operator too. On the other hand, sometimes there are good arguments for not completing a set. For example, we do not, and probably will never, parse a superscript q as an identifier symbol, even though we accept superscript versions of the other 25 lower-case Latin letters. (If you're wondering why, google superscript q unicode and be prepared to tear your hair out.)
[julia-users] Re: Call for Unicode julia source examples
I wonder if we should extend utf8proc to understand the ConScript unicode http://en.wikipedia.org/wiki/ConScript_Unicode_Registryregistry too. That way we can support Klingon and Elvish identifiers in Julia. ;-)
Re: [julia-users] Re: essay on the history of programming languages
Ismael, although ASCIIString is a subtype of String, Array{ASCIIString,1}
is not a subtype of Array{String,1}. As far as I understand Julia has been
designed this way for practical reasons. You can read about it in the
manual's section: Types.
You might want to rewrite your function as
function Pkg.add{T:String}(pkgs::Array{T, 1})
Pkg.update()
for pkg in pkgs
Pkg.add(pkg)
end
end
Re: [julia-users] Re: Jupyter project
It inspires Unicode envy too; they have a Unicode codepoint (♃) for their project, whereas I don't think we'll ever get the Julia logo into Unicode. On Wednesday, July 16, 2014 4:22:36 PM UTC-4, Stefan Karpinski wrote: Also, it gave them a chance to design a snazzy new website! The logo with sun and planets a la Galileo is just brilliant.
Re: [julia-users] Re: my first julia function
@Leah Hanson
Note that helpdb.jl is autogenerated from the .rst files.
doc/stdlib/base.rst
https://raw.githubusercontent.com/JuliaLang/julia/master/doc/stdlib/base.rst
now
contains the documentation, so it should be included in upcoming releases.
There is a problem where some versions of spinx generate extra newlines for
the helpdb file, so many developers are unable to regenerate the file. It
will likely happen soon.
Ivar
kl. 17:41:47 UTC+2 onsdag 16. juli 2014 skrev Leah Hanson følgende:
Help data is hand-written; if no one has documented a function yet, then
it just tells you how many methods there are. `methods(sumabs2)` would show
you the method signatures.
If you want to add to the help documentation, you can edit this file:
https://github.com/JuliaLang/julia/blob/master/doc/helpdb.jl
https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2FJuliaLang%2Fjulia%2Fblob%2Fmaster%2Fdoc%2Fhelpdb.jlsa=Dsntz=1usg=AFQjCNHC8rmXrwvMNTBtg89SPo6CLr-cFw
(You can either use the github interface to edit it online, or, if you have
the Julia source, edit the file locally and make a pull request.)
-- Leah
On Wed, Jul 16, 2014 at 10:36 AM, Neal Becker ndbe...@gmail.com
javascript: wrote:
Dahua Lin wrote:
With the latest Julia, you can do this by
sumabs2(x)
Dahua
On Wednesday, July 16, 2014 9:57:54 AM UTC-5, Neal Becker wrote:
As a first exercise, I wanted to code magnitude squared of a complex
1-d array. Here is what I did:
mag_sqr{T} (x::Array{Complex{T},1}) =
sum(real(x).*real(x)+imag(x).*imag(x))
Is this a good approach? I'm wondering if it's not very efficient,
since I
expect it would compute matrixes of element-wise products first, rather
than
doing the sum as a running summation (like a loop in c++).
Can you suggest something better?
Not exactly answering my question, as I was looking for a learning
opportunity.
But this raises another question:
In [2]:
help(sumabs2)
INFO: Loading help data...
sumabs2 (generic function with 2 methods)
Why is the help data not being shown? (this is ipython notebook interface)
[julia-users] Re: Call for Unicode julia source examples
On Wednesday, July 16, 2014 3:56:49 PM UTC-4, Jake Bolewski wrote: Luckily it seems like Steven Johnson is on a quest to make every possible unicode symbol available in Julia so this should be fixed soon. https://github.com/JuliaLang/julia/pull/7630
Re: [julia-users] Re: ways to improve performance of a non-integer power?
On Wed, Jul 16, 2014 at 12:39 PM, Florian Oswald florian.osw...@gmail.com wrote: do you think this log issue may be worth a mention in the performance tips section of the manual? I would have never guessed that there could be a fast/slow issue with such basic functions. Little do I know! The trouble with mentioning this is that it's an arbitrarily deep rathole. Whole books could (and have) been written on this kind of optimization. But perhaps a passing mention might be good.
[julia-users] Re: Call for Unicode julia source examples
On Wednesday, July 16, 2014 4:45:00 PM UTC-4, Steven G. Johnson wrote: On Wednesday, July 16, 2014 3:56:49 PM UTC-4, Jake Bolewski wrote: Luckily it seems like Steven Johnson is on a quest to make every possible unicode symbol available in Julia so this should be fixed soon. https://github.com/JuliaLang/julia/pull/7630 :-) Is there a good resource to see when a codepoint has been introduced? Probably Wikipedia, but I was lazy when giving my (uninformed) response.
Re: [julia-users] Re: Call for Unicode julia source examples
On Wed, Jul 16, 2014 at 1:04 PM, Steven G. Johnson stevenj@gmail.com
wrote:
∪ is already defined to union in Julia.
Note that it also supports infix syntax:
julia A = Set(1,2,3)
Set{Int64}({2,3,1})
julia B = Set(2,4,5)
Set{Int64}({4,2,5})
julia A ∪ B
Set{Int64}({4,2,3,5,1})
Re: [julia-users] Re: Call for Unicode julia source examples
On Wed, Jul 16, 2014 at 1:12 PM, j verzani jverz...@gmail.com wrote: Here is a small argument: in SymPy the negation prints with that character. So to match the output I was hoping to utilize (U+00AC) as ! for input. Easy to work around, but it might be nice to have. On Wednesday, July 16, 2014 4:04:07 PM UTC-4, Steven G. Johnson wrote: On Wednesday, July 16, 2014 3:40:31 PM UTC-4, Ben Arthur wrote: julia const ∪ = union ∪ is already defined to union in Julia. julia const ¬ = ! ERROR: syntax: invalid character ¬ The ¬ character (U+00AC) is in category Sm (math symbols), and Julia does not allow all possible math symbols as identifier characters. The reason is that, for each math symbol, we need to individually decide whether it will be parsed as part of an identifier or as an operator. And, if it is parsed as an operator, we need to decide the precedence. In consequence, there is a whitelist of math symbols allowed in identifiers https://github.com/JuliaLang/julia/blob/master/src/flisp/ julia_extensions.c#L51-L93 and another whitelist of symbols treated as operators https://github.com/JuliaLang/julia/blob/master/src/julia- parser.scm#L6-L22 Both of these lists will probably grow over time. In the case of ¬, I think it would make sense to parse it as a prefix operator (with the same precedence as !), and probably to define const ¬ = ! I actually thought about ¬ when I recently whitelisted a bunch of unicode math symbols in Julia. My hesitation was that I'm not sure what useful purpose ¬ would serve in Julia code, other than as a synonym for !. It's not any shorter than !, and in general in Julia we have tried to avoid introducing redundant syntax (e.g. and and or synonyms for and ||). Following the when in doubt, leave it out philosophy, I therefore left ¬ out of the patch. However, if an argument can be made for the utility of ¬ in Julia, it would be easy to include. --SGJ How about making ¬ parse as a unary operator with precedence like ! but leave it undefined. It would be pretty weird for ¬ to be part of an identifier and not as a unary operator and that's all we really need to decide.
Re: [julia-users] Re: build-in function to find inverse of a matrix
I agree. What I meant is that since inv is avoided, it's not used nor well referenced in search engines or on this list. :)
Re: [julia-users] Re: Jupyter project
ஃ isn't too bad (via http://shapecatcher.com/) peace, s On Wed, Jul 16, 2014 at 4:38 PM, Steven G. Johnson stevenj@gmail.com wrote: It inspires Unicode envy too; they have a Unicode codepoint (♃) for their project, whereas I don't think we'll ever get the Julia logo into Unicode. On Wednesday, July 16, 2014 4:22:36 PM UTC-4, Stefan Karpinski wrote: Also, it gave them a chance to design a snazzy new website! The logo with sun and planets a la Galileo is just brilliant.
[julia-users] Julia gives numerical results different by a factor of 20 (varies with different input parameters) when comparing to python
Hello, I have a code for calculating some physical quantities. I had a very rough day trying to understand, why my results differ so much from what I should get. Up until I have tried the same code in Python and I got the correct result. Both codes are completely identical, but why is there a difference? Julia code: # THIS IS FOR HETERONUCLEAR PFs Be = [1.8997,1.7153,1.973] De = [0.0,0.0,0.0] He = [0.0,0.0,0.0] we = [2163.9,1812.33,2068.61] alfa_e = [0.0175,0.01727,0.023] beta_e = [0.0,0.0,0.0] wexe = [13.114,12.61,20.2] gamma_e=[0.0,0.0,0.0] weye = [0.0,0.0,0.0] T_e = [0,8215.01,24725.99] w_e=[2,4,2] mu = 6.860525081309955 #m1*m2/(m1+m2) sigma = 1 #1 for hetero, 2 for homonuclear molecules g_n = [1,2,2,2,2,2] T = 2000 #temperature HPLNCK=6.62554e-27 BOLTZK=1.38054e-16 CLIGHT=2.997925e10 const c2=(HPLNCK*CLIGHT)/BOLTZK QQ=0 #over all electronic states in consideration for el=1:length(T_e) nu_max=trunc(we[el]/(2*wexe[el])) #Determine nu_max nu_max2= trunc(Be[el]/alfa_e[el]-0.5) #check nu_max if nu_maxnu_max2 nu_max=nu_max2 end #over all vibrational states until nu_max for nu=1:nu_max aa=(w_e[el]*T)/(sigma*c2) #first term in summation, degeneracies bb=-c2/T*(we[el]*(nu+0.5)-wexe[el]*(nu+0.5)^2+T_e[el]) #exponential part cc=(Be[el]-alfa_e[el]*(nu+0.5)) QQ=QQ+aa*exp(bb)/cc end end first=exp(c2/T*(we[1]/2-wexe[1]/4)) Q_AB=first*QQ println(T, ,Q_AB) Python code: import numpy Be = [1.8997,1.7153,1.973] De = [0.0,0.0,0.0] He = [0.0,0.0,0.0] we = [2163.9,1812.33,2068.61] alfa_e = [0.0175,0.01727,0.023] beta_e = [0.0,0.0,0.0] wexe = [13.114,12.61,20.2] gamma_e=[0.0,0.0,0.0] weye = [0.0,0.0,0.0] T_e = [0,8215.01,24725.99] w_e=[2,4,2] mu = 6.860525081309955 #m1*m2/(m1+m2) sigma = 1 #1 for hetero, 2 for homonuclear molecules g_n = [1,2,2,2,2,2] T = 2000 #temperature #constants HPLNCK=6.62554e-27 BOLTZK=1.38054e-16 CLIGHT=2.997925e10 c2=(HPLNCK*CLIGHT)/BOLTZK QQ=0 #over all electronic states in consideration for el in range(len(T_e)): nu_max=int(we[el]/(2*wexe[el])) #Determine nu_max nu_max2= int(Be[el]/alfa_e[el]-0.5) #check nu_max if nu_maxnu_max2: nu_max=nu_max2 #over all vibrational states until nu_max for nu in range(nu_max): aa=(w_e[el]*T)/(sigma*c2) #first term in summation, degeneracies bb=-c2/T*(we[el]*(nu+0.5)-wexe[el]*(nu+0.5)**2+T_e[el]) #exponential part cc=(Be[el]-alfa_e[el]*(nu+0.5)) QQ=QQ+aa*numpy.exp(bb)/cc first=numpy.exp(c2/T*(we[0]/2-wexe[0]/4)) Q_AB=first*QQ print T= ,T,Q= ,Q_AB
Re: [julia-users] Re: Jupyter project
Oh, excellent. The Julia Unicode character is U+B83 – 'ஃ' – the Tamil character visarga. On Wed, Jul 16, 2014 at 2:08 PM, Spencer Russell s...@mit.edu wrote: ஃ isn't too bad (via http://shapecatcher.com/) peace, s On Wed, Jul 16, 2014 at 4:38 PM, Steven G. Johnson stevenj@gmail.com wrote: It inspires Unicode envy too; they have a Unicode codepoint (♃) for their project, whereas I don't think we'll ever get the Julia logo into Unicode. On Wednesday, July 16, 2014 4:22:36 PM UTC-4, Stefan Karpinski wrote: Also, it gave them a chance to design a snazzy new website! The logo with sun and planets a la Galileo is just brilliant.
Re: [julia-users] Re: essay on the history of programming languages
Thanks for that Pablo! I figured it out, while reading the Multiple Dispatch PDF, I also saw this other way: function Pkg.add(pkgs::String...) Pkg.update() for pkg in pkgs Pkg.add(pkg) end end
Re: [julia-users] Re: Jupyter project
The is also the alchemical symbol for oil http://www.fileformat.info/info/unicode/char/1f746/index.htm ༜
[julia-users] Re: Julia gives numerical results different by a factor of 20 (varies with different input parameters) when comparing to python
Changing the line for nu=1:nu_max to for nu=0:(nu_max-1) makes julia agree with python. On Wednesday, July 16, 2014 1:55:40 PM UTC-7, Andrius Popovas wrote: Hello, I have a code for calculating some physical quantities. I had a very rough day trying to understand, why my results differ so much from what I should get. Up until I have tried the same code in Python and I got the correct result. Both codes are completely identical, but why is there a difference? Julia code: # THIS IS FOR HETERONUCLEAR PFs Be = [1.8997,1.7153,1.973] De = [0.0,0.0,0.0] He = [0.0,0.0,0.0] we = [2163.9,1812.33,2068.61] alfa_e = [0.0175,0.01727,0.023] beta_e = [0.0,0.0,0.0] wexe = [13.114,12.61,20.2] gamma_e=[0.0,0.0,0.0] weye = [0.0,0.0,0.0] T_e = [0,8215.01,24725.99] w_e=[2,4,2] mu = 6.860525081309955 #m1*m2/(m1+m2) sigma = 1 #1 for hetero, 2 for homonuclear molecules g_n = [1,2,2,2,2,2] T = 2000 #temperature HPLNCK=6.62554e-27 BOLTZK=1.38054e-16 CLIGHT=2.997925e10 const c2=(HPLNCK*CLIGHT)/BOLTZK QQ=0 #over all electronic states in consideration for el=1:length(T_e) nu_max=trunc(we[el]/(2*wexe[el])) #Determine nu_max nu_max2= trunc(Be[el]/alfa_e[el]-0.5) #check nu_max if nu_maxnu_max2 nu_max=nu_max2 end #over all vibrational states until nu_max for nu=1:nu_max aa=(w_e[el]*T)/(sigma*c2) #first term in summation, degeneracies bb=-c2/T*(we[el]*(nu+0.5)-wexe[el]*(nu+0.5)^2+T_e[el]) #exponential part cc=(Be[el]-alfa_e[el]*(nu+0.5)) QQ=QQ+aa*exp(bb)/cc end end first=exp(c2/T*(we[1]/2-wexe[1]/4)) Q_AB=first*QQ println(T, ,Q_AB) Python code: import numpy Be = [1.8997,1.7153,1.973] De = [0.0,0.0,0.0] He = [0.0,0.0,0.0] we = [2163.9,1812.33,2068.61] alfa_e = [0.0175,0.01727,0.023] beta_e = [0.0,0.0,0.0] wexe = [13.114,12.61,20.2] gamma_e=[0.0,0.0,0.0] weye = [0.0,0.0,0.0] T_e = [0,8215.01,24725.99] w_e=[2,4,2] mu = 6.860525081309955 #m1*m2/(m1+m2) sigma = 1 #1 for hetero, 2 for homonuclear molecules g_n = [1,2,2,2,2,2] T = 2000 #temperature #constants HPLNCK=6.62554e-27 BOLTZK=1.38054e-16 CLIGHT=2.997925e10 c2=(HPLNCK*CLIGHT)/BOLTZK QQ=0 #over all electronic states in consideration for el in range(len(T_e)): nu_max=int(we[el]/(2*wexe[el])) #Determine nu_max nu_max2= int(Be[el]/alfa_e[el]-0.5) #check nu_max if nu_maxnu_max2: nu_max=nu_max2 #over all vibrational states until nu_max for nu in range(nu_max): aa=(w_e[el]*T)/(sigma*c2) #first term in summation, degeneracies bb=-c2/T*(we[el]*(nu+0.5)-wexe[el]*(nu+0.5)**2+T_e[el]) #exponential part cc=(Be[el]-alfa_e[el]*(nu+0.5)) QQ=QQ+aa*numpy.exp(bb)/cc first=numpy.exp(c2/T*(we[0]/2-wexe[0]/4)) Q_AB=first*QQ print T= ,T,Q= ,Q_AB
Re: [julia-users] Julia gives numerical results different by a factor of 20 (varies with different input parameters) when comparing to python
In such cases I'd recommend printing the values at each step to see where they first differ. --Tim On Wednesday, July 16, 2014 01:55:40 PM Andrius Popovas wrote: Hello, I have a code for calculating some physical quantities. I had a very rough day trying to understand, why my results differ so much from what I should get. Up until I have tried the same code in Python and I got the correct result. Both codes are completely identical, but why is there a difference? Julia code: # THIS IS FOR HETERONUCLEAR PFs Be = [1.8997,1.7153,1.973] De = [0.0,0.0,0.0] He = [0.0,0.0,0.0] we = [2163.9,1812.33,2068.61] alfa_e = [0.0175,0.01727,0.023] beta_e = [0.0,0.0,0.0] wexe = [13.114,12.61,20.2] gamma_e=[0.0,0.0,0.0] weye = [0.0,0.0,0.0] T_e = [0,8215.01,24725.99] w_e=[2,4,2] mu = 6.860525081309955 #m1*m2/(m1+m2) sigma = 1 #1 for hetero, 2 for homonuclear molecules g_n = [1,2,2,2,2,2] T = 2000 #temperature HPLNCK=6.62554e-27 BOLTZK=1.38054e-16 CLIGHT=2.997925e10 const c2=(HPLNCK*CLIGHT)/BOLTZK QQ=0 #over all electronic states in consideration for el=1:length(T_e) nu_max=trunc(we[el]/(2*wexe[el])) #Determine nu_max nu_max2= trunc(Be[el]/alfa_e[el]-0.5) #check nu_max if nu_maxnu_max2 nu_max=nu_max2 end #over all vibrational states until nu_max for nu=1:nu_max aa=(w_e[el]*T)/(sigma*c2) #first term in summation, degeneracies bb=-c2/T*(we[el]*(nu+0.5)-wexe[el]*(nu+0.5)^2+T_e[el]) #exponential part cc=(Be[el]-alfa_e[el]*(nu+0.5)) QQ=QQ+aa*exp(bb)/cc end end first=exp(c2/T*(we[1]/2-wexe[1]/4)) Q_AB=first*QQ println(T, ,Q_AB) Python code: import numpy Be = [1.8997,1.7153,1.973] De = [0.0,0.0,0.0] He = [0.0,0.0,0.0] we = [2163.9,1812.33,2068.61] alfa_e = [0.0175,0.01727,0.023] beta_e = [0.0,0.0,0.0] wexe = [13.114,12.61,20.2] gamma_e=[0.0,0.0,0.0] weye = [0.0,0.0,0.0] T_e = [0,8215.01,24725.99] w_e=[2,4,2] mu = 6.860525081309955 #m1*m2/(m1+m2) sigma = 1 #1 for hetero, 2 for homonuclear molecules g_n = [1,2,2,2,2,2] T = 2000 #temperature #constants HPLNCK=6.62554e-27 BOLTZK=1.38054e-16 CLIGHT=2.997925e10 c2=(HPLNCK*CLIGHT)/BOLTZK QQ=0 #over all electronic states in consideration for el in range(len(T_e)): nu_max=int(we[el]/(2*wexe[el])) #Determine nu_max nu_max2= int(Be[el]/alfa_e[el]-0.5) #check nu_max if nu_maxnu_max2: nu_max=nu_max2 #over all vibrational states until nu_max for nu in range(nu_max): aa=(w_e[el]*T)/(sigma*c2) #first term in summation, degeneracies bb=-c2/T*(we[el]*(nu+0.5)-wexe[el]*(nu+0.5)**2+T_e[el]) #exponential part cc=(Be[el]-alfa_e[el]*(nu+0.5)) QQ=QQ+aa*numpy.exp(bb)/cc first=numpy.exp(c2/T*(we[0]/2-wexe[0]/4)) Q_AB=first*QQ print T= ,T,Q= ,Q_AB
Re: [julia-users] Re: Jupyter project
And we have also, Julia the Language Predator https://encrypted-tbn1.gstatic.com/images?q=tbn:ANd9GcT1MtrE5eL7PDMoMJRwci9TPqfoeUWNXMStctBOEUzufAipdrvm8Q https://encrypted-tbn1.gstatic.com/images?q=tbn:ANd9GcT1MtrE5eL7PDMoMJRwci9TPqfoeUWNXMStctBOEUzufAipdrvm8Q Quarta-feira, 16 de Julho de 2014 22:25:19 UTC+1, Luke Stagner escreveu: The is also the alchemical symbol for oil http://www.fileformat.info/info/unicode/char/1f746/index.htm ༜
[julia-users] Re: ways to improve performance of a non-integer power?
And Florian Oswald writes: I would have never guessed that there could be a fast/slow issue with such basic functions. Little do I know! See also Jean-Michel Muller's text on Elementary Functions, Algorithms and Implementation and others (including, imho, Markstein's IA-64 and Elementary Functions: Speed and Precision for very concrete descriptions of trade-offs on one (possibly odd) architecture). It'd be fantastic if something like the NIST Digital Library of Mathematical Functions (http://dlmf.nist.gov/) discussed more of the computational trade-offs, but there are the dual issues of funding and the slow deterioration of knowledge. There might be a role for a high-performance, high-level, free language like Julia here. A few people have made routines dependable enough that few people worry. While this is good for general use, it creates a difficult position for continuing the knowledge. I know that I don't have it...
[julia-users] Re: PSA: Julia 0.3-RC1 packages working well again
It's a little late now, but I have updated Lint.jl to warn on extending a
deprecated function. It parses the deprecated.jl and keeps a list. If a new
function definition matches the signature of a deprecated function, it'd
give a lint error. The definition of a match is more relaxed than the
typical invariant style w.r.t. ADT such as Array{ Real, 1} so it should
catch reasonably specialized forms of a function.
Hopefully it'd be more useful the next time we have API migration.
On Thursday, July 17, 2014 2:12:04 AM UTC+7, Iain Dunning wrote:
Hi all,
If you updated to Julia 0.3-RC1 in the past couple of days, you may have
noticed issues with many packages. This was due to deprecated functions
that were deprecated in the previous release cycle being finally removed.
Most packages affected by this have fixed these minor issues so if you run
Pkg.update() you should be OK. Please do give 0.3-RC1 a good try so as many
bugs are flushed out before 0.3 is released as possible.
Cheers,
Iain
Re: [julia-users] Re: ways to improve performance of a non-integer power?
Hi Stefan, I've got no idea about the technical implications, i.e. why julia's log is slower (on some systems?) than libm's and what's involved in bringing performance up to par. I mentioned the manual only because this is the second time that someone suggests the system-log trick to me, and it paid off handsomely in both occasions. Now, I am perfectly happy to keep it at that. I suspect however that there are a) plenty of dirty tricks I don't know of yet and b) plenty of people who don't either. the thorny issue of deciding when a trick becomes dirty is of course up to you. To be honest I'm not sure if the manual is the right place for things like that - but it would be good to have them in *some* place. cheers florian On Wednesday, 16 July 2014 21:47:58 UTC+1, Stefan Karpinski wrote: On Wed, Jul 16, 2014 at 12:39 PM, Florian Oswald florian...@gmail.com javascript: wrote: do you think this log issue may be worth a mention in the performance tips section of the manual? I would have never guessed that there could be a fast/slow issue with such basic functions. Little do I know! The trouble with mentioning this is that it's an arbitrarily deep rathole. Whole books could (and have) been written on this kind of optimization. But perhaps a passing mention might be good.
[julia-users] Re: build-in function to find inverse of a matrix
any reason of avoiding inv?
[julia-users] any packages for AI usage
namely, different linear regression, logistical regression, gradient descent, neural network backprop, etc?
Re: [julia-users] Re: Capture the output of Julia's console
Interesting. Can you (or did you) file an issue? Cheers, Kevin On Wed, Jul 16, 2014 at 4:36 PM, Laszlo Hars laszloh...@gmail.com wrote: I hoped that at some point Julia error messages would again appear in STDERR. No luck. Even the Release candidate 0.3.0-rc1 fails to write, e.g. DomainError to STDERR (provoked by 1^-1 entered in the Windows REPL). Maybe the documentation should mention that STDERR is for warnings, only.
Re: [julia-users] insert! function only for item not items
Thanks!
Could you perhaps point me to a place where these sort of things may be
documented?
Trying to adopt the language has been less painful than Python was. Python
however, has better documentation currently for these kind of small things.
Python is also far more mature so go_figure! (go_figure! alters its
contents :D)
It may just be me however missing an obvious result in Google.
On Wednesday, 16 July 2014 03:11:30 UTC+2, Kevin Squire wrote:
Hi Michael,
You can actually use splice!:
julia splice!(x, 3:2, y)
0-element Array{Int64,1}
julia x
8-element Array{Int64,1}:
1
2
3
4
5
6
7
8
3:2 is a convention in julia that indicates the (empty) location in the
array between index 2 and index 3 (e.g., searchsorted(x,3) for your
original x will return 3:2 as the insertion point).
Note that splice returns any removed (spliced out) elements, which is
why the return value of the first command above is empty
Hope this helps!
Cheers,
Kevin
On Tue, Jul 15, 2014 at 5:23 PM, Michael Louwrens
michael.w...@outlook.com javascript: wrote:
Should insert! not be able to insert a collection?
x = [1,2,7,8]
y = [3,4,5,6]
insert!(x,2+1,y)
Is then unable to complete the insertion and create [1,2,3,4,5,6,7,8].
There is a costlier way to do this at the moment however.
splice! almost replicates the required functionality but it replaces the
item at 2 instead of inserting items after position2.
x = [1,2,7,8]
y = [3,4,5,6]
splice!(x,2,unshift!(y,x[2]))
This is about 20% slower but does work.
I was surprised that insert! inserts the item before the item at that
index instead of after. Could this perhaps be mentioned in the doc for
insert!?
Perhaps my Google-Fu is weak, but I could not find any reference to say
which behaviour it should have.
Just wanted to point out that currently insert! only works for a single
item instead of a single item and collections and to inquire if there is
not perhaps a better workaround than the above.
Thanks!
Re: [julia-users] Re: Capture the output of Julia's console
I don't know, how to file an issue. Where can I get instructions? (The STDERR behavior may be intentional. I kept asking about it in this group, for months, but nobody was interested.) On Wednesday, July 16, 2014 6:36:23 PM UTC-6, Kevin Squire wrote: Interesting. Can you (or did you) file an issue? Cheers, Kevin On Wed, Jul 16, 2014 at 4:36 PM, Laszlo Hars laszl...@gmail.com javascript: wrote: I hoped that at some point Julia error messages would again appear in STDERR. No luck. Even the Release candidate 0.3.0-rc1 fails to write, e.g. DomainError to STDERR (provoked by 1^-1 entered in the Windows REPL). Maybe the documentation should mention that STDERR is for warnings, only.
Re: [julia-users] insert! function only for item not items
Yep, Python documentation is quite good, and Julia's has a little ways to
go. (Did you see Python's documentation 10 years ago, though? ;-)
There wasn't much, if any, documentation about n:n-1 empty ranges or
splicing without removal, so I just added some (
https://github.com/JuliaLang/julia/pull/7631). These will appear online as
soon as someone regenerates the documentation (it might take a few days).
The main sections I updated are
http://docs.julialang.org/en/latest/manual/arrays/#indexing and
http://docs.julialang.org/en/latest/stdlib/base/#Base.splice!. The updates
are minimal, though, and so it's still possible to overlook.
I was thinking that your first question/point actually makes some sense.
push! allows adding multiple items at the end of a list via
push!(list, 1,2,3)
so it would make sense that you could also do
insert!(list, 4, 'a', 'b', 'c')
It also might make sense to have a `splicein!` or `insertat!` function,
which just inserts values into a collection and returns the full
collection. (Issue discussing this is here:
https://github.com/JuliaLang/julia/issues/7632
Cheers!
Kevin
On Wed, Jul 16, 2014 at 5:41 PM, Michael Louwrens
michael.w.louwr...@outlook.com wrote:
Thanks!
Could you perhaps point me to a place where these sort of things may be
documented?
Trying to adopt the language has been less painful than Python was. Python
however, has better documentation currently for these kind of small things.
Python is also far more mature so go_figure! (go_figure! alters its
contents :D)
It may just be me however missing an obvious result in Google.
On Wednesday, 16 July 2014 03:11:30 UTC+2, Kevin Squire wrote:
Hi Michael,
You can actually use splice!:
julia splice!(x, 3:2, y)
0-element Array{Int64,1}
julia x
8-element Array{Int64,1}:
1
2
3
4
5
6
7
8
3:2 is a convention in julia that indicates the (empty) location in the
array between index 2 and index 3 (e.g., searchsorted(x,3) for your
original x will return 3:2 as the insertion point).
Note that splice returns any removed (spliced out) elements, which is
why the return value of the first command above is empty
Hope this helps!
Cheers,
Kevin
On Tue, Jul 15, 2014 at 5:23 PM, Michael Louwrens michael.w...@outlook.
com wrote:
Should insert! not be able to insert a collection?
x = [1,2,7,8]
y = [3,4,5,6]
insert!(x,2+1,y)
Is then unable to complete the insertion and create [1,2,3,4,5,6,7,8].
There is a costlier way to do this at the moment however.
splice! almost replicates the required functionality but it replaces the
item at 2 instead of inserting items after position2.
x = [1,2,7,8]
y = [3,4,5,6]
splice!(x,2,unshift!(y,x[2]))
This is about 20% slower but does work.
I was surprised that insert! inserts the item before the item at that
index instead of after. Could this perhaps be mentioned in the doc for
insert!?
Perhaps my Google-Fu is weak, but I could not find any reference to say
which behaviour it should have.
Just wanted to point out that currently insert! only works for a single
item instead of a single item and collections and to inquire if there is
not perhaps a better workaround than the above.
Thanks!
Re: [julia-users] Re: Capture the output of Julia's console
I think the change in the STDERR behavior was intentional, once we got rid of the limitations of using libreadline. Now we can run multiple simultaneous independent REPL loops, thanks to Keno's work. Redirecting STDERR and having that propagate to the stderr stream used by the REPL was a limitation in 0.2 which no longer exists in 0.3. I wouldn't expect it to be reintroduced. Steve Johnson has provided solutions several times. Such as https://gist.github.com/stevengj/88502943fe0478933492, if you want to hook into the existing REPL, or while true println(RESULT: , eval(parse(readline( end if you want to roll your own. Implementing a good REPL requires interacting with the user, so it is inherently a hard task and thus may needs a fairly large amount of code to configure and manage the program's state to stay synchronize with the user's expectations. PS: https://github.com/JuliaLang/julia/issues/7633 On Wed, Jul 16, 2014 at 8:48 PM, Laszlo Hars laszloh...@gmail.com wrote: I don't know, how to file an issue. Where can I get instructions? (The STDERR behavior may be intentional. I kept asking about it in this group, for months, but nobody was interested.) On Wednesday, July 16, 2014 6:36:23 PM UTC-6, Kevin Squire wrote: Interesting. Can you (or did you) file an issue? Cheers, Kevin On Wed, Jul 16, 2014 at 4:36 PM, Laszlo Hars laszl...@gmail.com wrote: I hoped that at some point Julia error messages would again appear in STDERR. No luck. Even the Release candidate 0.3.0-rc1 fails to write, e.g. DomainError to STDERR (provoked by 1^-1 entered in the Windows REPL). Maybe the documentation should mention that STDERR is for warnings, only.
Re: [julia-users] Re: Capture the output of Julia's console
Per Jameson's response and my own testing, it seems like the STDERR issues have been resolved (perhaps after rc1?): $ julia -e 'throw(DomainError())' 1 stdout.txt 2 stderr.txt $ cat stdout.txt $ cat stderr.txt ERROR: DomainError in process_options at ./client.jl:213 in _start at ./client.jl:354 For future reference, you can search for current issues and file new ones at https://github.com/JuliaLang/julia. Click on the Issues tab on the right. Search is located at the top. Cheers, Kevin On Wed, Jul 16, 2014 at 5:48 PM, Laszlo Hars laszloh...@gmail.com wrote: I don't know, how to file an issue. Where can I get instructions? (The STDERR behavior may be intentional. I kept asking about it in this group, for months, but nobody was interested.) On Wednesday, July 16, 2014 6:36:23 PM UTC-6, Kevin Squire wrote: Interesting. Can you (or did you) file an issue? Cheers, Kevin On Wed, Jul 16, 2014 at 4:36 PM, Laszlo Hars laszl...@gmail.com wrote: I hoped that at some point Julia error messages would again appear in STDERR. No luck. Even the Release candidate 0.3.0-rc1 fails to write, e.g. DomainError to STDERR (provoked by 1^-1 entered in the Windows REPL). Maybe the documentation should mention that STDERR is for warnings, only.
Re: [julia-users] Re: Capture the output of Julia's console
Or not. See https://github.com/JuliaLang/julia/issues/7633. On Wed, Jul 16, 2014 at 7:13 PM, Kevin Squire kevin.squ...@gmail.com wrote: Per Jameson's response and my own testing, it seems like the STDERR issues have been resolved (perhaps after rc1?): $ julia -e 'throw(DomainError())' 1 stdout.txt 2 stderr.txt $ cat stdout.txt $ cat stderr.txt ERROR: DomainError in process_options at ./client.jl:213 in _start at ./client.jl:354 For future reference, you can search for current issues and file new ones at https://github.com/JuliaLang/julia. Click on the Issues tab on the right. Search is located at the top. Cheers, Kevin On Wed, Jul 16, 2014 at 5:48 PM, Laszlo Hars laszloh...@gmail.com wrote: I don't know, how to file an issue. Where can I get instructions? (The STDERR behavior may be intentional. I kept asking about it in this group, for months, but nobody was interested.) On Wednesday, July 16, 2014 6:36:23 PM UTC-6, Kevin Squire wrote: Interesting. Can you (or did you) file an issue? Cheers, Kevin On Wed, Jul 16, 2014 at 4:36 PM, Laszlo Hars laszl...@gmail.com wrote: I hoped that at some point Julia error messages would again appear in STDERR. No luck. Even the Release candidate 0.3.0-rc1 fails to write, e.g. DomainError to STDERR (provoked by 1^-1 entered in the Windows REPL). Maybe the documentation should mention that STDERR is for warnings, only.
Re: [julia-users] Re: Capture the output of Julia's console
the STDERR behavior was intentional 1) It just does not seem to be logical: warning messages still get written to STDERR. Why? And what is the use of STDERR, in general? STDERR is in the documentation, without telling anything about it. 2) The REPL behavior ought to be documented, otherwise new users would naively think that error messages are sent to STDERR, as regular console (REPL) output is available in STDOUT, and user input is seen in STDIN. So what is so special about error messages sent to STDERR? (Btw. error messages are not sent to STDOUT, either, they are just displayed in the console window.) Steve Johnson has provided solutions several times Unfortunately, his solutions either don't work or they are so complicated, that I cannot include them into my programs. println(RESULT: , eval(parse(readline( As we discussed it several times, this does not work with multi-line input. Sure, I can write my own REPL, but this is not the issue here. We should not have to do it, since there is one included in the Julia distribution. It just does not seem to have sufficient documentation. On Wednesday, July 16, 2014 8:07:00 PM UTC-6, Jameson wrote: I think the change in the STDERR behavior was intentional, once we got rid of the limitations of using libreadline. Now we can run multiple simultaneous independent REPL loops, thanks to Keno's work. Redirecting STDERR and having that propagate to the stderr stream used by the REPL was a limitation in 0.2 which no longer exists in 0.3. I wouldn't expect it to be reintroduced. Steve Johnson has provided solutions several times. Such as https://gist.github.com/stevengj/88502943fe0478933492, if you want to hook into the existing REPL, or while true println(RESULT: , eval(parse(readline( end if you want to roll your own. Implementing a good REPL requires interacting with the user, so it is inherently a hard task and thus may needs a fairly large amount of code to configure and manage the program's state to stay synchronize with the user's expectations. PS: https://github.com/JuliaLang/julia/issues/7633 On Wed, Jul 16, 2014 at 8:48 PM, Laszlo Hars laszl...@gmail.com javascript: wrote: I don't know, how to file an issue. Where can I get instructions? (The STDERR behavior may be intentional. I kept asking about it in this group, for months, but nobody was interested.) On Wednesday, July 16, 2014 6:36:23 PM UTC-6, Kevin Squire wrote: Interesting. Can you (or did you) file an issue? Cheers, Kevin On Wed, Jul 16, 2014 at 4:36 PM, Laszlo Hars laszl...@gmail.com wrote: I hoped that at some point Julia error messages would again appear in STDERR. No luck. Even the Release candidate 0.3.0-rc1 fails to write, e.g. DomainError to STDERR (provoked by 1^-1 entered in the Windows REPL). Maybe the documentation should mention that STDERR is for warnings, only.
[julia-users] Julia idiom for something like CLOS's call-next-method
Most multimethod systems seem to have a way to call the next-most-general method of a function, but I'm not seeing a good way to do that in Julia. This is complicated by the fact that my sense of what's idiomatically clean in Julia isn't very well honed yet. If Julia had CLOS's call-next-method I could get the results I'm looking for by writing something like: abstract Fu function bar(f::Fu) print(Bar\n) end type Foo : Fu end function bar(f::Foo) print(Oooo...\n) call-next-method() # -- CLOS, not Julia end bar(Foo()) (which I would expect to emit Oooo...Bar\n). Similar results can be obtained in other languages with super, inherited, etc. or by casting the appropriate argument to the (in Julia, abstract) parent type. My question: what's the right way to do this in Julia? -- MarkusQ P.S. An around-method analogue would work too, though it doesn't feel as semantically appropriate.
Re: [julia-users] Julia idiom for something like CLOS's call-next-method
Usually the answer to this is to factor your methods so this is unnecessary (e.g. by having a secondary method that does the actual work). If that doesn't work for you for some reason, there's also `invoke(bar,(Fu,),f)` which does what you want. On Wed, Jul 16, 2014 at 9:03 PM, Markus Roberts mar...@reality.com wrote: Most multimethod systems seem to have a way to call the next-most-general method of a function, but I'm not seeing a good way to do that in Julia. This is complicated by the fact that my sense of what's idiomatically clean in Julia isn't very well honed yet. If Julia had CLOS's call-next-method I could get the results I'm looking for by writing something like: abstract Fu function bar(f::Fu) print(Bar\n) end type Foo : Fu end function bar(f::Foo) print(Oooo...\n) call-next-method() # -- CLOS, not Julia end bar(Foo()) (which I would expect to emit Oooo...Bar\n). Similar results can be obtained in other languages with super, inherited, etc. or by casting the appropriate argument to the (in Julia, abstract) parent type. My question: what's the right way to do this in Julia? -- MarkusQ P.S. An around-method analogue would work too, though it doesn't feel as semantically appropriate.
Re: [julia-users] Julia idiom for something like CLOS's call-next-method
If you replace call-next-method() with invoke(bar,(Fu,),f) then it does what you want. The situation in Julia is a bit more complicated since you don't know which argument(s) you want to push further up the type lattice. The invoke function works by letting you specify exactly which less specific type signature you would like to invoke the function with. On Wed, Jul 16, 2014 at 9:03 PM, Markus Roberts mar...@reality.com wrote: Most multimethod systems seem to have a way to call the next-most-general method of a function, but I'm not seeing a good way to do that in Julia. This is complicated by the fact that my sense of what's idiomatically clean in Julia isn't very well honed yet. If Julia had CLOS's call-next-method I could get the results I'm looking for by writing something like: abstract Fu function bar(f::Fu) print(Bar\n) end type Foo : Fu end function bar(f::Foo) print(Oooo...\n) call-next-method() # -- CLOS, not Julia end bar(Foo()) (which I would expect to emit Oooo...Bar\n). Similar results can be obtained in other languages with super, inherited, etc. or by casting the appropriate argument to the (in Julia, abstract) parent type. My question: what's the right way to do this in Julia? -- MarkusQ P.S. An around-method analogue would work too, though it doesn't feel as semantically appropriate.
Re: [julia-users] Re: build-in function to find inverse of a matrix
It's a bit of numerical computing lore that inv is bad – both for performance and for numerical accuracy. It turns out it may not be so bad http://arxiv.org/pdf/1201.6035v1.pdf after all, but everyone is still kind of wary of it and there are often better ways to solve problems where inv would be the naive way to do it. On Wed, Jul 16, 2014 at 3:59 PM, Alan Chan szelok.c...@gmail.com wrote: any reason of avoiding inv?
