Re: [julia-users] function perlRegexReplace
#Version 4 #More optimization done function perlRegexReplace(str::ASCIIString,regex::Regex,rep::ASCIIString) local m,result,inter result = replace(str,regex,rep) inter = eachmatch(regex,str) for (m in inter) for k = 1:length(m.captures) result = replace(result,char(k),m.captures[k],1) end end result end originalstring=Mary had a little lamb, her skin is as white as snow resultstring = perlRegexReplace(originalstring,r\b([\w]*e) ([\w]*),not \1 black \2) println(ORIGINAL: ,originalstring) println(RESULTST: ,resultstring) On Wednesday, August 13, 2014 8:19:08 PM UTC+10, Kevin Squire wrote: I implemented something related to this a long time ago ( https://github.com/JuliaLang/julia/pull/1448). At the time, Stefan agreed that something like it was needed, but didn't like my implementation. Still hasn't happened (other things have had greater priority), but I think it would be worthwhile. Kevin On Wed, Aug 13, 2014 at 12:07 AM, Jameson Nash vtj...@gmail.com javascript: wrote: right, in other words, it implements backreference substitutions On Wed, Aug 13, 2014 at 3:01 AM, Steven Siew steve...@gmail.com javascript: wrote: replace(*string*, *pat*, *r*[, *n*]) Search for the given pattern pat, and replace each occurrence with r. If n is provided, replace at most n occurrences. As with search, the second argument may be a single character, a vector or a set of characters, a string, or a regular expression. If r is a function, each occurrence is replaced with r(s) where s is the matched substring. _ _ _ _(_)_ | A fresh approach to technical computing (_) | (_) (_)| Documentation: http://docs.julialang.org _ _ _| |_ __ _ | Type help() to list help topics | | | | | | |/ _` | | | | |_| | | | (_| | | Version 0.2.0 (2013-11-16 23:44 UTC) _/ |\__'_|_|_|\__'_| | Official http://julialang.org release |__/ | i686-w64-mingw32 julia originalstring=Mary had a little lamb, her skin is as white as snow Mary had a little lamb, her skin is as white as snow julia replace(originalstring,r\b([\w]*e) ([\w]*),not \1 black \2) Mary had a not \x01 black \x02, her skin is as not \x01 black \x02 snow On Wednesday, August 13, 2014 4:05:23 PM UTC+10, John Myles White wrote: Suspect I'm missing something. How is this different from the existing function replace? -- John On Aug 12, 2014, at 11:03 PM, Steven Siew steve...@gmail.com wrote: Using regex like in the programming language Perl to perform replacements. function perlRegexReplace(str::ASCIIString,regex::Regex,rep::ASCIIString) local m,len,result,inter m = match(regex,str) len=length(m.captures) result = replace(str,regex,rep) if len 0 inter = eachmatch(regex,str) for (m in inter) for k = 1:len # Comment out the next line when using function for production println(Replacing \\,k, with ,m.captures[k]) result = replace(result,char(k),m.captures[k],1) end end end result end originalstring=Mary had a little lamb, her skin is as white as snow resultstring = perlRegexReplace(originalstring,r\b([\w]*e) ([\w]*),not \1 black \2) println(ORIGINAL: ,originalstring) println(RESULTST: ,resultstring) == C:\oracle\julia\scripts ..\julia.bat perlRegexReplace3.jl Replacing \1 with little Replacing \2 with lamb Replacing \1 with white Replacing \2 with as ORIGINAL: Mary had a little lamb, her skin is as white as snow RESULTST: Mary had a not little black lamb, her skin is as not white black as snow
Re: [julia-users] Create matrix from a comprehension with row/col-returning function?
hcat([f(i) for i = 1:n]...) Or use vcat for adding rows.
Re: [julia-users] Gibbs sampling 10x slower than c++
Excellent, thanks. Replacing `@inbounds a = dot(W[:,n], state)` with the following gave a ~5x improvement: a::Float64 = 0 for k in 1:N @inbounds a += W[k, n] * state[k] end The ::Float64 annotation was necessary or it was really slow. Why does Julia copy the column before using it in the expression? Andrew On Thursday, August 14, 2014 2:40:54 PM UTC+10, John Myles White wrote: Here are some things you might try: (1) Don’t use a global const. Pass N as an argument to all functions. (2) Use in-place multiplication via functions like A_mul_B! in lines like `@inbounds a = dot(W[:,n], state)`. In Julia 0.3, W[:,n] creates a copy of that column of W on every iteration. (3) Don’t make full copies of state in lines like `@inbounds samples[:,i] = copy(state)`. Do explicit elementwise copying, which is much cheaper. — John On Aug 13, 2014, at 9:14 PM, Andrew Wrigley and...@wrigley.io javascript: wrote: gibbstiming.jl
Re: [julia-users] Gibbs sampling 10x slower than c++
Regarding the need for annotation. There is a good reason for this and its that the type should be kept stable during calculations. `a = 0` will set a to be an Int with value 0. Later it is updated with Float64 values and therefore the performance loss. You can solve this in different variants a::Float64 = 0 a = 0.0 a = zero(Float64) a = zero(state[0]) The last one is esspecially useful when writing generic code and found at various places in the Julia base library. The point is to make this fast for any type and not only Float64. The copying of columns / slices is about to change in future versions of Julia. It will return a view then. Cheers, Tobias Am Donnerstag, 14. August 2014 09:57:12 UTC+2 schrieb Andrew Wrigley: Excellent, thanks. Replacing `@inbounds a = dot(W[:,n], state)` with the following gave a ~5x improvement: a::Float64 = 0 for k in 1:N @inbounds a += W[k, n] * state[k] end The ::Float64 annotation was necessary or it was really slow. Why does Julia copy the column before using it in the expression? Andrew On Thursday, August 14, 2014 2:40:54 PM UTC+10, John Myles White wrote: Here are some things you might try: (1) Don’t use a global const. Pass N as an argument to all functions. (2) Use in-place multiplication via functions like A_mul_B! in lines like `@inbounds a = dot(W[:,n], state)`. In Julia 0.3, W[:,n] creates a copy of that column of W on every iteration. (3) Don’t make full copies of state in lines like `@inbounds samples[:,i] = copy(state)`. Do explicit elementwise copying, which is much cheaper. — John On Aug 13, 2014, at 9:14 PM, Andrew Wrigley and...@wrigley.io wrote: gibbstiming.jl
Re: [julia-users] Gibbs sampling 10x slower than c++
I have not heard it explicitly from the developers, but it seems obvious to me that implementing slicing as a view into the original array, is hard to do right, while a copy is simple. They probably wanted to do the simple thing first, and then solve the harder problem when things settle down. This behaviour will likely change soon and be included in the 0.4 release. Ivar kl. 09:57:12 UTC+2 torsdag 14. august 2014 skrev Andrew Wrigley følgende: Excellent, thanks. Replacing `@inbounds a = dot(W[:,n], state)` with the following gave a ~5x improvement: a::Float64 = 0 for k in 1:N @inbounds a += W[k, n] * state[k] end The ::Float64 annotation was necessary or it was really slow. Why does Julia copy the column before using it in the expression? Andrew On Thursday, August 14, 2014 2:40:54 PM UTC+10, John Myles White wrote: Here are some things you might try: (1) Don’t use a global const. Pass N as an argument to all functions. (2) Use in-place multiplication via functions like A_mul_B! in lines like `@inbounds a = dot(W[:,n], state)`. In Julia 0.3, W[:,n] creates a copy of that column of W on every iteration. (3) Don’t make full copies of state in lines like `@inbounds samples[:,i] = copy(state)`. Do explicit elementwise copying, which is much cheaper. — John On Aug 13, 2014, at 9:14 PM, Andrew Wrigley and...@wrigley.io wrote: gibbstiming.jl
Re: [julia-users] Proposal for inargs
For any algorithm that accepts AbstractArrays, can't you just just define
immutable ReadOnlyArray{T,N,AT:AbstractArray} : AbstractArray{T,N}
data::AT
end
ReadOnlyArray{AT:AbstractArray}(A::AT) =
ReadOnlyArray{eltype(A),ndims(A),typeof(A)}(A)
and then define the pass-through methods you want to support? That way can wrap
any array type.
Also, you could easily create your own package that does this. I don't see any
particular requirement to have it in base.
One nit: can you really support your assertion that C++ and Fortran are the
two major languages of scientific computing? In my world, Matlab is used by
about 20x (maybe 50x) as many people as C++. I suspect there's a major divide
depending on field. Science is a big place.
--Tim
On Wednesday, August 13, 2014 03:19:36 PM vava...@uwaterloo.ca wrote:
Dear Julia colleagues,
In June, I wondered on this newsgroup why Julia lacks an 'inarg'
specification for functions. The two major languages used nowadays for
scientific programming, namely Fortran and C++, both provide mechanisms to
declare that a function argument is read-only by the function. Indeed,
this was added to Fortran late in its life, so one assumes that there is
some bitter experience underlying the decision to include it in Fortran.
(Matlab has only inargs, at least until you get to relatively advanced
programming techniques, so this is not an issue.)
Stefan Karpinski provided a convincing explanation for why inarg and outarg
specifications have been omitted from the Julia core. Now that I am
slightly more familiar with Julia, I would like to make a proposal for
inarg that would not require changes to the core language. The proposal
would, however, entail substantial additional code, so it is intended for
some version of Julia in the future.
Here is the proposal: suppose fn is a function that takes an array input
a and wants to declare it to be read-only. Then at the beginning of the
function before any of the arguments gets used, there would be an
assignment statement like this:
function fn(a::AbstractArray{Int,1})
a = readonly(a)
The way this would work is as follows: Julia would have new types, mostly
invisible to the user, like ReadOnlyArray which would have a setindex!
method that would throw an error, Then there would be methods like
readonly{T.N}(a::Array{T,N}) that would use 'reinterpret' to change the
Array to a ReadOnlyArray. A programmer who wanted to write a function that
could take either arrays or readonlyarrays as inputs would have to declare
abstract argument types like DenseArray or AbstractArray. The user would
not, in general, have to worry about the read-only types; the situation
when a user would have to worry about them is if he/she wants to develop a
read-only version of his/her own data structure that internally uses the
standard containers.
This proposal has several advantages:
(1) The above mechanism enforces the read-only property of a since fn no
longer has access to the initial (writeable) definition of a.
(2) The above mechanism, if adopted as an idiom, could be easily spotted by
program analysis tools that could then make optimizations based on the fact
that a is read-only.
(3) There is hardly any performance penalty for this mechanism.
But obviously there is one big disadvantage:
(1) For each of the standard containers, a new read-only version would have
to be written. Furthermore, there would also have to be an abstract type
to serve as a common parent. E.g. there is currently no abstract parent
for Set (although there is an open discussion about that matter on github).
and a second minor disadvantage
(2) The enforcement of read-only would probably would not work recursively,
e.g., if a were an array of arrays. In fact C++ has a similar gap in its
'const' mechanism.
-- Steve Vavasis
Re: [julia-users] Gadfly, draw, and font embedding.
On Wednesday, August 13, 2014 08:59:52 PM Lee Streeter wrote: It looks like pgf is a suitable solution. Thanks for that. I might bug the Gadfly repo on this matter as well. In general, for issues specific to a particular package, that's usually the best place to do it. --Tim
Re: [julia-users] Proposal for inargs
I second that I knew a lot more people doing scientific computing with
Matlab/Python.
And of those few that use C++ only a minority knows (and cares) how to
write const aware code...
To your solution, Tim: I think Steve wants to hide this in the function so
that regular arrays can be passed. In your version a Wrapper type has to be
created before calling the function.
Cheers,
Tobi
Am Donnerstag, 14. August 2014 11:54:15 UTC+2 schrieb Tim Holy:
For any algorithm that accepts AbstractArrays, can't you just just define
immutable ReadOnlyArray{T,N,AT:AbstractArray} : AbstractArray{T,N}
data::AT
end
ReadOnlyArray{AT:AbstractArray}(A::AT) =
ReadOnlyArray{eltype(A),ndims(A),typeof(A)}(A)
and then define the pass-through methods you want to support? That way can
wrap
any array type.
Also, you could easily create your own package that does this. I don't see
any
particular requirement to have it in base.
One nit: can you really support your assertion that C++ and Fortran are
the
two major languages of scientific computing? In my world, Matlab is used
by
about 20x (maybe 50x) as many people as C++. I suspect there's a major
divide
depending on field. Science is a big place.
--Tim
On Wednesday, August 13, 2014 03:19:36 PM vav...@uwaterloo.ca
javascript: wrote:
Dear Julia colleagues,
In June, I wondered on this newsgroup why Julia lacks an 'inarg'
specification for functions. The two major languages used nowadays for
scientific programming, namely Fortran and C++, both provide mechanisms
to
declare that a function argument is read-only by the function. Indeed,
this was added to Fortran late in its life, so one assumes that there is
some bitter experience underlying the decision to include it in Fortran.
(Matlab has only inargs, at least until you get to relatively advanced
programming techniques, so this is not an issue.)
Stefan Karpinski provided a convincing explanation for why inarg and
outarg
specifications have been omitted from the Julia core. Now that I am
slightly more familiar with Julia, I would like to make a proposal for
inarg that would not require changes to the core language. The proposal
would, however, entail substantial additional code, so it is intended
for
some version of Julia in the future.
Here is the proposal: suppose fn is a function that takes an array input
a and wants to declare it to be read-only. Then at the beginning of
the
function before any of the arguments gets used, there would be an
assignment statement like this:
function fn(a::AbstractArray{Int,1})
a = readonly(a)
The way this would work is as follows: Julia would have new types,
mostly
invisible to the user, like ReadOnlyArray which would have a setindex!
method that would throw an error, Then there would be methods like
readonly{T.N}(a::Array{T,N}) that would use 'reinterpret' to change the
Array to a ReadOnlyArray. A programmer who wanted to write a function
that
could take either arrays or readonlyarrays as inputs would have to
declare
abstract argument types like DenseArray or AbstractArray. The user
would
not, in general, have to worry about the read-only types; the situation
when a user would have to worry about them is if he/she wants to develop
a
read-only version of his/her own data structure that internally uses the
standard containers.
This proposal has several advantages:
(1) The above mechanism enforces the read-only property of a since fn no
longer has access to the initial (writeable) definition of a.
(2) The above mechanism, if adopted as an idiom, could be easily spotted
by
program analysis tools that could then make optimizations based on the
fact
that a is read-only.
(3) There is hardly any performance penalty for this mechanism.
But obviously there is one big disadvantage:
(1) For each of the standard containers, a new read-only version would
have
to be written. Furthermore, there would also have to be an abstract
type
to serve as a common parent. E.g. there is currently no abstract parent
for Set (although there is an open discussion about that matter on
github).
and a second minor disadvantage
(2) The enforcement of read-only would probably would not work
recursively,
e.g., if a were an array of arrays. In fact C++ has a similar gap in
its
'const' mechanism.
-- Steve Vavasis
Re: [julia-users] Proposal for inargs
I think mine is the same as his: he suggested implementing a function fn like
this:
function fn(a::AbstractArray{Int,1})
a = readonly(a)
...
end
which does that wrapping inside the function itself. I was just pointing out
that you need only one new type to wrap any AbstractArray, not one new wrapper
per AbstractArray type.
Naturally, in that proposal a = readonly(a) destroys type stability, but the
standard Julian solution
function fn(a::ReadOnlyArray{Int,1})
# implement the real fn
end
fn(a::AbstractArray) = fn(readonly(a))
solves this, while also having the advantage of advertising the existence of a
direct read-only implementation.
--Tim
On Thursday, August 14, 2014 03:31:58 AM Tobias Knopp wrote:
I second that I knew a lot more people doing scientific computing with
Matlab/Python.
And of those few that use C++ only a minority knows (and cares) how to
write const aware code...
To your solution, Tim: I think Steve wants to hide this in the function so
that regular arrays can be passed. In your version a Wrapper type has to be
created before calling the function.
Cheers,
Tobi
Am Donnerstag, 14. August 2014 11:54:15 UTC+2 schrieb Tim Holy:
For any algorithm that accepts AbstractArrays, can't you just just define
immutable ReadOnlyArray{T,N,AT:AbstractArray} : AbstractArray{T,N}
data::AT
end
ReadOnlyArray{AT:AbstractArray}(A::AT) =
ReadOnlyArray{eltype(A),ndims(A),typeof(A)}(A)
and then define the pass-through methods you want to support? That way can
wrap
any array type.
Also, you could easily create your own package that does this. I don't see
any
particular requirement to have it in base.
One nit: can you really support your assertion that C++ and Fortran are
the
two major languages of scientific computing? In my world, Matlab is used
by
about 20x (maybe 50x) as many people as C++. I suspect there's a major
divide
depending on field. Science is a big place.
--Tim
On Wednesday, August 13, 2014 03:19:36 PM vav...@uwaterloo.ca
javascript: wrote:
Dear Julia colleagues,
In June, I wondered on this newsgroup why Julia lacks an 'inarg'
specification for functions. The two major languages used nowadays for
scientific programming, namely Fortran and C++, both provide mechanisms
to
declare that a function argument is read-only by the function. Indeed,
this was added to Fortran late in its life, so one assumes that there is
some bitter experience underlying the decision to include it in Fortran.
(Matlab has only inargs, at least until you get to relatively advanced
programming techniques, so this is not an issue.)
Stefan Karpinski provided a convincing explanation for why inarg and
outarg
specifications have been omitted from the Julia core. Now that I am
slightly more familiar with Julia, I would like to make a proposal for
inarg that would not require changes to the core language. The proposal
would, however, entail substantial additional code, so it is intended
for
some version of Julia in the future.
Here is the proposal: suppose fn is a function that takes an array input
a and wants to declare it to be read-only. Then at the beginning of
the
function before any of the arguments gets used, there would be an
assignment statement like this:
function fn(a::AbstractArray{Int,1})
a = readonly(a)
The way this would work is as follows: Julia would have new types,
mostly
invisible to the user, like ReadOnlyArray which would have a setindex!
method that would throw an error, Then there would be methods like
readonly{T.N}(a::Array{T,N}) that would use 'reinterpret' to change the
Array to a ReadOnlyArray. A programmer who wanted to write a function
that
could take either arrays or readonlyarrays as inputs would have to
declare
abstract argument types like DenseArray or AbstractArray. The user
would
not, in general, have to worry about the read-only types; the situation
when a user would have to worry about them is if he/she wants to develop
a
read-only version of his/her own data structure that internally uses the
standard containers.
This proposal has several advantages:
(1) The above mechanism enforces the read-only property of a since fn no
longer has access to the initial (writeable) definition of a.
(2) The above mechanism, if adopted as an idiom, could be easily spotted
by
program analysis tools that could then make optimizations based on the
fact
that a is read-only.
(3) There is hardly any performance penalty for this mechanism.
But obviously there is one big disadvantage:
(1) For each of the standard containers, a new read-only version would
have
to be written. Furthermore, there would also have to be an abstract
Re: [julia-users] Proposal for inargs
Ah yes, this looks like a good solution (if one cares about the read
property of arrays...)
Am Donnerstag, 14. August 2014 12:44:47 UTC+2 schrieb Tim Holy:
I think mine is the same as his: he suggested implementing a function fn
like
this:
function fn(a::AbstractArray{Int,1})
a = readonly(a)
...
end
which does that wrapping inside the function itself. I was just pointing
out
that you need only one new type to wrap any AbstractArray, not one new
wrapper
per AbstractArray type.
Naturally, in that proposal a = readonly(a) destroys type stability, but
the
standard Julian solution
function fn(a::ReadOnlyArray{Int,1})
# implement the real fn
end
fn(a::AbstractArray) = fn(readonly(a))
solves this, while also having the advantage of advertising the existence
of a
direct read-only implementation.
--Tim
On Thursday, August 14, 2014 03:31:58 AM Tobias Knopp wrote:
I second that I knew a lot more people doing scientific computing with
Matlab/Python.
And of those few that use C++ only a minority knows (and cares) how to
write const aware code...
To your solution, Tim: I think Steve wants to hide this in the function
so
that regular arrays can be passed. In your version a Wrapper type has to
be
created before calling the function.
Cheers,
Tobi
Am Donnerstag, 14. August 2014 11:54:15 UTC+2 schrieb Tim Holy:
For any algorithm that accepts AbstractArrays, can't you just just
define
immutable ReadOnlyArray{T,N,AT:AbstractArray} : AbstractArray{T,N}
data::AT
end
ReadOnlyArray{AT:AbstractArray}(A::AT) =
ReadOnlyArray{eltype(A),ndims(A),typeof(A)}(A)
and then define the pass-through methods you want to support? That way
can
wrap
any array type.
Also, you could easily create your own package that does this. I don't
see
any
particular requirement to have it in base.
One nit: can you really support your assertion that C++ and Fortran
are
the
two major languages of scientific computing? In my world, Matlab is
used
by
about 20x (maybe 50x) as many people as C++. I suspect there's a major
divide
depending on field. Science is a big place.
--Tim
On Wednesday, August 13, 2014 03:19:36 PM vav...@uwaterloo.ca
javascript: wrote:
Dear Julia colleagues,
In June, I wondered on this newsgroup why Julia lacks an 'inarg'
specification for functions. The two major languages used nowadays
for
scientific programming, namely Fortran and C++, both provide
mechanisms
to
declare that a function argument is read-only by the function.
Indeed,
this was added to Fortran late in its life, so one assumes that
there is
some bitter experience underlying the decision to include it in
Fortran.
(Matlab has only inargs, at least until you get to relatively
advanced
programming techniques, so this is not an issue.)
Stefan Karpinski provided a convincing explanation for why inarg and
outarg
specifications have been omitted from the Julia core. Now that I am
slightly more familiar with Julia, I would like to make a proposal
for
inarg that would not require changes to the core language. The
proposal
would, however, entail substantial additional code, so it is
intended
for
some version of Julia in the future.
Here is the proposal: suppose fn is a function that takes an array
input
a and wants to declare it to be read-only. Then at the beginning
of
the
function before any of the arguments gets used, there would be an
assignment statement like this:
function fn(a::AbstractArray{Int,1})
a = readonly(a)
The way this would work is as follows: Julia would have new types,
mostly
invisible to the user, like ReadOnlyArray which would have a
setindex!
method that would throw an error, Then there would be methods like
readonly{T.N}(a::Array{T,N}) that would use 'reinterpret' to change
the
Array to a ReadOnlyArray. A programmer who wanted to write a
function
that
could take either arrays or readonlyarrays as inputs would have to
declare
abstract argument types like DenseArray or AbstractArray. The user
would
not, in general, have to worry about the read-only types; the
situation
when a user would have to worry about them is if he/she wants to
develop
a
read-only version of his/her own data structure that internally uses
the
standard containers.
This proposal has several advantages:
(1) The above mechanism enforces the read-only property of a since
fn no
longer has access to the initial (writeable) definition of a.
(2) The above mechanism, if
[julia-users] Re: Proposal for inargs
At some point, I put some thinking into this.
In my ideal world this should be solved by a library, which supplies meta
informations for all known Julia functions.
With that you could recursively determine if a function actually intents to
alter some of its arguments.
Together with an IDE, you could display, which arguments might get altered
and which stay constant.
I think Stefan wrote, that this is not trivial in the context of compiler
optimization.
I'm only guessing, that it would help to have this done by an additional
library/database, which keeps track of these kind of things.
It has the advantage, that you actually verify, if something stays constant
throughout the complete call-tree, without throwing errors at runtime.
You can also find out, if arguments stay constant, even if someone
programmed it who doesn't care about these kind of optimizations.
Obvious downside: A lot of things have to happen, to make this possible.
But I'm still hoping, that at some point we will have a library, which
collects metadata about functions, like benchmarks, documentations, code
complexity, etc, etc...
Am Donnerstag, 14. August 2014 00:19:36 UTC+2 schrieb vav...@uwaterloo.ca:
Dear Julia colleagues,
In June, I wondered on this newsgroup why Julia lacks an 'inarg'
specification for functions. The two major languages used nowadays for
scientific programming, namely Fortran and C++, both provide mechanisms to
declare that a function argument is read-only by the function. Indeed,
this was added to Fortran late in its life, so one assumes that there is
some bitter experience underlying the decision to include it in Fortran.
(Matlab has only inargs, at least until you get to relatively advanced
programming techniques, so this is not an issue.)
Stefan Karpinski provided a convincing explanation for why inarg and
outarg specifications have been omitted from the Julia core. Now that I am
slightly more familiar with Julia, I would like to make a proposal for
inarg that would not require changes to the core language. The proposal
would, however, entail substantial additional code, so it is intended for
some version of Julia in the future.
Here is the proposal: suppose fn is a function that takes an array input
a and wants to declare it to be read-only. Then at the beginning of the
function before any of the arguments gets used, there would be an
assignment statement like this:
function fn(a::AbstractArray{Int,1})
a = readonly(a)
The way this would work is as follows: Julia would have new types, mostly
invisible to the user, like ReadOnlyArray which would have a setindex!
method that would throw an error, Then there would be methods like
readonly{T.N}(a::Array{T,N}) that would use 'reinterpret' to change the
Array to a ReadOnlyArray. A programmer who wanted to write a function that
could take either arrays or readonlyarrays as inputs would have to declare
abstract argument types like DenseArray or AbstractArray. The user would
not, in general, have to worry about the read-only types; the situation
when a user would have to worry about them is if he/she wants to develop a
read-only version of his/her own data structure that internally uses the
standard containers.
This proposal has several advantages:
(1) The above mechanism enforces the read-only property of a since fn no
longer has access to the initial (writeable) definition of a.
(2) The above mechanism, if adopted as an idiom, could be easily spotted
by program analysis tools that could then make optimizations based on the
fact that a is read-only.
(3) There is hardly any performance penalty for this mechanism.
But obviously there is one big disadvantage:
(1) For each of the standard containers, a new read-only version would
have to be written. Furthermore, there would also have to be an abstract
type to serve as a common parent. E.g. there is currently no abstract
parent for Set (although there is an open discussion about that matter on
github).
and a second minor disadvantage
(2) The enforcement of read-only would probably would not work
recursively, e.g., if a were an array of arrays. In fact C++ has a similar
gap in its 'const' mechanism.
-- Steve Vavasis
[julia-users] Re: Clipping Algorithm
I'd be a huge fan, of a OpenCL accelerated geometry package, which works flawlessly with OpenGL. After all, these kind of algorithms quickly get slow on big meshes, and you normally want to view them in OpenGL anyways. No one really has this open source and integrated into a bigger framework. Maybe we can start with some Julia implementations and slowly start offering them also for Arrays which reside in VRAM? Why not extending Meshes.jl? I always thought, it will host these kind of algorithms at some point... We just need to make it use parametric types, instead of having 64 bits everywhere... Am Freitag, 9. Mai 2014 23:13:06 UTC+2 schrieb Steve Kelly: I am going to be developing some software for 3D printing. For path planning, we will need to use the clipping algorithm. Graphics.jl mentions a clip function. https://github.com/JuliaLang/julia/blob/master/base/graphics.jl Cairo.jl uses the C implementation in Cairo. I would like to implement this algorithm natively in Julia. My question to the community is whether it be more appropriate to create a new package or optionally add the algorithm to Graphics.jl (or another package)? Thanks, Steve
[julia-users] Re: Running example code in packages
Anyone? The problem is that I have some resource files (i.e. *.jpg) and they live under the src/ directory of the package. Whenever I run ImageQuilting.example(), the paths to the images aren't correct. Is there any variable that stores the root directory for a package? Júlio. 2014-08-13 11:11 GMT-03:00 Júlio Hoffimann julio.hoffim...@gmail.com: Hi all, I've just adapted my code to respect Julia package management standards: https://github.com/juliohm/ImageQuilting.jl The package is working well, but I would like to give the user the possibility of running example code as explained in the README.md. What is the best way of doing it? Any other general tip you would like to share about package development? Best, Júlio.
[julia-users] Re: Running example code in packages
dirname(@__FILE__ http://docs.julialang.org/en/latest/stdlib/file/?highlight=__file__#Base.@__FILE__ ) kl. 13:55:37 UTC+2 torsdag 14. august 2014 skrev Júlio Hoffimann følgende: Anyone? The problem is that I have some resource files (i.e. *.jpg) and they live under the src/ directory of the package. Whenever I run ImageQuilting.example(), the paths to the images aren't correct. Is there any variable that stores the root directory for a package? Júlio. 2014-08-13 11:11 GMT-03:00 Júlio Hoffimann julio.h...@gmail.com javascript:: Hi all, I've just adapted my code to respect Julia package management standards: https://github.com/juliohm/ImageQuilting.jl The package is working well, but I would like to give the user the possibility of running example code as explained in the README.md. What is the best way of doing it? Any other general tip you would like to share about package development? Best, Júlio.
[julia-users] Re: Running example code in packages
I do this via Pkg.dir()*/MyPackage. If there is any better solution, I'd be quite curious to know! This looks like a cool package! =) I just implemented an OpenGL image viewer, which theoretically can tile images very easily, as OpenGL does the tiling for you. If you're interested take a look at: https://github.com/SimonDanisch/GLPlot.jl/wiki What do you plan on doing with this, if I may ask?
[julia-users] Re: Clipping Algorithm
Hello colleague, i wiser man/programmer once wrote: *Premature optimization is the root of all evil.*We started talking about the prospect to have *some* CG alorithms available in julia, so jumping to OpenCL seems fast for me. On Thursday, August 14, 2014 1:32:38 PM UTC+2, Simon Danisch wrote: I'd be a huge fan, of a OpenCL accelerated geometry package, which works flawlessly with OpenGL. After all, these kind of algorithms quickly get slow on big meshes, and you normally want to view them in OpenGL anyways. No one really has this open source and integrated into a bigger framework. Maybe we can start with some Julia implementations and slowly start offering them also for Arrays which reside in VRAM? Why not extending Meshes.jl? I always thought, it will host these kind of algorithms at some point... We just need to make it use parametric types, instead of having 64 bits everywhere... Am Freitag, 9. Mai 2014 23:13:06 UTC+2 schrieb Steve Kelly: I am going to be developing some software for 3D printing. For path planning, we will need to use the clipping algorithm. Graphics.jl mentions a clip function. https://github.com/JuliaLang/julia/blob/master/base/graphics.jl Cairo.jl uses the C implementation in Cairo. I would like to implement this algorithm natively in Julia. My question to the community is whether it be more appropriate to create a new package or optionally add the algorithm to Graphics.jl (or another package)? Thanks, Steve
Re: [julia-users] JuliaCon Opening Session Videos Posted!
The videos for the Optimization Session from JuliaCon 2014 have been posted. Enjoy! http://julialang.org/blog/2014/08/juliacon-opt-session/ -Jacob On Tue, Aug 12, 2014 at 7:01 AM, Jacob Quinn quinn.jac...@gmail.com wrote: Yes, very sorry Pontus. Luckily I used your trick for the youtube and blog post, and then must have gotten over-confident when doing this post! -Jacob On Tue, Aug 12, 2014 at 12:26 AM, Stefan Karpinski ste...@karpinski.org wrote: Sorry, Pontus – I spelled your name wrong in an entirely different (and far less American) manner. Although star dwelling vs stone dwelling is maybe ok ;-) On Tue, Aug 12, 2014 at 12:11 AM, Pontus Stenetorp pon...@stenetorp.se wrote: To Jacob and the team, thank you for all your hard work. These videos will surely help spread the word about Julia. On 11 August 2014 20:53, Jacob Quinn karbar...@gmail.com wrote: Gather round and here the tales of a wonderous new language, presented by Tim Holy, Pontus Stenetrop, and Arch Robison. Just to nip this one in the bud, it is Stenetorp, not Stenetrop or Sterntorp [1] (I like the last one, it has a woody quality to it). No harm done, I am used to it and do find it amusing to see possible permutations of my name. =) I have a bit of a trick that I use to avoid getting names wrong. If the name is not common enough not to be in the spelling dictionary, I copy paste the blasted thing, this is something that I have learned over the years after messing up the first line of far too many e-mails... Pontus [1]: https://news.ycombinator.com/item?id=8163607
Re: [julia-users] Create matrix from a comprehension with row/col-returning function?
hcat and vcat will do the trick. Thanks! -Brendan
Re: [julia-users] JuliaCon Opening Session Videos Posted!
Thanks for all the hard work on these! The videos so far have come out awesome and the presenters are really easy to understand. Good capture at the event, good post work, and good projection by the presenters. The JuliaCon organizers put a HUGE amount of work into making a great conference, so I'm really happy that it's captured for a wider audience. Thanks all involved! peace, s On Thu, Aug 14, 2014 at 8:16 AM, Jacob Quinn quinn.jac...@gmail.com wrote: The videos for the Optimization Session from JuliaCon 2014 have been posted. Enjoy! http://julialang.org/blog/2014/08/juliacon-opt-session/ -Jacob On Tue, Aug 12, 2014 at 7:01 AM, Jacob Quinn quinn.jac...@gmail.com wrote: Yes, very sorry Pontus. Luckily I used your trick for the youtube and blog post, and then must have gotten over-confident when doing this post! -Jacob On Tue, Aug 12, 2014 at 12:26 AM, Stefan Karpinski ste...@karpinski.org wrote: Sorry, Pontus – I spelled your name wrong in an entirely different (and far less American) manner. Although star dwelling vs stone dwelling is maybe ok ;-) On Tue, Aug 12, 2014 at 12:11 AM, Pontus Stenetorp pon...@stenetorp.se wrote: To Jacob and the team, thank you for all your hard work. These videos will surely help spread the word about Julia. On 11 August 2014 20:53, Jacob Quinn karbar...@gmail.com wrote: Gather round and here the tales of a wonderous new language, presented by Tim Holy, Pontus Stenetrop, and Arch Robison. Just to nip this one in the bud, it is Stenetorp, not Stenetrop or Sterntorp [1] (I like the last one, it has a woody quality to it). No harm done, I am used to it and do find it amusing to see possible permutations of my name. =) I have a bit of a trick that I use to avoid getting names wrong. If the name is not common enough not to be in the spelling dictionary, I copy paste the blasted thing, this is something that I have learned over the years after messing up the first line of far too many e-mails... Pontus [1]: https://news.ycombinator.com/item?id=8163607
[julia-users] Re: Clipping Algorithm
Please excuse me for my OpenCL lobbying, but I pretty much came to Julia, to have these kind of algorithms as fast as possible :) These considerations won't necessarily slow down the development of any Julia algorithm, as the implementation is rather orthogonal - which is why I don't see any harm in getting OpenCL into the discussion. I just mentioned, what I will be doing, in the hope, that people who develop any geometric algorithm in Julia keep it in mind, while designing the library. For example, the library should only use parametric types, which would enable me to use Float32. It's a small thing if you do it from the beginning, but gives you quite a headache if you try to integrate it later on. This way it becomes a lot simpler, to smuggle in some OpenCL implementations( e.g. via multiple dispatch) parallel to the already established algorithms written in Julia. I'm not talking theoretically about this, but I mention this because this is the reason why I can't use two very nice packages (namely Color.jl and Meshes.jl), without a lot of unnecessary conversions. I'm very well aware, that not everyone wants to put the extra effort into developing in OpenCL. That's why I wrote: lets start with julia and add OpenCL later Am Freitag, 9. Mai 2014 23:13:06 UTC+2 schrieb Steve Kelly: I am going to be developing some software for 3D printing. For path planning, we will need to use the clipping algorithm. Graphics.jl mentions a clip function. https://github.com/JuliaLang/julia/blob/master/base/graphics.jl Cairo.jl uses the C implementation in Cairo. I would like to implement this algorithm natively in Julia. My question to the community is whether it be more appropriate to create a new package or optionally add the algorithm to Graphics.jl (or another package)? Thanks, Steve
[julia-users] Re: Running example code in packages
Thanks Ivar, that looks nicer! Seems like I've been overlooking this for quite some time Am Mittwoch, 13. August 2014 16:11:43 UTC+2 schrieb Júlio Hoffimann: Hi all, I've just adapted my code to respect Julia package management standards: https://github.com/juliohm/ImageQuilting.jl The package is working well, but I would like to give the user the possibility of running example code as explained in the README.md. What is the best way of doing it? Any other general tip you would like to share about package development? Best, Júlio.
Re: [julia-users] pkg.julialang.org updated for 0.3/0.4, new permalinks/badges
Because julia 0.2 is shipped with some Linux distros that are expected to be supported for several more years, there may be some people running 0.2 for some time. To make sure that future developments don't break 0.2 support (and without PkgEvaluator how will I know? :) ), I took the time to freeze all of my packages on 0.2. I encourage others to consider doing the same. Here's the rough procedure I used: - edit the REQUIRE file to include julia 0.2 0.3 - commit - tag - edit the REQUIRE file to include julia 0.3- - commit - tag with a minor version bump Obviously it might be nice to have an automated way of doing this, but it wasn't too bad. --Tim On Wednesday, August 13, 2014 05:06:16 PM Iain Dunning wrote: Hi all, Just wanted to announce I've changed pkg.julialang.org to show 0.3 and 0.4 packages. I've also taken this opportunity to change the badge and permalink URLs to something more, well, permanent. The old ones had specific Julia versions in which I feel like is a pain to maintain, so I've changed them to this format: I've kept the old SVGs there for now, but I will be removing them in a month or so. So you'll need to update this one time, but after that you should be OK forever. Release/stable: PERMALINK: http://pkg.julialang.org/?pkg=AffineTransformsver=release BADGE SVG: http://pkg.julialang.org/badges/AffineTransforms_release.svg MARKDOWN: [](http://pkg.julialang.org/?pkg=AffineTransformsver=release) Nightly/unstable: PERMALINK: http://pkg.julialang.org/?pkg=AffineTransformsver=nightly BADGE SVG: http://pkg.julialang.org/badges/AffineTransforms_nightly.svg MARKDOWN: [](http://pkg.julialang.org/?pkg=AffineTransformsver=nightly)
Re: [julia-users] Re: Clipping Algorithm
On Thursday, August 14, 2014 06:38:29 AM Simon Danisch wrote: I'm not talking theoretically about this, but I mention this because this is the reason why I can't use two very nice packages (namely Color.jl and Meshes.jl), without a lot of unnecessary conversions. The latest version of Color has fixed this. --Tim
[julia-users] Fully Typed Function As Argument Type
I'm new to the language so I may have missed something. But is there a way to make sure a function passed as an argument is of a specific type including it's arguments? It doesn't look like from the design of the language this could be supported but I'm curious. For example I would like to be able to do: function callme(handler::Function(Int32, Float64)) handler(12, 0.2) end And the compiler would guarantee the correct type of function is called. Thanks,
Re: [julia-users] Fully Typed Function As Argument Type
Not possible in the current versions of Julia. Maybe one day. There are bunch of us who’d like to have this functionality, but it’s a non-trivial addition of complexity to the compiler. — John On Aug 14, 2014, at 4:59 AM, Chris Kellendonk chriskellend...@gmail.com wrote: I'm new to the language so I may have missed something. But is there a way to make sure a function passed as an argument is of a specific type including it's arguments? It doesn't look like from the design of the language this could be supported but I'm curious. For example I would like to be able to do: function callme(handler::Function(Int32, Float64)) handler(12, 0.2) end And the compiler would guarantee the correct type of function is called. Thanks,
[julia-users] pdf of a multivariate distribution
Hi all,
I am getting an error when I try to obtain the probability density
evaluated at z1[1,;]:
julia pdf(MvNormal(zhat11,F11),z1[1,:])
MethodError(logpdf,(GenericMvNormal{PDMat} distribution
Dim: 27
Zeromean: false
μ:
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
Σ: PDMat(27,27x27 Array{Float64,2}:
1.46955 1.08653 0.872691 0.73362 … 0.0 0.0 0.0
1.08653 1.58080.948201 0.797096 0.0 0.0 0.0
0.872691 0.948201 1.38173 0.640224 0.0 0.0 0.0
0.73362 0.797096 0.640224 0.94777 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 … 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
⋮ ⋱⋮
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 … 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.408578 0.564983 0.610912
0.0 0.0 0.0 0.0 0.335025 0.463274 0.500935
0.0 0.0 0.0 0.0 1.41921 0.723169 0.781958
0.0 0.0 0.0 0.0 … 0.723169 1.79472 1.08129
0.0 0.0 0.0 0.0 0.781958 1.08129 1.95214
,Cholesky{Float64}(27x27 Array{Float64,2}:
1.21225 0.896288 0.719894 0.605172 … 0.0 0.0 0.0
1.08653 0.881739 0.343604 0.288847 0.0 0.0 0.0
0.872691 0.948201 0.863378 0.12198 0.0 0.0 0.0
0.73362 0.797096 0.640224 0.695144 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 … 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
⋮ ⋱⋮
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 … 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.449492 0.621558 0.672087
0.0 0.0 0.0 0.0 0.313935 0.43411 0.469401
0.0 0.0 0.0 0.0 1.05765 0.290741 0.314376
0.0 0.0 0.0 0.0 … 0.723169 1.06555 0.345716
0.0 0.0 0.0 0.0 0.781958 1.08129 1.03041 ,'U'))
,{-0.18446029}))
The MvNormal part works perfect alone:
julia MvNormal(zhat11,F11)
GenericMvNormal{PDMat} distribution
Dim: 27
Zeromean: false
μ:
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
Σ: PDMat(27,27x27 Array{Float64,2}:
1.46955 1.08653 0.872691 0.73362 … 0.0 0.0 0.0
1.08653 1.58080.948201 0.797096 0.0 0.0 0.0
0.872691 0.948201 1.38173 0.640224 0.0 0.0 0.0
0.73362 0.797096 0.640224 0.94777 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 … 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
⋮ ⋱⋮
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 … 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0
Re: [julia-users] pdf of a multivariate distribution
In Julia, anything with a description like 1x27 Array{Any,2} is a matrix, not a
vector.
Also, it's not the right kind of vector because it has no numeric type
restriction. It needs to be a vector of Float64 values, like you'd get from
doing something like:
[1.0, 2.0, 3.0]
-- John
On Aug 14, 2014, at 8:56 AM, pamjer...@gmail.com wrote:
Hi all,
I am getting an error when I try to obtain the probability density evaluated
at z1[1,;]:
julia pdf(MvNormal(zhat11,F11),z1[1,:])
MethodError(logpdf,(GenericMvNormal{PDMat} distribution
Dim: 27
Zeromean: false
μ:
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
Σ: PDMat(27,27x27 Array{Float64,2}:
1.46955 1.08653 0.872691 0.73362 … 0.0 0.0 0.0
1.08653 1.58080.948201 0.797096 0.0 0.0 0.0
0.872691 0.948201 1.38173 0.640224 0.0 0.0 0.0
0.73362 0.797096 0.640224 0.94777 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 … 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
⋮ ⋱⋮
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 … 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.408578 0.564983 0.610912
0.0 0.0 0.0 0.0 0.335025 0.463274 0.500935
0.0 0.0 0.0 0.0 1.41921 0.723169 0.781958
0.0 0.0 0.0 0.0 … 0.723169 1.79472 1.08129
0.0 0.0 0.0 0.0 0.781958 1.08129 1.95214
,Cholesky{Float64}(27x27 Array{Float64,2}:
1.21225 0.896288 0.719894 0.605172 … 0.0 0.0 0.0
1.08653 0.881739 0.343604 0.288847 0.0 0.0 0.0
0.872691 0.948201 0.863378 0.12198 0.0 0.0 0.0
0.73362 0.797096 0.640224 0.695144 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 … 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
⋮ ⋱⋮
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 … 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.449492 0.621558 0.672087
0.0 0.0 0.0 0.0 0.313935 0.43411 0.469401
0.0 0.0 0.0 0.0 1.05765 0.290741 0.314376
0.0 0.0 0.0 0.0 … 0.723169 1.06555 0.345716
0.0 0.0 0.0 0.0 0.781958 1.08129 1.03041 ,'U'))
,{-0.18446029}))
The MvNormal part works perfect alone:
julia MvNormal(zhat11,F11)
GenericMvNormal{PDMat} distribution
Dim: 27
Zeromean: false
μ:
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
Σ: PDMat(27,27x27 Array{Float64,2}:
1.46955 1.08653 0.872691 0.73362 … 0.0 0.0 0.0
1.08653 1.58080.948201 0.797096 0.0 0.0 0.0
0.872691 0.948201 1.38173 0.640224 0.0 0.0 0.0
0.73362 0.797096 0.640224 0.94777 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 … 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
⋮ ⋱⋮
0.0 0.0 0.0 0.0
Re: [julia-users] Re: Clipping Algorithm
I implemented the Greiner-Hormann algorithm for clipping and Hormann-Agathos algorithm for point-in-polygon here: https://github.com/sjkelly/PolygonClipping.jl I made a specialized implementation for generating infill for 3D printing paths. I am currently working on merging this package with Geometry2D.jl. It can also be about 2x faster in the general case and handle more than two polys, but I need some things in Geometry2D.jl to make that possible. On Thu, Aug 14, 2014 at 10:12 AM, Tim Holy tim.h...@gmail.com wrote: On Thursday, August 14, 2014 06:38:29 AM Simon Danisch wrote: I'm not talking theoretically about this, but I mention this because this is the reason why I can't use two very nice packages (namely Color.jl and Meshes.jl), without a lot of unnecessary conversions. The latest version of Color has fixed this. --Tim
Re: [julia-users] Re: Clipping Algorithm
I'm not talking theoretically about this, but I mention this because this is the reason why I can't use two very nice packages (namely Color.jl and Meshes.jl), without a lot of unnecessary conversions. I've been hacking on Meshes.jl the past few days. I will file an issue for this and try to fix it ASAP. On Thu, Aug 14, 2014 at 9:38 AM, Simon Danisch sdani...@gmail.com wrote: Please excuse me for my OpenCL lobbying, but I pretty much came to Julia, to have these kind of algorithms as fast as possible :) These considerations won't necessarily slow down the development of any Julia algorithm, as the implementation is rather orthogonal - which is why I don't see any harm in getting OpenCL into the discussion. I just mentioned, what I will be doing, in the hope, that people who develop any geometric algorithm in Julia keep it in mind, while designing the library. For example, the library should only use parametric types, which would enable me to use Float32. It's a small thing if you do it from the beginning, but gives you quite a headache if you try to integrate it later on. This way it becomes a lot simpler, to smuggle in some OpenCL implementations( e.g. via multiple dispatch) parallel to the already established algorithms written in Julia. I'm not talking theoretically about this, but I mention this because this is the reason why I can't use two very nice packages (namely Color.jl and Meshes.jl), without a lot of unnecessary conversions. I'm very well aware, that not everyone wants to put the extra effort into developing in OpenCL. That's why I wrote: lets start with julia and add OpenCL later Am Freitag, 9. Mai 2014 23:13:06 UTC+2 schrieb Steve Kelly: I am going to be developing some software for 3D printing. For path planning, we will need to use the clipping algorithm. Graphics.jl mentions a clip function. https://github.com/JuliaLang/ julia/blob/master/base/graphics.jl Cairo.jl uses the C implementation in Cairo. I would like to implement this algorithm natively in Julia. My question to the community is whether it be more appropriate to create a new package or optionally add the algorithm to Graphics.jl (or another package)? Thanks, Steve
[julia-users] Re: Clipping Algorithm
Awesom work, thanks Tim! I actually just hacked into Meshes.jl as well, trying to use your obj importer. There are some more things missing, to make them work nicely with OpenGL. But this now becomes completely off-topic. I'll file an issue! Am Freitag, 9. Mai 2014 23:13:06 UTC+2 schrieb Steve Kelly: I am going to be developing some software for 3D printing. For path planning, we will need to use the clipping algorithm. Graphics.jl mentions a clip function. https://github.com/JuliaLang/julia/blob/master/base/graphics.jl Cairo.jl uses the C implementation in Cairo. I would like to implement this algorithm natively in Julia. My question to the community is whether it be more appropriate to create a new package or optionally add the algorithm to Graphics.jl (or another package)? Thanks, Steve
Re: [julia-users] pdf of a multivariate distribution
Thanks a lot John for your answer! I'm starting in Julia so I'm still in
the learning curve...
Do you know how I can convert Array{Float64, 2} to Array{Float64, 1}?
Thanks again!
Pam.
On Thursday, August 14, 2014 5:15:01 PM UTC+1, John Myles White wrote:
In Julia, anything with a description like 1x27 Array{Any,2} is a matrix,
not a vector.
Also, it's not the right kind of vector because it has no numeric type
restriction. It needs to be a vector of Float64 values, like you'd get from
doing something like:
[1.0, 2.0, 3.0]
-- John
On Aug 14, 2014, at 8:56 AM, pamj...@gmail.com javascript: wrote:
Hi all,
I am getting an error when I try to obtain the probability density
evaluated at z1[1,;]:
julia pdf(MvNormal(zhat11,F11),z1[1,:])
MethodError(logpdf,(GenericMvNormal{PDMat} distribution
Dim: 27
Zeromean: false
μ:
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
Σ: PDMat(27,27x27 Array{Float64,2}:
1.46955 1.08653 0.872691 0.73362 … 0.0 0.0 0.0
1.08653 1.58080.948201 0.797096 0.0 0.0 0.0
0.872691 0.948201 1.38173 0.640224 0.0 0.0 0.0
0.73362 0.797096 0.640224 0.94777 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 … 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
⋮ ⋱⋮
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 … 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.408578 0.564983 0.610912
0.0 0.0 0.0 0.0 0.335025 0.463274 0.500935
0.0 0.0 0.0 0.0 1.41921 0.723169 0.781958
0.0 0.0 0.0 0.0 … 0.723169 1.79472 1.08129
0.0 0.0 0.0 0.0 0.781958 1.08129 1.95214
,Cholesky{Float64}(27x27 Array{Float64,2}:
1.21225 0.896288 0.719894 0.605172 … 0.0 0.0 0.0
1.08653 0.881739 0.343604 0.288847 0.0 0.0 0.0
0.872691 0.948201 0.863378 0.12198 0.0 0.0 0.0
0.73362 0.797096 0.640224 0.695144 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 … 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
⋮ ⋱⋮
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 … 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.449492 0.621558 0.672087
0.0 0.0 0.0 0.0 0.313935 0.43411 0.469401
0.0 0.0 0.0 0.0 1.05765 0.290741 0.314376
0.0 0.0 0.0 0.0 … 0.723169 1.06555 0.345716
0.0 0.0 0.0 0.0 0.781958 1.08129 1.03041 ,'U'))
,{-0.18446029}))
The MvNormal part works perfect alone:
julia MvNormal(zhat11,F11)
GenericMvNormal{PDMat} distribution
Dim: 27
Zeromean: false
μ:
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
Σ: PDMat(27,27x27 Array{Float64,2}:
1.46955 1.08653 0.872691 0.73362 … 0.0 0.0 0.0
1.08653 1.58080.948201 0.797096 0.0 0.0 0.0
0.872691 0.948201 1.38173 0.640224 0.0 0.0 0.0
0.73362 0.797096 0.640224 0.94777 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 … 0.0 0.0 0.0
0.0 0.0 0.0
Re: [julia-users] pdf of a multivariate distribution
The vec() function would work.
But it might be worth reviewing your code again. You should be storing your
data such that you have a matrix of N samples (each of dimensionality D) stored
as a DxN matrix. Call this matrix X. Then you access samples as X[:, j]. If you
do this, your data structures will match the signatures of the methdos in
Distributions.jl.
-- John
On Aug 14, 2014, at 9:38 AM, pamjer...@gmail.com wrote:
Thanks a lot John for your answer! I'm starting in Julia so I'm still in the
learning curve...
Do you know how I can convert Array{Float64, 2} to Array{Float64, 1}?
Thanks again!
Pam.
On Thursday, August 14, 2014 5:15:01 PM UTC+1, John Myles White wrote:
In Julia, anything with a description like 1x27 Array{Any,2} is a matrix, not
a vector.
Also, it's not the right kind of vector because it has no numeric type
restriction. It needs to be a vector of Float64 values, like you'd get from
doing something like:
[1.0, 2.0, 3.0]
-- John
On Aug 14, 2014, at 8:56 AM, pamj...@gmail.com wrote:
Hi all,
I am getting an error when I try to obtain the probability density evaluated
at z1[1,;]:
julia pdf(MvNormal(zhat11,F11),z1[1,:])
MethodError(logpdf,(GenericMvNormal{PDMat} distribution
Dim: 27
Zeromean: false
μ:
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
Σ: PDMat(27,27x27 Array{Float64,2}:
1.46955 1.08653 0.872691 0.73362 … 0.0 0.0 0.0
1.08653 1.58080.948201 0.797096 0.0 0.0 0.0
0.872691 0.948201 1.38173 0.640224 0.0 0.0 0.0
0.73362 0.797096 0.640224 0.94777 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 … 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
⋮ ⋱⋮
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 … 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.408578 0.564983 0.610912
0.0 0.0 0.0 0.0 0.335025 0.463274 0.500935
0.0 0.0 0.0 0.0 1.41921 0.723169 0.781958
0.0 0.0 0.0 0.0 … 0.723169 1.79472 1.08129
0.0 0.0 0.0 0.0 0.781958 1.08129 1.95214
,Cholesky{Float64}(27x27 Array{Float64,2}:
1.21225 0.896288 0.719894 0.605172 … 0.0 0.0 0.0
1.08653 0.881739 0.343604 0.288847 0.0 0.0 0.0
0.872691 0.948201 0.863378 0.12198 0.0 0.0 0.0
0.73362 0.797096 0.640224 0.695144 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 … 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
⋮ ⋱⋮
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 … 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.449492 0.621558 0.672087
0.0 0.0 0.0 0.0 0.313935 0.43411 0.469401
0.0 0.0 0.0 0.0 1.05765 0.290741 0.314376
0.0 0.0 0.0 0.0 … 0.723169 1.06555 0.345716
0.0 0.0 0.0 0.0 0.781958 1.08129 1.03041
,'U'))
,{-0.18446029}))
The MvNormal part works perfect alone:
julia MvNormal(zhat11,F11)
GenericMvNormal{PDMat} distribution
Dim: 27
Zeromean: false
μ:
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
Σ: PDMat(27,27x27 Array{Float64,2}:
1.46955 1.08653 0.872691 0.73362 … 0.0 0.0 0.0
1.08653 1.58080.948201 0.797096 0.0 0.0 0.0
[julia-users] table of UTF8 operator symbols
It may be due to a because it's there syndrome but I feel that code is easier to understand when I use ≠ instead of !=. Now I am trying to remember the UTF8 symbols and TeX-like names for == and ===. I know there is a table of these somewhere but perfunctory searches of docs.julialang.org/en/latest haven't revealed it to me. Could someone provide a pointer for me?
[julia-users] Re: table of UTF8 operator symbols
On Thursday, August 14, 2014 12:58:40 PM UTC-4, Douglas Bates wrote: It may be due to a because it's there syndrome but I feel that code is easier to understand when I use ≠ instead of !=. Now I am trying to remember the UTF8 symbols and TeX-like names for == and ===. I don't think there is a Unicode symbol in Julia for ==. For === it is ≡ (\equiv). I know there is a table of these somewhere but perfunctory searches of docs.julialang.org/en/latest haven't revealed it to me. Could someone provide a pointer for me? There is a table of Unicode synonyms in the NEWS file (https://github.com/JuliaLang/julia/blob/master/NEWS.md). The only table of the supported LaTeX shortcuts that I know of is in the source code: https://github.com/JuliaLang/julia/blob/master/base/latex_symbols.jl It's not in the manual yet, but see https://github.com/JuliaLang/julia/pull/7918
[julia-users] unsure about an error message from ccall
I'm getting an error from ccall when the first argument is a tuple of a
symbol and a string.
julia libwsmp
/home/bates/.julia/v0.4/WSMP/deps/usr/lib/libwsmp
julia
ccall((:wkktord_,libwsmp),Void,(Ptr{Cint},Ptr{Cint},Ptr{Cint},Ptr{Cint},Ptr{Cint},
Ptr{Cint},Ptr{Cint},Ptr{Cint},Ptr{Cint}),
n,adj.colptr,adj.rowval,options,1,perm,invp,C_NULL,0)
ERROR: type: anonymous: in ccall: first argument not a pointer or valid
constant expression, expected DataType, got Type{(Any...,)}
in anonymous at no file
but the same call with a dlsym works
julia hh = dlopen_e(libwsmp)
Ptr{Void} @0x06541b50
julia
ccall(dlsym(hh,wkktord_),Void,(Ptr{Cint},Ptr{Cint},Ptr{Cint},Ptr{Cint},Ptr{Cint},
Ptr{Cint},Ptr{Cint},Ptr{Cint},Ptr{Cint}),
n,adj.colptr,adj.rowval,options,1,perm,invp,C_NULL,0)
I use the ccall((Symbol,String),... idiom in several other places in the
same Module and can't see what I am doing differently here to cause an
error. Can someone give me a hint?
julia versioninfo()
Julia Version 0.4.0-dev+124
Commit eb5b91c (2014-08-14 13:15 UTC)
Platform Info:
System: Linux (x86_64-pc-linux-gnu)
CPU: AMD Athlon(tm) II X4 635 Processor
WORD_SIZE: 64
BLAS: libopenblas (NO_AFFINITY BARCELONA)
LAPACK: libopenblas
LIBM: libopenlibm
LLVM: libLLVM-3.3
[julia-users] unsure about an error message from ccall
Does it help to declare libwsmp as const?
[julia-users] We have typed functions, don't we?
Hi Julia users,
As this is my first post, I must say I'm extremely impressed by julia, met
2 weeks ago. For many months I've meant to clean-up a C++/python lib of
mine, for public consumption. I couldn't help but procrastinate, as the
maintenance cost is so high a tax (eg. too clever hacks, big compilation
times (mainly due to having to instantiate non-lazily an explosion of
templates to make them accessible from within python), the last version of
gcc not accepting my code anymore, for probably valid reasons, I guess,
etc.). So big thanks to all julia developers for destroying my problem and
freeing me from C++. I gave in after checking by myself the hard-to-believe
efficiency promise (speed within 120% of C) on the non-toy DES crypto
algorithm. I'm very grateful for this awesome beautiful, fast, fun,
language, that I didn't dare to dream of.
The problem of higher-order-functions inlining (via callable types, aka
functors) is getting a lot of attention, but I will need fast solutions
soon and don't want to give up the right to use cost-free abstractions
(offered by C++). So should we hold our breath on built-in functors, are is
it still worth investigating library solutions?
I found NumericFunctors/NumericFuns (and base/reduce.jl) based on `abstract
Functor{N}`, are there others built on `Functor{Result, Arg1, ..., ArgN}`?
I wanted to share a tiny trick that occurred to me today, which doesn't
seem to be widely known, unleashing stateless functors (type constructors
have a dual nature). Please let me know if it relies on undefined
behavior.
abstract Functor{N}
typealias UnaryFunctor Functor{1}
typealias BinaryFunctor Functor{2}
type double : UnaryFunctor end
double(x) = 2*x
type plus : BinaryFunctor end
plus(x, y) = x+y
plus(x::String, y::String) = x*y # ;-)
type compose{Out:Functor, In:Functor} : Functor
compose(x...) = Out(In(x...))
# compose(x...) = Out(In(x...)...) # more general but awfully slow
end
doubleplus = compose{double, plus}
# constrained function:
f{F:BinaryFunctor}(fun::Type{F}, x) = fun(x, x)
f(plus, 1)
# etc.
This can't serve as a drop-in replacement for normal functions, as many API
hardcode `Function` in their type signatures.
I only barely tested the performances. In the benchmark code at [1],
statement (1) is 10 times slower than statement (2) on my machine, but if
`plus` gets replaced by the definition above, it's only about 20% slower.
And then becomes unsurprisigly faster for `doubleplus`. However, for e.g.
`reduce(plus, 0, 1:n)` I observed no gain (compared to plus(x,y)=x+y, as
reduce(+,...) is special-cased and optimized), any ideas why?
Note that the native_code of `doubleplus` seems to be more optimized with
this finer grained definition of compose (which improves only slightly the
benchmark):
type compose{Out:Functor, In:Functor} : Functor
if In : UnaryFunctor
compose(x) = Out(In(x))
elseif In : BinaryFunctor
compose(x, y) = Out(In(x, y))
else
compose(x...) = Out(In(x...))
end
end
On a related note, my last question: is there a variation of the following
definition that would compile?
arity{N, F:Functor{N}}(::Type{F}) = N
Thanks,
Rafael
[1] https://github.com/timholy/NumericFunctors.jl, benchmark code below:
plus(x, y) = x + y
map_plus(x, y) = map(plus, x, y)
a = rand(1000, 1000)
b = rand(1000, 1000)
# warming up and get map_plus compiled
a + b
map_plus(a, b)
# benchmark
@time for i in 1 : 10 map_plus(a, b) end # -- statement (1)
@time for i in 1 : 10 a + b end # -- statement (2)
[julia-users] Re: unsure about an error message from ccall
On Thursday, August 14, 2014 2:06:06 PM UTC-5, Ivar Nesje wrote: Does it help to declare libwsmp as const? Now the problem seems to have cured itself. I'm not sure what I am doing differently.
[julia-users] Stabilizer LLVM Plugin
I just heard a talk about this (somewhat out-of-date) LLVM plugin for doing performance testing in a way that randomizes over possible memory layouts: https://github.com/ccurtsinger/stabilizer If the plugin gets updated for a newer version of LLVM it might be a fun project to try using this for testing the performance of Julia code. -- John
Re: [julia-users] Typo in local variable name not detected
Hi all. I have been busy and not following the julia development news. are there any news wrt this topic? What I find dangerous is mistakenly referencing a global variable from a local context, when that is not intended. To me it seems worth adding a qualifier to specify that whatever is not declared as 'global', should only be local (or an error should be thrown). This could also be a julia flag. Do these ideas seem reasonable? Cheers. El sábado, 8 de marzo de 2014 03:40:37 UTC+1, Stefan Karpinski escribió: How about check_locals? You can check for both unused and potentially unassigned locals. On Mar 7, 2014, at 5:39 PM, Leah Hanson astri...@gmail.com javascript: wrote: Adding that to TypeCheck sounds pretty reasonable. Functions already provide their local variable names, so it would be a matter of finding all variable usages (excluding LHS assignments). I can probably find time in the next week or so to add it. Maybe check_for_unused_local_variables? (which seems long, but descriptive) -- Leah On Fri, Mar 7, 2014 at 4:02 PM, Jiahao Chen jia...@mit.edu javascript: wrote: On Fri, Mar 7, 2014 at 4:22 PM, Stefan Karpinski ste...@karpinski.org javascript: wrote: I would prefer to have opt-in (but easy to use) code analysis that can tell you that anwser is an unused variable (or in slight variations of this code, that answer or anwser is always or sometimes not assigned). That sounds like -Wimplicit in fortran compilers, which forces IMPLICIT NONE.
[julia-users] Re: ANN: Docile.jl Package Documentation (again)
I’ve added some new functionality in the form of @doc docstrings for:
- methods
- functions
- globals
- macros
- types
- modules
The YAML metadata has been replaced with a Dict{Symbol, Any}, resulting in
quite a large improvement in load times.
Documentation can also be included from external files if a docstring
becomes too large. String interpolation into docstrings
is supported, as well as a string macro (tex_mstr) for writing LaTeX
equations without needing to use escape characters.
I’m in the process of getting Docile included in METADATA so hopefully
it’ll be ready for general use quite soon.
— Mike
[julia-users] Re: ANN: Docile.jl Package Documentation (again)
I'll try to give this ago, its a nice idea. I've don't believe I've ever
worked on a project that actually used docstrings in a formalized way
(to, i.e. generate HTML documentation), but I can see how it'd be very
useful for some Julia packages.
Cheers,
Iain
On Thursday, August 14, 2014 5:01:31 PM UTC-4, Michael Hatherly wrote:
I’ve added some new functionality in the form of @doc docstrings for:
- methods
- functions
- globals
- macros
- types
- modules
The YAML metadata has been replaced with a Dict{Symbol, Any}, resulting
in quite a large improvement in load times.
Documentation can also be included from external files if a docstring
becomes too large. String interpolation into docstrings
is supported, as well as a string macro (tex_mstr) for writing LaTeX
equations without needing to use escape characters.
I’m in the process of getting Docile included in METADATA so hopefully
it’ll be ready for general use quite soon.
— Mike
Re: [julia-users] JuliaCon Opening Session Videos Posted!
can we look forward to June 2015 for the second ever great JuliaCon ... ? if so, where shall we plan on going to? ~ cdm
Re: [julia-users] Proposal for inargs
One nit: can you really support your assertion that C++ and Fortran are the two major languages of scientific computing? In my world, Matlab is used by about 20x (maybe 50x) as many people as C++. I suspect there's a major divide depending on field. Science is a big place. It's just as you said: it depends heavily on the field. In my experience, fields requiring heavy calculations (like CFD or ab initio computational chemistry) tend to use C++ and Fortran (actually mostly Fortran if the project was not started less than 10 years ago). Unfortunately, I can't find a ready-to-read list for CFD but for CC, it was easier: http://en.m.wikipedia.org/wiki/List_of_quantum_chemistry_and_solid-state_physics_software The explanation is simple: with BLAS and Fortran and 100-1000 CPU cores, some calculations already require weeks to complete.
Re: [julia-users] Typo in local variable name not detected
It's funny, this issue is by far my biggest source of bugs when coding in Julia. I find myself often prototyping things with commands in the global REPL scope, then wrapping everything into a function once I get it working. Then I forget to pass a variable as an argument to the function and the function accidentally reaches out to the global scope from within the function. It would be nice if there was an easy macro which could warn me (something basic like @time but which says btw: your reaching into global scope for some non-function variables). Unfortunately I don't really know how to write such a macro. Cheers, Ethan On Thursday, August 14, 2014 2:01:08 PM UTC-7, Carlos Becker wrote: Hi all. I have been busy and not following the julia development news. are there any news wrt this topic? What I find dangerous is mistakenly referencing a global variable from a local context, when that is not intended. To me it seems worth adding a qualifier to specify that whatever is not declared as 'global', should only be local (or an error should be thrown). This could also be a julia flag. Do these ideas seem reasonable? Cheers. El sábado, 8 de marzo de 2014 03:40:37 UTC+1, Stefan Karpinski escribió: How about check_locals? You can check for both unused and potentially unassigned locals. On Mar 7, 2014, at 5:39 PM, Leah Hanson astri...@gmail.com wrote: Adding that to TypeCheck sounds pretty reasonable. Functions already provide their local variable names, so it would be a matter of finding all variable usages (excluding LHS assignments). I can probably find time in the next week or so to add it. Maybe check_for_unused_local_variables? (which seems long, but descriptive) -- Leah On Fri, Mar 7, 2014 at 4:02 PM, Jiahao Chen jia...@mit.edu wrote: On Fri, Mar 7, 2014 at 4:22 PM, Stefan Karpinski ste...@karpinski.org wrote: I would prefer to have opt-in (but easy to use) code analysis that can tell you that anwser is an unused variable (or in slight variations of this code, that answer or anwser is always or sometimes not assigned). That sounds like -Wimplicit in fortran compilers, which forces IMPLICIT NONE.
Re: [julia-users] Typo in local variable name not detected
I think Lint.jl might handle this already: https://github.com/tonyhffong/Lint.jl -- John On Aug 14, 2014, at 2:39 PM, Ethan Anderes ethanande...@gmail.com wrote: It's funny, this issue is by far my biggest source of bugs when coding in Julia. I find myself often prototyping things with commands in the global REPL scope, then wrapping everything into a function once I get it working. Then I forget to pass a variable as an argument to the function and the function accidentally reaches out to the global scope from within the function. It would be nice if there was an easy macro which could warn me (something basic like @time but which says btw: your reaching into global scope for some non-function variables). Unfortunately I don't really know how to write such a macro. Cheers, Ethan On Thursday, August 14, 2014 2:01:08 PM UTC-7, Carlos Becker wrote: Hi all. I have been busy and not following the julia development news. are there any news wrt this topic? What I find dangerous is mistakenly referencing a global variable from a local context, when that is not intended. To me it seems worth adding a qualifier to specify that whatever is not declared as 'global', should only be local (or an error should be thrown). This could also be a julia flag. Do these ideas seem reasonable? Cheers. El sábado, 8 de marzo de 2014 03:40:37 UTC+1, Stefan Karpinski escribió: How about check_locals? You can check for both unused and potentially unassigned locals. On Mar 7, 2014, at 5:39 PM, Leah Hanson astri...@gmail.com wrote: Adding that to TypeCheck sounds pretty reasonable. Functions already provide their local variable names, so it would be a matter of finding all variable usages (excluding LHS assignments). I can probably find time in the next week or so to add it. Maybe check_for_unused_local_variables? (which seems long, but descriptive) -- Leah On Fri, Mar 7, 2014 at 4:02 PM, Jiahao Chen jia...@mit.edu wrote: On Fri, Mar 7, 2014 at 4:22 PM, Stefan Karpinski ste...@karpinski.org wrote: I would prefer to have opt-in (but easy to use) code analysis that can tell you that anwser is an unused variable (or in slight variations of this code, that answer or anwser is always or sometimes not assigned). That sounds like -Wimplicit in fortran compilers, which forces IMPLICIT NONE.
[julia-users] Return value of try error() end
I have a question about the return value of try expr end. julia try 1 == 1 end true julia try 1 == 0 end false julia try error() end false I like that try expr end returns false if expr throws an error. Is this a documented feature of try? For exception handling, it's great being able to write if try e.message == Busy end ... where the type of e is unknown and may not even have a field named message. Sam (Originally asked as part of a longer post to julia-dev, but unanswered: https://groups.google.com/forum/?fromgroups=#!topic/julia-dev/DQFEhzZcjvQ)
[julia-users] Re: table of UTF8 operator symbols
This doesn't entirely help with whether or not the substitution is implemented in Julia yet, but for the purposes of writing papers in Latex I'm a frequent user of http://detexify.kirelabs.org/classify.html when I can't remember the code for a symbol. On Thursday, August 14, 2014 10:17:38 AM UTC-7, Steven G. Johnson wrote: On Thursday, August 14, 2014 12:58:40 PM UTC-4, Douglas Bates wrote: It may be due to a because it's there syndrome but I feel that code is easier to understand when I use ≠ instead of !=. Now I am trying to remember the UTF8 symbols and TeX-like names for == and ===. I don't think there is a Unicode symbol in Julia for ==. For === it is ≡ (\equiv). I know there is a table of these somewhere but perfunctory searches of docs.julialang.org/en/latest haven't revealed it to me. Could someone provide a pointer for me? There is a table of Unicode synonyms in the NEWS file ( https://github.com/JuliaLang/julia/blob/master/NEWS.md). The only table of the supported LaTeX shortcuts that I know of is in the source code: https://github.com/JuliaLang/julia/blob/master/base/latex_symbols.jl It's not in the manual yet, but see https://github.com/JuliaLang/julia/pull/7918
[julia-users] Re: table of UTF8 operator symbols
And apparently there's a unicode version, http://shapecatcher.com/ On Thursday, August 14, 2014 4:00:49 PM UTC-7, Tony Kelman wrote: This doesn't entirely help with whether or not the substitution is implemented in Julia yet, but for the purposes of writing papers in Latex I'm a frequent user of http://detexify.kirelabs.org/classify.html when I can't remember the code for a symbol.
Re: [julia-users] Typo in local variable name not detected
Thanks for the link John. I has a quick glance and it looks like it will do what I want when I want to analyze a file with a bunch of function definitions. It would be nice, however, to get a macro which analyzes all the functions called in a line of code at runtime. E.g. `@lint x = foo(1.1) + bar(y)` and would throw a warning if either `foo` or `bar` reached into global scope for anything other than function definitions. Cheers! Ethan On Thursday, August 14, 2014 2:40:40 PM UTC-7, John Myles White wrote: I think Lint.jl might handle this already: https://github.com/tonyhffong/Lint.jl -- John On Aug 14, 2014, at 2:39 PM, Ethan Anderes ethana...@gmail.com javascript: wrote: It's funny, this issue is by far my biggest source of bugs when coding in Julia. I find myself often prototyping things with commands in the global REPL scope, then wrapping everything into a function once I get it working. Then I forget to pass a variable as an argument to the function and the function accidentally reaches out to the global scope from within the function. It would be nice if there was an easy macro which could warn me (something basic like @time but which says btw: your reaching into global scope for some non-function variables). Unfortunately I don't really know how to write such a macro. Cheers, Ethan On Thursday, August 14, 2014 2:01:08 PM UTC-7, Carlos Becker wrote: Hi all. I have been busy and not following the julia development news. are there any news wrt this topic? What I find dangerous is mistakenly referencing a global variable from a local context, when that is not intended. To me it seems worth adding a qualifier to specify that whatever is not declared as 'global', should only be local (or an error should be thrown). This could also be a julia flag. Do these ideas seem reasonable? Cheers. El sábado, 8 de marzo de 2014 03:40:37 UTC+1, Stefan Karpinski escribió: How about check_locals? You can check for both unused and potentially unassigned locals. On Mar 7, 2014, at 5:39 PM, Leah Hanson astri...@gmail.com wrote: Adding that to TypeCheck sounds pretty reasonable. Functions already provide their local variable names, so it would be a matter of finding all variable usages (excluding LHS assignments). I can probably find time in the next week or so to add it. Maybe check_for_unused_local_variables? (which seems long, but descriptive) -- Leah On Fri, Mar 7, 2014 at 4:02 PM, Jiahao Chen jia...@mit.edu wrote: On Fri, Mar 7, 2014 at 4:22 PM, Stefan Karpinski ste...@karpinski.org wrote: I would prefer to have opt-in (but easy to use) code analysis that can tell you that anwser is an unused variable (or in slight variations of this code, that answer or anwser is always or sometimes not assigned). That sounds like -Wimplicit in fortran compilers, which forces IMPLICIT NONE.
Re: [julia-users] R interface/Rif -- does it still work?
Rif in its master repository on github is working with Julia 0.3. The
moment I get the central MANIFEST to register this it will be available to
all with the default package utilities.
L.
On Thursday, February 6, 2014 2:33:04 PM UTC-5, John Myles White wrote:
I would guess that Rif is out-of-date at this point, but Pierre (who I
believe is the author) will need to confirm that.
-- John
On Feb 6, 2014, at 11:26 AM, Travis Porco see.the...@gmail.com
javascript: wrote:
Has anyone had success with Rif using version 0.2 (or 0.3, though I
can't even get DataFrames to work yet for 0.3) of Julia, R v. 3.0+, on
Macintosh or Linux?
I get this:
Warning: static parameter T does not occur in signature for call at
/Users/travis/.julia/Rif/src/functions.jl:67.
The method will not be callable.
Warning: static parameter S does not occur in signature for call at
/Users/travis/.julia/Rif/src/functions.jl:67.
The method will not be callable.
first, then
ERROR: EnvHash not defined
in initr at /Users/travis/.julia/Rif/src/embeddedr.jl:64
After fixing these problems, on Ubuntu Linux 11.10 (for now), nothing
works:
julia ge = Rif.getGlobalEnv()
REnvironment(Ptr{Void} @0x0a903910)
julia Rif.get(ge,letters)
ERROR: key not found: 16
in getindex at dict.jl:500
in _factory at /home/ubuntu/.julia/Rif/src/Rif.jl:185
in get at /home/ubuntu/.julia/Rif/src/environments.jl:50
julia ge[zz] = 4
ERROR: no method setindex!(REnvironment,Int32,ASCIIString)
Etc. There's probably just some simple thing I overlooked. I met the two
requirements in the Rif documentation (R, compiled with the option
--enable-R-shlib, and R executable in the ${PATH} (or path specified in the
file Make.inc)). I can use RInside to call R from C++, so it isn't an
inability to embed R.
Thanks for any thoughts.
[julia-users] Possibility for an MPI-based cluster manager for use on Cray systems?
Hello all, I recently acquired an account under a project at ORNL's Titan supercomputer, and had hoped to deploy some Julia codes I had written and used on my University's HPC cluster but I'm having some trouble. Titan only allows one to start processes on other computers via the aprun command, which is basically the same as mpirun. You can have processes communicate, but only via MPI (no sshing into compute nodes allowed). I know there is an MPI.jl package available and a ClusterManagers.jl package available. Does anyone have any idea how much work would be involved in trying to create a cluster manager that passes messages between workers via MPI rather than ssh? Alternatively, I primarily use pmap for parallel computation, so I may be able to get by with a wrapper script which will first compute which core will do what task in the pmap-like operation and then create a configuration file that all the julia workers can see what job they should do given their MPI rank from MPI.jl. That might work, but it isn't as clean as the real pmap. Thanks in advance for any guidance y'all might be able to give! -Josh.
[julia-users] Re: Possibility for an MPI-based cluster manager for use on Cray systems?
Do look at ClusterManager.jl, which has support for Sun GridEngine. It may be possible to add aprun support much the same way, without too much effort. MPI.jl is a package that helps processes in the cluster talk over MPI, instead of the default socket based communication that Julia uses. -viral On Friday, August 15, 2014 9:55:35 AM UTC+5:30, Joshua Job wrote: Hello all, I recently acquired an account under a project at ORNL's Titan supercomputer, and had hoped to deploy some Julia codes I had written and used on my University's HPC cluster but I'm having some trouble. Titan only allows one to start processes on other computers via the aprun command, which is basically the same as mpirun. You can have processes communicate, but only via MPI (no sshing into compute nodes allowed). I know there is an MPI.jl package available and a ClusterManagers.jl package available. Does anyone have any idea how much work would be involved in trying to create a cluster manager that passes messages between workers via MPI rather than ssh? Alternatively, I primarily use pmap for parallel computation, so I may be able to get by with a wrapper script which will first compute which core will do what task in the pmap-like operation and then create a configuration file that all the julia workers can see what job they should do given their MPI rank from MPI.jl. That might work, but it isn't as clean as the real pmap. Thanks in advance for any guidance y'all might be able to give! -Josh.
[julia-users] 0.3.0 Release Candidate 4 released
Mac and Ubuntu binaries are up, Windows not yet. Barring any significant problems cropping up over the next few days, this RC is expected to be promoted to 0.3.0-final. Happy coding, -E
[julia-users] Re: 0.3.0 Release Candidate 4 released
A very basic question: How to update without losing packages? Just re-install?
Re: [julia-users] Re: 0.3.0 Release Candidate 4 released
Your packages should remain untouched through upgrades on minor versions. (E.g. if you were on a 0.3.0 prerelease version before, upgrading to 0.3.0-rc4 or even 0.3.0-final should not affect your packages) If you are on 0.2.1, your packages will probably need to be reinstalled, as Julia separates major versions in the package manager. So you'll just need to Pkg.add() all the packages you had before. This won't erase your 0.2.1 packages, they will persist as long as your `~/.julia/v0.2` directory persists. -E On Fri, Aug 15, 2014 at 1:06 AM, KK Sasa genwei...@gmail.com wrote: A very basic question: How to update without losing packages? Just re-install?
