Re: [julia-users] Creation of custom iterators.
Yes; Base is *implicitly* imported, meaning that you can *use* any function
in Base without having to *explicitly* import it. However, in order to
*extend* the function with new methods, you do need to import it
*explicitly* (using a statement like import Base.start, Base.next, Base.done
or import Base: start, next, done). Otherwise, you’ll *shadow* the function
in Base instead.
// T
On Sunday, July 27, 2014 10:02:13 PM UTC+2, Ben Ward wrote:
I see, if I put this into a module in a package will this still be
nessecery? I read that when defining a module, base is implicitly imported.
On Sunday, July 27, 2014 8:58:33 PM UTC+1, Leah Hanson wrote:
You need to either `import Base.start` or implement a function named
`Base.start` instead of `start`. That change will make your `start`
function extend the one from Base with new methods, rather than being a
separate function that happens to be named `start`. (This is a super common
confusion.)
-- Leah
On Sun, Jul 27, 2014 at 2:40 PM, Ben Ward axolotl...@gmail.com wrote:
I've given this a go but it does not quite work as expected:
immutable DepthFirst
tree::Phylogeny
end
function start(x::DepthFirst)
state = Stack(PhyNode)
push!(state, x.tree.Root)
return state
end
function next(x::DepthFirst, state)
current::PhyNode = pop!(state)
for i in current.Children
push!(state, i)
end
return current, state
end
function done(x::DepthFirst, state)
return length(state) == 0 ? true : false
end
Then:
*for i in DepthFirst(myTree)*
*i*
*end*
results in:
*ERROR: `start` has no method matching start(::DepthFirst)*
* in anonymous at no file*
I'm not sure why this is - I have a method defined start() for the
utterable immutable DepthFirst trivial type. I'm clearly missing something
here.
On Sunday, July 27, 2014 7:58:09 PM UTC+1, Tim Holy wrote:
Did you check out the examples I suggested? :)
On Sunday, July 27, 2014 11:56:16 AM Ben Ward wrote:
I had not considered this - so state variable is a complex type which
would
have say the Queue/Stack and current value, and the start, next and
done
methods update it?
On Sunday, July 27, 2014 7:48:56 PM UTC+1, Tim Holy wrote:
Why can't you keep track of everything in the state variable, and
make
your
iterator-types trivial?
--Tim
On Sunday, July 27, 2014 11:07:36 AM Ben Ward wrote:
My traverser types are not exactly wrappers quite a simple as
they
contain
FIFO and FILO structures that keep track of things - I struggle
to
imagine
how else to have them. Do the three iterate methods necessarily
need to
have the second argument state? My types know they are done -
hasReachedEnd() - because there are no more nodes to visit in
their
Ahead
Queue/Stack. So would a done() that only requires the type be
sufficient
with no state input variable as in done(tier, state)?
Best,
Ben.
On Sunday, July 27, 2014 4:49:24 PM UTC+1, Tim Holy wrote:
You can obtain different types of iteration simply by wrapping
obj
in
different thin-wrappers. For example, you can define
immutable SomeOtherWayOfTraversing{T}
obj::T
end
which is used as
for x in SomeOtherWayOfTraversing(obj)
# blah
end
and then write the specific start, next, done methods like
this:
start{T}(iter::SomeOtherWayOfTraversing{T})
You can get totally different behavior this way from what would
happen
when you
just say for x in obj
You might want to browse through more packages to see more
examples.
Here's
one:
https://github.com/timholy/Grid.jl/blob/
600cbcf645a73525fb6d563d5a148b9d8b
2668aa/src/counter.jl but many other packages (DataFrames, Gtk,
HDF5,
etc)
define iterators.
--Tim
On Sunday, July 27, 2014 06:41:43 AM Ben Ward wrote:
I'm not nessecerily trying it iterate over the children of a
node.
Rather I
have defined a series of types that facilitate traversing a
tree in
various
ways for my Phylogenetics.jl package, for example by depth
first:
type TraverserCore
Start::PhyNode
Behind::Stack
History::Array{PhyNode, 1}
Current::PhyNode
end
type DepthFirstTraverser : TreeTraverser
Ahead::Stack
Core::TraverserCore
function DepthFirstTraverser(tree::Phylogeny)
x = new(Stack(PhyNode), TraverserCore(tree.Root,
Stack(PhyNode),
PhyNode
[], tree.Root))
for i in x.Core.Current.Children
push!(x.Ahead, i)
[julia-users] Julia syntax highlighting for gedit
Hello,
I am trying to teach gedit to understand the Julia syntax.
I am using Ubuntu 12.04, 64 bits.
I tried the code from:
https://github.com/cko/juliaLang-gnome
I copied julia.xml to /usr/share/mime and julia.lang
to /usr/share/gtksourceview-3.0/language-specs/
For updating the mime types I used:
sudo update-mime-database /usr/share/mime
It does not work.
I fixed an error in julia.xml and one error in julia.lang,
but there are still errors in julia.lang.
See: https://gist.github.com/ufechner7/19e20d67d5000db294f2
I get the following error message if I launch gedit in the
console and open a .jl file:
(gedit:12899): GtkSourceView-WARNING **: Failed to load
'/usr/share/gtksourceview-3.0/language-specs/julia.lang': Fehler beim
Kompilieren des regulären Ausdrucks
(?-ix)\b('[^\']|\\.'|'\\[0-7]{1,3}'|'\x[0-9a-fA-F]{1,2}'|'\u[0-9a-fA-F]{1,3}'|'\u[0-9a-cA-C][0-9a-fA-F]{3}'|'\u[dD][0-7][0-9a-fA-F]{2}'|'\U[0-9a-fA-F]{1,5}'|'\U10[0-9a-fA-F]{4}')\b
an Zeichen 59: Groß- und Kleinschreibung-beeinflussende Escape-Sequenzen
(\l, \L, \u, \U) sind an dieser Stelle nicht erlaubt.
(Translation: Error compiling the regular expression ...
Escape sequences, that influence capitalization (\l, \L, \u, \U) are not
allowed at this place.)
Any idea how to fix this?
Best regards:
Uwe Fechner
Re: [julia-users] Julia syntax highlighting for gedit
Le mardi 29 juillet 2014 à 02:46 -0700, Uwe Fechner a écrit :
Hello,
I am trying to teach gedit to understand the Julia syntax.
I am using Ubuntu 12.04, 64 bits.
I tried the code from:
https://github.com/cko/juliaLang-gnome
I copied julia.xml to /usr/share/mime and julia.lang
to /usr/share/gtksourceview-3.0/language-specs/
For updating the mime types I used:
sudo update-mime-database /usr/share/mime
It does not work.
I fixed an error in julia.xml and one error in julia.lang,
but there are still errors in julia.lang.
See: https://gist.github.com/ufechner7/19e20d67d5000db294f2
I get the following error message if I launch gedit in the
console and open a .jl file:
(gedit:12899): GtkSourceView-WARNING **: Failed to load
'/usr/share/gtksourceview-3.0/language-specs/julia.lang': Fehler beim
Kompilieren des regulären Ausdrucks (?-ix)\b('[^\']|\\.'|'\
\[0-7]{1,3}'|'\x[0-9a-fA-F]{1,2}'|'\u[0-9a-fA-F]{1,3}'|'\u[0-9a-cA-C][0-9a-fA-F]{3}'|'\u[dD][0-7][0-9a-fA-F]{2}'|'\U[0-9a-fA-F]{1,5}'|'\U10[0-9a-fA-F]{4}')\b
an Zeichen 59: Groß- und Kleinschreibung-beeinflussende Escape-Sequenzen
(\l, \L, \u, \U) sind an dieser Stelle nicht erlaubt.
(Translation: Error compiling the regular expression ...
Escape sequences, that influence capitalization (\l, \L, \u, \U) are
not allowed at this place.)
Any idea how to fix this?
I've not looked at the file, but I'm currently using the attached file
and it works fine. It's not completely up-to-date as regards the
standard function names, so it would need a little more work before it
can be sent to the gedit developers (any help appreciated).
Regards
julia.lang
Description: XML document
Re: [julia-users] Julia syntax highlighting for gedit
Thanks, this works already nicely!
Best regards:
Uwe
On Tuesday, July 29, 2014 12:04:06 PM UTC+2, Milan Bouchet-Valat wrote:
Le mardi 29 juillet 2014 à 02:46 -0700, Uwe Fechner a écrit :
Hello,
I am trying to teach gedit to understand the Julia syntax.
I am using Ubuntu 12.04, 64 bits.
I tried the code from:
https://github.com/cko/juliaLang-gnome
I copied julia.xml to /usr/share/mime and julia.lang
to /usr/share/gtksourceview-3.0/language-specs/
For updating the mime types I used:
sudo update-mime-database /usr/share/mime
It does not work.
I fixed an error in julia.xml and one error in julia.lang,
but there are still errors in julia.lang.
See: https://gist.github.com/ufechner7/19e20d67d5000db294f2
I get the following error message if I launch gedit in the
console and open a .jl file:
(gedit:12899): GtkSourceView-WARNING **: Failed to load
'/usr/share/gtksourceview-3.0/language-specs/julia.lang': Fehler beim
Kompilieren des regulären Ausdrucks (?-ix)\b('[^\']|\\.'|'\
\[0-7]{1,3}'|'\x[0-9a-fA-F]{1,2}'|'\u[0-9a-fA-F]{1,3}'|'\u[0-9a-cA-C][0-9a-fA-F]{3}'|'\u[dD][0-7][0-9a-fA-F]{2}'|'\U[0-9a-fA-F]{1,5}'|'\U10[0-9a-fA-F]{4}')\b
an Zeichen 59: Groß- und Kleinschreibung-beeinflussende Escape-Sequenzen
(\l, \L, \u, \U) sind an dieser Stelle nicht erlaubt.
(Translation: Error compiling the regular expression ...
Escape sequences, that influence capitalization (\l, \L, \u, \U) are
not allowed at this place.)
Any idea how to fix this?
I've not looked at the file, but I'm currently using the attached file
and it works fine. It's not completely up-to-date as regards the
standard function names, so it would need a little more work before it
can be sent to the gedit developers (any help appreciated).
Regards
[julia-users] Julia call to Seaborn library
A recent post on reddit http://badhessian.org/2014/07/six-of-one-plot-half-dozen-of-the-other/ brought my attention to the python seaborn package: http://web.stanford.edu/~mwaskom/software/seaborn/ Seaborn is a really cool Python visualization library based on matplotlib and pandas, and provides a high-level interface for drawing attractive statistical graphics. Any chance to use this library already from Julia via PyPlot or PyCall?? --Bernd
[julia-users] questions about the format of function arguments in the documentation
Hi everyone, I started using Julia since last Saturday for my PhD work. My background in programming is mostly C++, C, and some non-performance-oriented MATLAB. I have never used R. Despite my lack of modern programming languages, I was able to convert some of my previous prototype code from MATLAB within hours. Thank you all for your hard work in contributing to this language! I have some questions about the format of the documentation. Consider the *sparse(I, J, V[, m, n, combine]**)* function. After some trial-and-error at 3am, I finally figured out I just add *m* and *n* to the argument list of *sparse()* if I wish to specify the size of the sparse matrix with this constructor function. 1) Does this mean the notation [, blah, blah2, ...] in the documentation mean blah, blah2, ... are all optional arguments? 2) If this a standard notation across other modern object-oriented languages, would it be possible to make a wikipedia link to this notation, and put it on the tutorial or the documentation page? If this isn't a standard notation, would it be possible to include a short example in the documentation?
[julia-users] Re: questions about the format of function arguments in the documentation
[] is used to indicate that some parameters is optional, but it is not used consistently throughout julia documentation. See https://github.com/JuliaLang/julia/issues/4902 for some discussion. kl. 09:42:43 UTC+2 tirsdag 29. juli 2014 skrev Roy Wang følgende: Hi everyone, I started using Julia since last Saturday for my PhD work. My background in programming is mostly C++, C, and some non-performance-oriented MATLAB. I have never used R. Despite my lack of modern programming languages, I was able to convert some of my previous prototype code from MATLAB within hours. Thank you all for your hard work in contributing to this language! I have some questions about the format of the documentation. Consider the *sparse(I, J, V[, m, n, combine]**)* function. After some trial-and-error at 3am, I finally figured out I just add *m* and *n* to the argument list of *sparse()* if I wish to specify the size of the sparse matrix with this constructor function. 1) Does this mean the notation [, blah, blah2, ...] in the documentation mean blah, blah2, ... are all optional arguments? 2) If this a standard notation across other modern object-oriented languages, would it be possible to make a wikipedia link to this notation, and put it on the tutorial or the documentation page? If this isn't a standard notation, would it be possible to include a short example in the documentation?
[julia-users] Help with Traceback
1 out of 20 time my process is crashing with the following traceback, there doesn't seem to be anything useful in it. I did find this issue ( https://github.com/JuliaLang/julia/issues/6611) which seems similar, and is fixed as part of Julia 0.3- (we're using 0.2.1). I'm wondering if anyone else has run into anything similar themselves and have found a solution. Cheers, Steve Traceback: in abstract_call_gf at inference.jl:623 in abstract_call at inference.jl:701 in abstract_eval_call at inference.jl:789 in abstract_eval at inference.jl:814 in abstract_eval_arg at inference.jl:748 in typeinf at inference.jl:1324 in typeinf_ext at inference.jl:1092 in include at boot.jl:238fatal: error thrown and no exception handler available. Full Traceback: https://gist.github.com/sbchisholm/1969b94447b2b9b16c60
[julia-users] array doubling
Whats the easiest way of going from an array [1,2,3] - [1,1,2,2,3,3] i.e. repeating all elements 2 (or more generally, n) times? A
Re: [julia-users] array doubling
repeat([1, 2, 3], inner = [2]) On Jul 29, 2014, at 7:03 AM, Andrei Berceanu andreiberce...@gmail.com wrote: Whats the easiest way of going from an array [1,2,3] - [1,1,2,2,3,3] i.e. repeating all elements 2 (or more generally, n) times? A
Re: [julia-users] array doubling
nice, ty! btw, the manual at http://julia.readthedocs.org/en/latest/stdlib/linalg/#Base.repeat says repeat(*A*, *inner = Int*, []*outer = Int*[]) shouldn't that be repeat(*A*, *inner = Int*[], *outer = Int*[]) i.e isn't the comma in the wrong position? On Tuesday, July 29, 2014 4:06:22 PM UTC+2, John Myles White wrote: repeat([1, 2, 3], inner = [2]) On Jul 29, 2014, at 7:03 AM, Andrei Berceanu andreib...@gmail.com javascript: wrote: Whats the easiest way of going from an array [1,2,3] - [1,1,2,2,3,3] i.e. repeating all elements 2 (or more generally, n) times? A
Re: [julia-users] array doubling
Yeah, that’s a typo. Could you fix it? — John On Jul 29, 2014, at 7:23 AM, Andrei Berceanu andreiberce...@gmail.com wrote: nice, ty! btw, the manual at http://julia.readthedocs.org/en/latest/stdlib/linalg/#Base.repeat says repeat(A, inner = Int, []outer = Int[]) shouldn't that be repeat(A, inner = Int[], outer = Int[]) i.e isn't the comma in the wrong position? On Tuesday, July 29, 2014 4:06:22 PM UTC+2, John Myles White wrote: repeat([1, 2, 3], inner = [2]) On Jul 29, 2014, at 7:03 AM, Andrei Berceanu andreib...@gmail.com wrote: Whats the easiest way of going from an array [1,2,3] - [1,1,2,2,3,3] i.e. repeating all elements 2 (or more generally, n) times? A
[julia-users] Re: Human readable files as inputs in Julia
On Sunday, July 27, 2014 8:38:37 AM UTC-4, Oliver Pewter wrote: I have thought about YAML, JSON, serialised Julia objects in a file or straight up Julia code. I would tend to suggest just entering Julia code.I've been down this path myself with custom input-file formats for simulation parameters you keep adding features (first comments, then, arithmetic, then conditionals, etc.) until you've basically re-created a (bad) programming language. You can define your Julia interface so that for simple uses they don't need to know how to program (i.e. they don't need a Turing-complete subset of Julia), they just need to know how to set parameters. e.g. S = Simulation(tolerance=1e-3, radius=7, ω=5) run(S) ... This way, the whole language is available if you need it, but making a basic input file doesn't feel too much like programming.
Re: [julia-users] array doubling
That's because Sphinx identifies [] as optional arguments in the ..function macro-thingy, and it does funny re-arrangements with it. The source is correct; it's the output that is wrong. It's annoying, but I've not dug into Sphinx enough to determine how we might disable it. On Tuesday, July 29, 2014 10:24:01 AM UTC-4, John Myles White wrote: Yeah, that’s a typo. Could you fix it? — John On Jul 29, 2014, at 7:23 AM, Andrei Berceanu andreib...@gmail.com javascript: wrote: nice, ty! btw, the manual at http://julia.readthedocs.org/en/latest/stdlib/linalg/#Base.repeat says repeat(*A*, *inner = Int*, []*outer = Int*[]) shouldn't that be repeat(*A*, *inner = Int*[], *outer = Int*[]) i.e isn't the comma in the wrong position? On Tuesday, July 29, 2014 4:06:22 PM UTC+2, John Myles White wrote: repeat([1, 2, 3], inner = [2]) On Jul 29, 2014, at 7:03 AM, Andrei Berceanu andreib...@gmail.com wrote: Whats the easiest way of going from an array [1,2,3] - [1,1,2,2,3,3] i.e. repeating all elements 2 (or more generally, n) times? A
[julia-users] Numerical types and machine word size
Dear all, By reading the docs, Int is an alias for either Int32 or Int64 depending on the WORD_SIZE of the machine where Julia is running. Why we do not have a similar Float construct for floating points? Can we say Real is either Float32 or Float64 likewise? Is there any theoretical difference? Best, Júlio.
Re: [julia-users] Numerical types and machine word size
See answers to the same question here: https://groups.google.com/forum/#!searchin/julia-users/Float$20Float32$20Float$2064/julia-users/1tDvMbfCUEE/BJCu0-S7OawJ On Tue, Jul 29, 2014 at 11:19 AM, Júlio Hoffimann julio.hoffim...@gmail.com wrote: Dear all, By reading the docs, Int is an alias for either Int32 or Int64 depending on the WORD_SIZE of the machine where Julia is running. Why we do not have a similar Float construct for floating points? Can we say Real is either Float32 or Float64 likewise? Is there any theoretical difference? Best, Júlio.
Re: [julia-users] Numerical types and machine word size
Integer size is system-dependent while floating-point size is not. The 8087 https://en.wikipedia.org/wiki/Intel_8087 already had 64-bit floats and every x86 since the i486 https://en.wikipedia.org/wiki/Intel_80486 has too, so there's no reason to change the size of floating-point numbers on different systems. When you write 1.0 in Julia, it is always a Float64. Real is an abstract type that has many non-floating-point subtypes, including all integer types and rationals. Being a subtype of Real means, as the name suggests, that a type represents values on the real number line. There is a FloatingPoint abstract type, which is closer to what you're thinking of, but it also includes BigFloat. On Tue, Jul 29, 2014 at 11:19 AM, Júlio Hoffimann julio.hoffim...@gmail.com wrote: Dear all, By reading the docs, Int is an alias for either Int32 or Int64 depending on the WORD_SIZE of the machine where Julia is running. Why we do not have a similar Float construct for floating points? Can we say Real is either Float32 or Float64 likewise? Is there any theoretical difference? Best, Júlio.
[julia-users] Bypass automatic printing of elements in show(io::IO,x::AbstractArray)
I have defined a subclass of AbstractArray for which I do *not* want to use
the default AbstractArray printing machinery in show.jl . My assumption,
apparently incorrect, is that I simply needed to overload show.
Unfortunately, my overloaded version is never used.
Here is some sample code. Note two things:
- The code contained within a named module, and Base.Array is not
imported, so there is not a name conflict here.
- The function eleltype is indeed defined, and returns T. The actual
eltype of this array is Scalar{T}. But the data is not stored as a
contiguous memory buffer containing Scalar{T} objects; it has been
compressed in a certain way.
show(io::IO,x::Array) = print( io, CVX $(eleltype(x)) $(ndims(x))D Array
... )
show{T,N}(io::IO,::Type{Array{T,N}}) = print( io, CVX $(T) $(N)D Array )
show(io::IO,::Type{Array}) = print( io, CVX Array )
The last two lines work as expected, suggesting I'm indeed exporting if I
type CVX.Array or CVX.Array{Float64,2} into the REPL, my custom show
commands are called. But if I attempt to instantiate an instance, and show
that, it still calls the show.jl code; my overloaded version is ignored.
Here's what I get:
2x2 Array{Float64,2}:
#undef #undef
#undef #undef
And here is the output of an explicit call to show(A)
CVX Float64 2D Array ...
I tried modifying that first line as follows
show{T,N}(io::IO,x::Array{T,N}) = print( io, CVX $(T) $(N)D Array ... )
but that didn't make a difference. I tried different combinations of
import/export
show as well. As you probably know I do have to import it, but I don't have
to export (at least, I don't think so), since I'm overloading. I also tried
overloading print as well.
Any hints? Thanks in advance for the help. I'm using Julia 0.3rc1 on the
Mac...
Re: [julia-users] Bypass automatic printing of elements in show(io::IO,x::AbstractArray)
Some of the printing machinery has gotten to be quite a mess – I ran into
this myself recently, specifically for arrays. I think you need to hook
into the display function somehow, but I gave up unravelling the tangle of
method calls and just ended up adding the methods I needed make the default
abstract printing work. Sorry that's not so helpful, but maybe someone else
can give more specific advice. In any case, this part of the standard
library needs some cleanup.
On Tue, Jul 29, 2014 at 12:08 PM, Michael Grant m...@cvxr.com wrote:
I have defined a subclass of AbstractArray for which I do *not* want to
use the default AbstractArray printing machinery in show.jl . My
assumption, apparently incorrect, is that I simply needed to overload show.
Unfortunately, my overloaded version is never used.
Here is some sample code. Note two things:
- The code contained within a named module, and Base.Array is not
imported, so there is not a name conflict here.
- The function eleltype is indeed defined, and returns T. The actual
eltype of this array is Scalar{T}. But the data is not stored as a
contiguous memory buffer containing Scalar{T} objects; it has been
compressed in a certain way.
show(io::IO,x::Array) = print( io, CVX $(eleltype(x)) $(ndims(x))D Array
... )
show{T,N}(io::IO,::Type{Array{T,N}}) = print( io, CVX $(T) $(N)D Array )
show(io::IO,::Type{Array}) = print( io, CVX Array )
The last two lines work as expected, suggesting I'm indeed exporting if I
type CVX.Array or CVX.Array{Float64,2} into the REPL, my custom show
commands are called. But if I attempt to instantiate an instance, and show
that, it still calls the show.jl code; my overloaded version is ignored.
Here's what I get:
2x2 Array{Float64,2}:
#undef #undef
#undef #undef
And here is the output of an explicit call to show(A)
CVX Float64 2D Array ...
I tried modifying that first line as follows
show{T,N}(io::IO,x::Array{T,N}) = print( io, CVX $(T) $(N)D Array ... )
but that didn't make a difference. I tried different combinations of
import/export
show as well. As you probably know I do have to import it, but I don't
have to export (at least, I don't think so), since I'm overloading. I also
tried overloading print as well.
Any hints? Thanks in advance for the help. I'm using Julia 0.3rc1 on the
Mac...
[julia-users] Re: Bypass automatic printing of elements in show(io::IO,x::AbstractArray)
I'll quote another ongoing thread Yes; Base is *implicitly* imported, meaning that you can *use* any function in Base without having to *explicitly* import it. However, in order to *extend* the function with new methods, you do need to import it *explicitly* (using a statement like import Base.start, Base.next, Base.done or import Base: start, next, done). Otherwise, you’ll *shadow* the function in Base instead. So you can either import import import Base.show first, or change the method definition to Base.show(args...) =... I'm actually not sure how it will interact with your Array type vs Base.Array I feel like this is one of the most frequently asked questions on the list. That may be a sign that could use more discoverability.
[julia-users] Distinguish between modules when embedding Julia in C
Good morning, I am exploring the idea of embedding Julia in our C++ medical image reconstruction streaming framework. Each piece of a given reconstruction workflow is basically a C++ class. Groups of classes live in dynamic libraries that are loaded at runtime (making them essentially plugins). Anyway, we currently have a group of classes that provide an interface to an embedded Python runtime, allowing users to write reconstruction code in Python rather than C++. The main problem with embedding a Python interpreter and running code that calls NumPy is that we have to manually handle a lock for classes calling Python due to the GIL. I'd like to replace this functionality with an interface to Julia. Two questions: 1. Is it safe to allow code in multiple threads access the Julia runtime using the C-API? 2. If so, how would I distinguish between functions of the same name contained in different files using the C-API? For example, *NoiseAdjust.jl* and *Filter.jl* both define a process function which modifies a multi-dimensional array. When the streaming framework loads, I can open, read, eval both files. At this point, do I ensure the files have different module declarations and look them up at runtime? I need to somehow grab distinct pointers to each process function. Notes: - The julia files are installed in a location unrelated to the Julia installation. - The process functions from each file/module can be called many times and simultaneously in various threads. Thanks a lot for your help... The C-API is looking great! -Joe
Re: [julia-users] Re: Bypass automatic printing of elements in show(io::IO,x::AbstractArray)
That may or may not be the issue here – it's unclear to me. Even with appropriate imports and qualifications, it is not obvious how to change the way custom array types are shown. On Tue, Jul 29, 2014 at 12:31 PM, g galenon...@gmail.com wrote: I'll quote another ongoing thread Yes; Base is *implicitly* imported, meaning that you can *use* any function in Base without having to *explicitly* import it. However, in order to *extend* the function with new methods, you do need to import it *explicitly* (using a statement like import Base.start, Base.next, Base.done or import Base: start, next, done). Otherwise, you’ll *shadow* the function in Base instead. So you can either import import import Base.show first, or change the method definition to Base.show(args...) =... I'm actually not sure how it will interact with your Array type vs Base.Array I feel like this is one of the most frequently asked questions on the list. That may be a sign that could use more discoverability.
Re: [julia-users] Distinguish between modules when embedding Julia in C
On Tue, Jul 29, 2014 at 12:33 PM, Joseph Naegele joseph.naeg...@gmail.com wrote: Is it safe to allow code in multiple threads access the Julia runtime using the C-API? It is currently not safe – Julia is not reentrant. This will change when we add threading support (already in progress), but even then, it's not yet clear if it will be possible to just arbitrarily call Julia code from C++ threads. There's a lot of crazy things that need to be done to make threading work reliably and conveniently, especially in the presence of garbage collection, which will need stop all threads by signalling them so that it can mark and sweep while nothing is being changed.
[julia-users] Roadmap for 0.4?
I saw the Roadmap for 0.3 here: https://github.com/JuliaLang/julia/issues/4853 But I cannot find the Roadmap for 0.4... Does anyone know where that is located? thx
Re: [julia-users] Julia syntax highlighting for gedit
Note that there's a julia.lang in the Julia repo
https://github.com/JuliaLang/julia/blob/master/contrib/julia.lang, an
earlier version of which was submitted to gtksourceview
https://bugzilla.gnome.org/show_bug.cgi?id=700410 and included in it
https://git.gnome.org/browse/gtksourceview/plain/data/language-specs/julia.lang
(since release 3.10 IIRC).
Apart from the changes already made to the version in the JuliaLang repo
since the submission (diff http://www.diffchecker.com/vdq7u5zq), issue
#6132 https://github.com/JuliaLang/julia/issues/6132 tracks the addition
of support for multiline comments to various editors. I was meaning to
address it but haven't had the time yet.
If the versions linked/attached previously in this thread contain this or
other fixes, those should at least be submitted to the julia.lang in the
Julia repo. Afterwards, the changes should be submitted to gtksourceview as
well.
On Tuesday, July 29, 2014 11:17:00 AM UTC+1, Uwe Fechner wrote:
Thanks, this works already nicely!
Best regards:
Uwe
On Tuesday, July 29, 2014 12:04:06 PM UTC+2, Milan Bouchet-Valat wrote:
Le mardi 29 juillet 2014 à 02:46 -0700, Uwe Fechner a écrit :
Hello,
I am trying to teach gedit to understand the Julia syntax.
I am using Ubuntu 12.04, 64 bits.
I tried the code from:
https://github.com/cko/juliaLang-gnome
I copied julia.xml to /usr/share/mime and julia.lang
to /usr/share/gtksourceview-3.0/language-specs/
For updating the mime types I used:
sudo update-mime-database /usr/share/mime
It does not work.
I fixed an error in julia.xml and one error in julia.lang,
but there are still errors in julia.lang.
See: https://gist.github.com/ufechner7/19e20d67d5000db294f2
I get the following error message if I launch gedit in the
console and open a .jl file:
(gedit:12899): GtkSourceView-WARNING **: Failed to load
'/usr/share/gtksourceview-3.0/language-specs/julia.lang': Fehler beim
Kompilieren des regulären Ausdrucks (?-ix)\b('[^\']|\\.'|'\
\[0-7]{1,3}'|'\x[0-9a-fA-F]{1,2}'|'\u[0-9a-fA-F]{1,3}'|'\u[0-9a-cA-C][0-9a-fA-F]{3}'|'\u[dD][0-7][0-9a-fA-F]{2}'|'\U[0-9a-fA-F]{1,5}'|'\U10[0-9a-fA-F]{4}')\b
an Zeichen 59: Groß- und Kleinschreibung-beeinflussende Escape-Sequenzen
(\l, \L, \u, \U) sind an dieser Stelle nicht erlaubt.
(Translation: Error compiling the regular expression ...
Escape sequences, that influence capitalization (\l, \L, \u, \U) are
not allowed at this place.)
Any idea how to fix this?
I've not looked at the file, but I'm currently using the attached file
and it works fine. It's not completely up-to-date as regards the
standard function names, so it would need a little more work before it
can be sent to the gedit developers (any help appreciated).
Regards
Re: [julia-users] Roadmap for 0.4?
There is no official roadmap for 0.4 yet – just a collection of ideas in various people's heads and spread across our mailing group and GitHub discussions. A few major changes that come to mind off the top of my head: - array views - string + I/O revamp - pkg revamp (again) - static compilation - multithreading - built-in debugger That is a pretty significant set of features. As always, there's a chance that not all of these will make it into 0.4, but I'm fairly confident about most of these. On Tue, Jul 29, 2014 at 12:41 PM, D johnson derrick.john...@mac.com wrote: I saw the Roadmap for 0.3 here: https://github.com/JuliaLang/julia/issues/4853 But I cannot find the Roadmap for 0.4... Does anyone know where that is located? thx
Re: [julia-users] Roadmap for 0.4?
Might we see the changes to the type system that are required to get higher-order functions to specialize on input functions? -- John On Jul 29, 2014, at 9:49 AM, Stefan Karpinski ste...@karpinski.org wrote: There is no official roadmap for 0.4 yet – just a collection of ideas in various people's heads and spread across our mailing group and GitHub discussions. A few major changes that come to mind off the top of my head: array views string + I/O revamp pkg revamp (again) static compilation multithreading built-in debugger That is a pretty significant set of features. As always, there's a chance that not all of these will make it into 0.4, but I'm fairly confident about most of these. On Tue, Jul 29, 2014 at 12:41 PM, D johnson derrick.john...@mac.com wrote: I saw the Roadmap for 0.3 here: https://github.com/JuliaLang/julia/issues/4853 But I cannot find the Roadmap for 0.4... Does anyone know where that is located? thx
Re: [julia-users] Roadmap for 0.4?
You can also take a look at specific github issues that have been marked 0.4: https://github.com/JuliaLang/julia/milestones/0.4 It may take another trip to Boston, but I'm also pulling for the Dates module in 0.4! -Jacob On Tue, Jul 29, 2014 at 12:51 PM, John Myles White johnmyleswh...@gmail.com wrote: Might we see the changes to the type system that are required to get higher-order functions to specialize on input functions? -- John On Jul 29, 2014, at 9:49 AM, Stefan Karpinski ste...@karpinski.org wrote: There is no official roadmap for 0.4 yet – just a collection of ideas in various people's heads and spread across our mailing group and GitHub discussions. A few major changes that come to mind off the top of my head: - array views - string + I/O revamp - pkg revamp (again) - static compilation - multithreading - built-in debugger That is a pretty significant set of features. As always, there's a chance that not all of these will make it into 0.4, but I'm fairly confident about most of these. On Tue, Jul 29, 2014 at 12:41 PM, D johnson derrick.john...@mac.com wrote: I saw the Roadmap for 0.3 here: https://github.com/JuliaLang/julia/issues/4853 But I cannot find the Roadmap for 0.4... Does anyone know where that is located? thx
Re: [julia-users] Roadmap for 0.4?
Seems like triangular dispatch may be on its way, too, which would be really cool. 0.4: everything you want, plus the pony --Tim On Tuesday, July 29, 2014 12:49:04 PM Stefan Karpinski wrote: There is no official roadmap for 0.4 yet – just a collection of ideas in various people's heads and spread across our mailing group and GitHub discussions. A few major changes that come to mind off the top of my head: - array views - string + I/O revamp - pkg revamp (again) - static compilation - multithreading - built-in debugger That is a pretty significant set of features. As always, there's a chance that not all of these will make it into 0.4, but I'm fairly confident about most of these. On Tue, Jul 29, 2014 at 12:41 PM, D johnson derrick.john...@mac.com wrote: I saw the Roadmap for 0.3 here: https://github.com/JuliaLang/julia/issues/4853 But I cannot find the Roadmap for 0.4... Does anyone know where that is located? thx
Re: [julia-users] Roadmap for 0.4?
I would hope/work for an improved help/documentation system, including user-defined documentation. On Tue, 2014-07-29 at 17:52, Jacob Quinn quinn.jac...@gmail.com wrote: You can also take a look at specific github issues that have been marked 0.4: https://github.com/JuliaLang/julia/milestones/0.4 It may take another trip to Boston, but I'm also pulling for the Dates module in 0.4! -Jacob On Tue, Jul 29, 2014 at 12:51 PM, John Myles White johnmyleswh...@gmail.com wrote: Might we see the changes to the type system that are required to get higher-order functions to specialize on input functions? -- John On Jul 29, 2014, at 9:49 AM, Stefan Karpinski ste...@karpinski.org wrote: There is no official roadmap for 0.4 yet – just a collection of ideas in various people's heads and spread across our mailing group and GitHub discussions. A few major changes that come to mind off the top of my head: - array views - string + I/O revamp - pkg revamp (again) - static compilation - multithreading - built-in debugger That is a pretty significant set of features. As always, there's a chance that not all of these will make it into 0.4, but I'm fairly confident about most of these. On Tue, Jul 29, 2014 at 12:41 PM, D johnson derrick.john...@mac.com wrote: I saw the Roadmap for 0.3 here: https://github.com/JuliaLang/julia/issues/4853 But I cannot find the Roadmap for 0.4... Does anyone know where that is located? thx --
Re: [julia-users] array doubling
That explains why the github page showed the right syntax! *head bump A On Tuesday, July 29, 2014 5:10:42 PM UTC+2, Matt Bauman wrote: That's because Sphinx identifies [] as optional arguments in the ..function macro-thingy, and it does funny re-arrangements with it. The source is correct; it's the output that is wrong. It's annoying, but I've not dug into Sphinx enough to determine how we might disable it. On Tuesday, July 29, 2014 10:24:01 AM UTC-4, John Myles White wrote: Yeah, that’s a typo. Could you fix it? — John On Jul 29, 2014, at 7:23 AM, Andrei Berceanu andreib...@gmail.com wrote: nice, ty! btw, the manual at http://julia.readthedocs.org/en/latest/stdlib/linalg/#Base.repeat says repeat(*A*, *inner = Int*, []*outer = Int*[]) shouldn't that be repeat(*A*, *inner = Int*[], *outer = Int*[]) i.e isn't the comma in the wrong position? On Tuesday, July 29, 2014 4:06:22 PM UTC+2, John Myles White wrote: repeat([1, 2, 3], inner = [2]) On Jul 29, 2014, at 7:03 AM, Andrei Berceanu andreib...@gmail.com wrote: Whats the easiest way of going from an array [1,2,3] - [1,1,2,2,3,3] i.e. repeating all elements 2 (or more generally, n) times? A
Re: [julia-users] Distinguish between modules when embedding Julia in C
Great thanks for the clarification. I guess I should have ascertained that it is not reentrant since the C-API obviously modifies some global state. I will look at the current development for threading support for fun but in the meantime, will the implementation always modify global state or will the C-API pass around a state structure, allowing for multiple embedded instances? On Tuesday, July 29, 2014 12:40:05 PM UTC-4, Stefan Karpinski wrote: On Tue, Jul 29, 2014 at 12:33 PM, Joseph Naegele joseph@gmail.com javascript: wrote: Is it safe to allow code in multiple threads access the Julia runtime using the C-API? It is currently not safe – Julia is not reentrant. This will change when we add threading support (already in progress), but even then, it's not yet clear if it will be possible to just arbitrarily call Julia code from C++ threads. There's a lot of crazy things that need to be done to make threading work reliably and conveniently, especially in the presence of garbage collection, which will need stop all threads by signalling them so that it can mark and sweep while nothing is being changed.
Re: [julia-users] Roadmap for 0.4?
On Tue, Jul 29, 2014 at 12:51 PM, John Myles White johnmyleswh...@gmail.com wrote: Might we see the changes to the type system that are required to get higher-order functions to specialize on input functions? I believe this is one of the things that Jeff wants to do, but obviously he's the definitive word on what he wants to do :-)
Re: [julia-users] Bypass automatic printing of elements in show(io::IO,x::AbstractArray)
The array printing code writes #undef when an attempt to access an element throws an error. Fix your array indexing code and it should work. I've written two relatively complete and self-contained AbstractArray derivatives in Gtk.jl if you want examples on the expected API for an AbstractArray (one for implementing GLists, one for StridedArrays) If you want to override the code used in the repl, I think you need to overload display(), not show(). But either way, you need to fix your getindex function to meet the implicit AbstractArray interface. On Tuesday, July 29, 2014, Stefan Karpinski ste...@karpinski.org wrote: That may or may not be the issue here – it's unclear to me. Even with appropriate imports and qualifications, it is not obvious how to change the way custom array types are shown. On Tue, Jul 29, 2014 at 12:31 PM, g galenon...@gmail.com javascript:_e(%7B%7D,'cvml','galenon...@gmail.com'); wrote: I'll quote another ongoing thread Yes; Base is *implicitly* imported, meaning that you can *use* any function in Base without having to *explicitly* import it. However, in order to *extend* the function with new methods, you do need to import it *explicitly* (using a statement like import Base.start, Base.next, Base.done or import Base: start, next, done). Otherwise, you’ll *shadow* the function in Base instead. So you can either import import import Base.show first, or change the method definition to Base.show(args...) =... I'm actually not sure how it will interact with your Array type vs Base.Array I feel like this is one of the most frequently asked questions on the list. That may be a sign that could use more discoverability.
Re: [julia-users] Roadmap for 0.4?
On Tue, Jul 29, 2014 at 12:55 PM, Mauro mauro...@runbox.com wrote: I would hope/work for an improved help/documentation system, including user-defined documentation. Yes, that's also important and we definitely need to make big progress there.
Re: [julia-users] Roadmap for 0.4?
+1 On Tuesday, July 29, 2014 01:17:59 PM Stefan Karpinski wrote: On Tue, Jul 29, 2014 at 12:55 PM, Mauro mauro...@runbox.com wrote: I would hope/work for an improved help/documentation system, including user-defined documentation. Yes, that's also important and we definitely need to make big progress there.
[julia-users] Re: Julia call to Seaborn library
Interesting question. I obviously didn't evaluate that as part of the blog post, but it seems like it could be possible. The one hiccup could be that Seaborn seems to be a wrapper around matplotlib, so that Seaborn code can be used interchangeably with matplotlib within Python. Not knowing how PyPlot.jl works, if you were to import Seaborn using PyCall, maybe they all would communicate to the same backend and work? On Tuesday, July 29, 2014 7:22:06 AM UTC-4, Bernd Blasius wrote: A recent post on reddit http://badhessian.org/2014/07/six-of-one-plot-half-dozen-of-the-other/ brought my attention to the python seaborn package: http://web.stanford.edu/~mwaskom/software/seaborn/ Seaborn is a really cool Python visualization library based on matplotlib and pandas, and provides a high-level interface for drawing attractive statistical graphics. Any chance to use this library already from Julia via PyPlot or PyCall?? --Bernd
Re: [julia-users] Re: Bypass automatic printing of elements in show(io::IO,x::AbstractArray)
My mistake. On Tuesday, July 29, 2014, Jameson Nash vtjn...@gmail.com wrote: The array printing code writes #undef when an attempt to access an element throws an error. Fix your array indexing code and it should work. I've written two relatively complete and self-contained AbstractArray derivatives in Gtk.jl if you want examples on the expected API for an AbstractArray (one for implementing GLists, one for StridedArrays) If you want to override the code used in the repl, I think you need to overload display(), not show(). But either way, you need to fix your getindex function to meet the implicit AbstractArray interface. On Tuesday, July 29, 2014, Stefan Karpinski ste...@karpinski.org javascript:_e(%7B%7D,'cvml','ste...@karpinski.org'); wrote: That may or may not be the issue here – it's unclear to me. Even with appropriate imports and qualifications, it is not obvious how to change the way custom array types are shown. On Tue, Jul 29, 2014 at 12:31 PM, g galenon...@gmail.com wrote: I'll quote another ongoing thread Yes; Base is *implicitly* imported, meaning that you can *use* any function in Base without having to *explicitly* import it. However, in order to *extend* the function with new methods, you do need to import it *explicitly* (using a statement like import Base.start, Base.next, Base.done or import Base: start, next, done). Otherwise, you’ll *shadow* the function in Base instead. So you can either import import import Base.show first, or change the method definition to Base.show(args...) =... I'm actually not sure how it will interact with your Array type vs Base.Array I feel like this is one of the most frequently asked questions on the list. That may be a sign that could use more discoverability.
Re: [julia-users] Julia syntax highlighting for gedit
Le mardi 29 juillet 2014 à 09:42 -0700, Waldir Pimenta a écrit : Note that there's a julia.lang in the Julia repo, an earlier version of which was submitted to gtksourceview and included in it (since release 3.10 IIRC). Ah, good to know it got included. I wasn't aware of that. Apart from the changes already made to the version in the JuliaLang repo since the submission (diff), issue #6132 tracks the addition of support for multiline comments to various editors. I was meaning to address it but haven't had the time yet. If the versions linked/attached previously in this thread contain this or other fixes, those should at least be submitted to the julia.lang in the Julia repo. Afterwards, the changes should be submitted to gtksourceview as well. Unfortunately, I wrote that file from scratch (based on the Python syntax spec file) before I noticed your work, so merging the changes won't be completely trivial. I'll try to have a look, but I'm not even sure my file brings improvements over yours at all. Regards
[julia-users] Re: Bypass automatic printing of elements in show(io::IO,x::AbstractArray)
I've answered my own question here: the key, for now, is to overload
writemime. However, it doesn't seem that should be necessary, so I've
commented on an existing GitHub issue
https://github.com/JuliaLang/julia/issues/6117#issuecomment-50502411
about it.
The #undef issue is *not my problem. *I am not interested in printing the
values *at all.*
On Tuesday, July 29, 2014 11:08:06 AM UTC-5, Michael Grant wrote:
I have defined a subclass of AbstractArray for which I do *not* want to
use the default AbstractArray printing machinery in show.jl . My
assumption, apparently incorrect, is that I simply needed to overload show.
Unfortunately, my overloaded version is never used.
Here is some sample code. Note two things:
- The code contained within a named module, and Base.Array is not
imported, so there is not a name conflict here.
- The function eleltype is indeed defined, and returns T. The actual
eltype of this array is Scalar{T}. But the data is not stored as a
contiguous memory buffer containing Scalar{T} objects; it has been
compressed in a certain way.
show(io::IO,x::Array) = print( io, CVX $(eleltype(x)) $(ndims(x))D Array
... )
show{T,N}(io::IO,::Type{Array{T,N}}) = print( io, CVX $(T) $(N)D Array )
show(io::IO,::Type{Array}) = print( io, CVX Array )
The last two lines work as expected, suggesting I'm indeed exporting if I
type CVX.Array or CVX.Array{Float64,2} into the REPL, my custom show
commands are called. But if I attempt to instantiate an instance, and show
that, it still calls the show.jl code; my overloaded version is ignored.
Here's what I get:
2x2 Array{Float64,2}:
#undef #undef
#undef #undef
And here is the output of an explicit call to show(A)
CVX Float64 2D Array ...
I tried modifying that first line as follows
show{T,N}(io::IO,x::Array{T,N}) = print( io, CVX $(T) $(N)D Array ... )
but that didn't make a difference. I tried different combinations of
import/export
show as well. As you probably know I do have to import it, but I don't
have to export (at least, I don't think so), since I'm overloading. I also
tried overloading print as well.
Any hints? Thanks in advance for the help. I'm using Julia 0.3rc1 on the
Mac...
[julia-users] Re: Bypass automatic printing of elements in show(io::IO,x::AbstractArray)
Thanks, but in fact imports/exports are not the problem here. I'm already importing show. It turns out that the real problem is that *show is not being used *in the scenario above; rather, writemime is. On Tuesday, July 29, 2014 11:31:23 AM UTC-5, g wrote: I'll quote another ongoing thread Yes; Base is *implicitly* imported, meaning that you can *use* any function in Base without having to *explicitly* import it. However, in order to *extend* the function with new methods, you do need to import it *explicitly* (using a statement like import Base.start, Base.next, Base.done or import Base: start, next, done). Otherwise, you’ll *shadow* the function in Base instead. So you can either import import import Base.show first, or change the method definition to Base.show(args...) =... I'm actually not sure how it will interact with your Array type vs Base.Array I feel like this is one of the most frequently asked questions on the list. That may be a sign that could use more discoverability.
Re: [julia-users] Re: Bypass automatic printing of elements in show(io::IO,x::AbstractArray)
Yes, this is precisely the same issue that I had encountered (and opened an issue about... and then forgotten that I'd opened an issue about). On Tue, Jul 29, 2014 at 2:19 PM, Michael Grant m...@cvxr.com wrote: Thanks, but in fact imports/exports are not the problem here. I'm already importing show. It turns out that the real problem is that *show is not being used *in the scenario above; rather, writemime is. On Tuesday, July 29, 2014 11:31:23 AM UTC-5, g wrote: I'll quote another ongoing thread Yes; Base is *implicitly* imported, meaning that you can *use* any function in Base without having to *explicitly* import it. However, in order to *extend* the function with new methods, you do need to import it *explicitly* (using a statement like import Base.start, Base.next, Base.done or import Base: start, next, done). Otherwise, you’ll *shadow* the function in Base instead. So you can either import import import Base.show first, or change the method definition to Base.show(args...) =... I'm actually not sure how it will interact with your Array type vs Base.Array I feel like this is one of the most frequently asked questions on the list. That may be a sign that could use more discoverability.
Re: [julia-users] Re: Bypass automatic printing of elements in show(io::IO,x::AbstractArray)
You can check Images.jl, which defines a type Image : AbstractArray but prints
like this:
julia img = testimage(mandrill)
RGB Image with:
data: 3x512x512 Array{Uint8,3}
properties:
colorspace: RGB
colordim: 1
spatialorder: x y
limits: (0x00,0xff)
On Tuesday, July 29, 2014 11:17:15 AM Michael Grant wrote:
I've answered my own question here: the key, for now, is to overload
writemime. However, it doesn't seem that should be necessary, so I've
commented on an existing GitHub issue
https://github.com/JuliaLang/julia/issues/6117#issuecomment-50502411
about it.
The #undef issue is *not my problem. *I am not interested in printing the
values *at all.*
On Tuesday, July 29, 2014 11:08:06 AM UTC-5, Michael Grant wrote:
I have defined a subclass of AbstractArray for which I do *not* want to
use the default AbstractArray printing machinery in show.jl . My
assumption, apparently incorrect, is that I simply needed to overload
show.
Unfortunately, my overloaded version is never used.
Here is some sample code. Note two things:
- The code contained within a named module, and Base.Array is not
imported, so there is not a name conflict here.
- The function eleltype is indeed defined, and returns T. The actual
eltype of this array is Scalar{T}. But the data is not stored as a
contiguous memory buffer containing Scalar{T} objects; it has been
compressed in a certain way.
show(io::IO,x::Array) = print( io, CVX $(eleltype(x)) $(ndims(x))D Array
... )
show{T,N}(io::IO,::Type{Array{T,N}}) = print( io, CVX $(T) $(N)D Array )
show(io::IO,::Type{Array}) = print( io, CVX Array )
The last two lines work as expected, suggesting I'm indeed exporting if I
type CVX.Array or CVX.Array{Float64,2} into the REPL, my custom show
commands are called. But if I attempt to instantiate an instance, and show
that, it still calls the show.jl code; my overloaded version is ignored.
Here's what I get:
2x2 Array{Float64,2}:
#undef #undef
#undef #undef
And here is the output of an explicit call to show(A)
CVX Float64 2D Array ...
I tried modifying that first line as follows
show{T,N}(io::IO,x::Array{T,N}) = print( io, CVX $(T) $(N)D Array ... )
but that didn't make a difference. I tried different combinations of
import/export show as well. As you probably know I do have to import it,
but I don't have to export (at least, I don't think so), since I'm
overloading. I also tried overloading print as well.
Any hints? Thanks in advance for the help. I'm using Julia 0.3rc1 on the
Mac...
Re: [julia-users] Re: Bypass automatic printing of elements in show(io::IO,x::AbstractArray)
Yes indeed, your solution is exactly what I need to do: overload writemime
...
On Tuesday, July 29, 2014 1:33:00 PM UTC-5, Tim Holy wrote:
You can check Images.jl, which defines a type Image : AbstractArray but
prints
like this:
julia img = testimage(mandrill)
RGB Image with:
data: 3x512x512 Array{Uint8,3}
properties:
colorspace: RGB
colordim: 1
spatialorder: x y
limits: (0x00,0xff)
[julia-users] array doubling
MLBase.jl has som data repetition functionality: http://mlbasejl.readthedocs.org/en/latest/datapre.html#data-repetition
Re: [julia-users] packages that depend on unregistered packages (also: pkg REQUIRE allow urls)?
I'd also like to be able to require a URL. At the very least it will make for easier testing. But I think it will also simplify maintaining and using non-public packages.
[julia-users] Re: MethodError when passing a floating point argument through ccall
I can't believe it was that simple. Thank you so much!
On Monday, July 28, 2014 10:16:21 PM UTC-7, Ivar Nesje wrote:
It seems to me like the error is that you don't have a Julia method
results = gillespie (rr, 0)
that takes an Int as the second argument. the method you define only takes
a Float64, so you should probably call it with a Float64 as well.
results = gillespie (rr, 0.)
Also I would think that RRHandle would be pointer sized, so you should
use Ptr{Void} instead of Uint for its type.
Regards Ivar
kl. 03:24:36 UTC+2 tirsdag 29. juli 2014 skrev Alexander Darling følgende:
Hello,
I am in the process of making Julia functions that use functions in
C-exported libraries using ccall. One of the functions I am writing
throws errors when I try to include a double in the call. I think this is
because I'm using the wrong type instead of double (Float64) but I don't
know what the correct type is and I'm not 100% sure that's the problem.
This is the function in C:
C_DECL_SPEC RRDataHandle rrcCallConv gillespie(RRHandle handle, double
startTime) {
// Things happen here
return (RRDataHandle) r-getSimulationResult();
}
Here is my test code.
rrlib = dlopen(...\\roadrunner_c_api.dll) // the library that the
gillespie function is from
function gillespie(rr, startTime::Float64)
return ccall (dlsym (rrlib,:gillespie),cdecl, Uint,(Uint, Float64),rr,
startTime)
end
//The object rr is set up here
results = gillespie (rr, 0)
And this is the error that gets thrown. For context, The gillespie
function is called on line 106 and the rr object's memory address is
@0x23dc4c08.:
LoadError(.../myTest.jl, 106, MethodError(gillespie, (Ptr{Void} @
0x23dc4c08,0)))
When I modify the function in C and the middleman function in Julia so
that both only takes the rr argument and not startTime, it works fine.
In addition, the function works just fine in C with two arguments. I
suspect it's because the startTime in Julia is a Float64, and C requires
a double. However changing the startTime argument in the C function into
a float just gives me the same error.
[julia-users] a function for calling functions inside module
I'm trying to write a small module that allows one to define a Step that describes operations on an HDF5 file. immutable Step func::String a_ins::(String...) #attribute inputs d_ins::(String...) #dataset inputs a_outs::(String...) #attribute outputs d_outs::(String...) #dataset outputs end The idea is to gather up the inputs specified by a_ins and d_ins, pass them to the function specified by func, and place the outputs in HDF5 datasets and attributes as specified by a_outs and d_outs. The issues I'm having is finding the correct function given that it is defined in some other Module. A minimal example is given by module Bar bar(s::String, args...) = eval(parse(s))(args...) export bar end using Bar foo(s::String, args...) = eval(parse(s))(args...) baz(x...) = +(x...) baz(4,5,6) foo(baz,4,5,6) bar(baz,4,5,6) # ERROR: baz not defined One path I can see is that when I create the Step I could pass an actual function to the constructor. If I knew how to access the fully qualified name of the function, I could record that instead of just the name. I'm not sure if that is possible. Any ideas on how I should approach this? Also I probably shouldn't be using eval(parse(s)) since that opens up the opportunity for arbitrary code execution.
Re: [julia-users] Numerical types and machine word size
2014-07-29 13:10 GMT-03:00 Stefan Karpinski ste...@karpinski.org: Integer size is system-dependent while floating-point size is not. The 8087 https://en.wikipedia.org/wiki/Intel_8087 already had 64-bit floats and every x86 since the i486 https://en.wikipedia.org/wiki/Intel_80486 has too, so there's no reason to change the size of floating-point numbers on different systems. When you write 1.0 in Julia, it is always a Float64. Nice. Real is an abstract type that has many non-floating-point subtypes, including all integer types and rationals. Being a subtype of Real means, as the name suggests, that a type represents values on the real number line. There is a FloatingPoint abstract type, which is closer to what you're thinking of, but it also includes BigFloat. That is what I thought. But since Float64 is ubiquitous, why not the cleaner alias Float instead? It would improve readability by a little yet considerable amount, IMHO. The 64 in the symbol is boiler plate for most use cases. Júlio. P.S.: Why Julia users do not hang on IRC? Such trivial questions would be addressed instantly. I guess this mailing list is being misused as an IRC channel. (~54 emails per day).
Re: [julia-users] a function for calling functions inside module
In general, you should avoid using `eval`. Is there a reason you don't want to pass in a function and make it `func::Function` in your type? Your `eval` inside module `Bar` is evaluating the code inside the scope of `Bar`, which is what's causing your problem. -- Leah On Tue, Jul 29, 2014 at 3:58 PM, g galenon...@gmail.com wrote: I'm trying to write a small module that allows one to define a Step that describes operations on an HDF5 file. immutable Step func::String a_ins::(String...) #attribute inputs d_ins::(String...) #dataset inputs a_outs::(String...) #attribute outputs d_outs::(String...) #dataset outputs end The idea is to gather up the inputs specified by a_ins and d_ins, pass them to the function specified by func, and place the outputs in HDF5 datasets and attributes as specified by a_outs and d_outs. The issues I'm having is finding the correct function given that it is defined in some other Module. A minimal example is given by module Bar bar(s::String, args...) = eval(parse(s))(args...) export bar end using Bar foo(s::String, args...) = eval(parse(s))(args...) baz(x...) = +(x...) baz(4,5,6) foo(baz,4,5,6) bar(baz,4,5,6) # ERROR: baz not defined One path I can see is that when I create the Step I could pass an actual function to the constructor. If I knew how to access the fully qualified name of the function, I could record that instead of just the name. I'm not sure if that is possible. Any ideas on how I should approach this? Also I probably shouldn't be using eval(parse(s)) since that opens up the opportunity for arbitrary code execution.
[julia-users] help with improving performance of a matrix multiplication
Hi all, I've got an algorithm that hinges critically on fast matrix multiplication. I put up the function on this gist https://gist.github.com/floswald/6dea493417912536688d#file-tensor-jl-L45 indicating the line (45) that takes most of the time, as you can see in the profile output that is there as well. I am trying to figure out if I'm doing something wrong here or if that line just takes as long as it takes. I have to do this many times, so if this takes too long I have to change my strategy. The core of the problem looks like that for imat in 2:nbm v0= copy(v1) stemp = ibm[ks[imat]] n = size(stemp,1) m = nall / n for i in 1:m v1[m*(0:(n-1)) + i] = stemp * v0[(n*(i-1)) + (1:n)] end end where v are vectors and stemp is a matrix. I spend a lot of time in the matrix multiplication line on the innermost loop. Any suggestions would be much appreciated. Thanks!
[julia-users] Resize image to specific size
There's pretty cool package Images by Tim Holy (kudos, Tim!), but it seems to leak one standard and pretty helpful function - resizing image to specific size. There's restrict method (probably imported from Grid.jl), but it only reduces image size by 2 at each dimension. Are there any other options that work with arbitrary images sizes?
Re: [julia-users] Resize image to specific size
On Tuesday, July 29, 2014 02:30:55 PM Andrei Zh wrote: There's pretty cool package Images by Tim Holy (kudos, Tim!), ...and Ron, Kevin, Lucas, etc ... but it seems to leak one standard and pretty helpful function - resizing image to specific size. There's restrict method (probably imported from Grid.jl), but it only reduces image size by 2 at each dimension. Are there any other options that work with arbitrary images sizes? Yeah, it's a pretty obvious omission, but to be truthful it's never come up for me so I've never implemented it. I will get to it eventually, but in the meantime if you need it soon it might be worth considering putting something together yourself. If you use Grid to do it (+ smoothing with imfilter or imfilter_gaussian if you're downsizing and don't want aliasing), it shouldn't be more than 20 lines or so. But there are other approaches, see http://stackoverflow.com/questions/384991/what-is-the-best-image-downscaling-algorithm-quality-wise which might involve more effort but also yield higher quality/speed. BTW, the version of restrict in Images is actually considerably faster than the one in Grid. Sometime I plan to implement what should be an even faster version and put it back into Grid, but I haven't gotten around to it. --Tim
Re: [julia-users] Numerical types and machine word size
On Tue, Jul 29, 2014 at 5:19 PM, Júlio Hoffimann julio.hoffim...@gmail.com wrote: P.S.: Why Julia users do not hang on IRC? Such trivial questions would be addressed instantly. I guess this mailing list is being misused as an IRC channel. (~54 emails per day). Some do. Personally, I find IRC to be far too much of a continual distraction. Email I can answer when I want to. With IRC, there's also no record of the discussion, which would just mean having to answer the same questions more often. IRC might be quicker and more convenient for the people asking questions, but not for the people answering them.
[julia-users] Re: help with improving performance of a matrix multiplication
I had similar problem recently, and in my case solution was to: 1. Make sure that you use OpenBLAS and not other implementation: julia Base.blas_vendor() :openblas 2. Use mutable versions of BLAS matrix multiplication (e.g. A_mul_B! or more general gemm!) and thus not produce intermediate garbage. See my old thread [1] and referenced post [2] for more details. [1]: https://groups.google.com/forum/#!topic/julia-users/4_Nhs6yANwM [2]: http://julialang.org/blog/2013/09/fast-numeric/ On Wednesday, July 30, 2014 12:22:32 AM UTC+3, Florian Oswald wrote: Hi all, I've got an algorithm that hinges critically on fast matrix multiplication. I put up the function on this gist https://gist.github.com/floswald/6dea493417912536688d#file-tensor-jl-L45 indicating the line (45) that takes most of the time, as you can see in the profile output that is there as well. I am trying to figure out if I'm doing something wrong here or if that line just takes as long as it takes. I have to do this many times, so if this takes too long I have to change my strategy. The core of the problem looks like that for imat in 2:nbm v0= copy(v1) stemp = ibm[ks[imat]] n = size(stemp,1) m = nall / n for i in 1:m v1[m*(0:(n-1)) + i] = stemp * v0[(n*(i-1)) + (1:n)] end end where v are vectors and stemp is a matrix. I spend a lot of time in the matrix multiplication line on the innermost loop. Any suggestions would be much appreciated. Thanks!
[julia-users] Re: help with improving performance of a matrix multiplication
You may have to check which is the bottleneck: getindex or matrix multiplication. Dahua On Tuesday, July 29, 2014 4:22:32 PM UTC-5, Florian Oswald wrote: Hi all, I've got an algorithm that hinges critically on fast matrix multiplication. I put up the function on this gist https://gist.github.com/floswald/6dea493417912536688d#file-tensor-jl-L45 indicating the line (45) that takes most of the time, as you can see in the profile output that is there as well. I am trying to figure out if I'm doing something wrong here or if that line just takes as long as it takes. I have to do this many times, so if this takes too long I have to change my strategy. The core of the problem looks like that for imat in 2:nbm v0= copy(v1) stemp = ibm[ks[imat]] n = size(stemp,1) m = nall / n for i in 1:m v1[m*(0:(n-1)) + i] = stemp * v0[(n*(i-1)) + (1:n)] end end where v are vectors and stemp is a matrix. I spend a lot of time in the matrix multiplication line on the innermost loop. Any suggestions would be much appreciated. Thanks!
Re: [julia-users] Re: help with improving performance of a matrix multiplication
The right-hand slice makes a copy so you might want to just do this: v1[m*(0:(n-1)) + i] = stemp * v1[(n*(i-1)) + (1:n)] That way only one copy is made, implicitly, by the slice operation. On Tue, Jul 29, 2014 at 5:56 PM, Dahua Lin linda...@gmail.com wrote: You may have to check which is the bottleneck: getindex or matrix multiplication. Dahua On Tuesday, July 29, 2014 4:22:32 PM UTC-5, Florian Oswald wrote: Hi all, I've got an algorithm that hinges critically on fast matrix multiplication. I put up the function on this gist https://gist.github.com/floswald/6dea493417912536688d#file-tensor-jl-L45 indicating the line (45) that takes most of the time, as you can see in the profile output that is there as well. I am trying to figure out if I'm doing something wrong here or if that line just takes as long as it takes. I have to do this many times, so if this takes too long I have to change my strategy. The core of the problem looks like that for imat in 2:nbm v0= copy(v1) stemp = ibm[ks[imat]] n = size(stemp,1) m = nall / n for i in 1:m v1[m*(0:(n-1)) + i] = stemp * v0[(n*(i-1)) + (1:n)] end end where v are vectors and stemp is a matrix. I spend a lot of time in the matrix multiplication line on the innermost loop. Any suggestions would be much appreciated. Thanks!
Re: [julia-users] a function for calling functions inside module
Thanks for the comments. With a bit more digging I was able to figure out how to pass a module in which to look for the function, this finds the correct function and avoids eval. module Bar bar(s::String, args...;m::Module=Main) = getfield(m,symbol(s))(args...) export bar end using Bar foo(s::String, args...;m::Module=Main) = getfield(m,symbol(s))(args...) baz(x...) = +(x...) baz(4,5,6) foo(baz,4,5,6) bar(baz,4,5,6) I want to be able to write a Step object to disk, and recreate it with the correction function later. I see now how do that with func::Function, but I hadn't previously seen how to do that so I went with a String. On Tuesday, July 29, 2014 3:20:44 PM UTC-6, Leah Hanson wrote: In general, you should avoid using `eval`. Is there a reason you don't want to pass in a function and make it `func::Function` in your type? Your `eval` inside module `Bar` is evaluating the code inside the scope of `Bar`, which is what's causing your problem. -- Leah On Tue, Jul 29, 2014 at 3:58 PM, g galen...@gmail.com javascript: wrote: I'm trying to write a small module that allows one to define a Step that describes operations on an HDF5 file. immutable Step func::String a_ins::(String...) #attribute inputs d_ins::(String...) #dataset inputs a_outs::(String...) #attribute outputs d_outs::(String...) #dataset outputs end The idea is to gather up the inputs specified by a_ins and d_ins, pass them to the function specified by func, and place the outputs in HDF5 datasets and attributes as specified by a_outs and d_outs. The issues I'm having is finding the correct function given that it is defined in some other Module. A minimal example is given by module Bar bar(s::String, args...) = eval(parse(s))(args...) export bar end using Bar foo(s::String, args...) = eval(parse(s))(args...) baz(x...) = +(x...) baz(4,5,6) foo(baz,4,5,6) bar(baz,4,5,6) # ERROR: baz not defined One path I can see is that when I create the Step I could pass an actual function to the constructor. If I knew how to access the fully qualified name of the function, I could record that instead of just the name. I'm not sure if that is possible. Any ideas on how I should approach this? Also I probably shouldn't be using eval(parse(s)) since that opens up the opportunity for arbitrary code execution.
Re: [julia-users] Resize image to specific size
...and Ron, Kevin, Lucas, etc ... Surely, I'm just referring to someone I see on the mailing list very often :) Yeah, it's a pretty obvious omission, but to be truthful it's never come up for me so I've never implemented it. I will get to it eventually, but in the meantime if you need it soon it might be worth considering putting something together yourself. If you use Grid to do it (+ smoothing with imfilter or imfilter_gaussian if you're downsizing and don't want aliasing), it shouldn't be more than 20 lines or so. But there are other approaches, see http://stackoverflow.com/questions/384991/what-is-the-best-image-downscaling-algorithm-quality-wise which might involve more effort but also yield higher quality/speed. I'm not so concerned about high quality, so I think I will dive into your code and maybe come up with a general solution.
Re: [julia-users] Numerical types and machine word size
What would Float be an alias for? On Jul 29, 2014, at 6:09 PM, Júlio Hoffimann julio.hoffim...@gmail.com wrote: Some do. Personally, I find IRC to be far too much of a continual distraction. Email I can answer when I want to. With IRC, there's also no record of the discussion, which would just mean having to answer the same questions more often. IRC might be quicker and more convenient for the people asking questions, but not for the people answering them. I totally agree. On the other hand, having your inbox full of discussion is annoying. No one is forced to answer questions on IRC instantly, and I usually answer them during procrastination. If all users here come join us on IRC, it would be really great. Regarding the Float typealias, what do you think? Júlio.
Re: [julia-users] Numerical types and machine word size
I'm following the analogy for Int: if is(Int,Int64) typealias Float Float64 else typealias Float Float32 end User code would be cleaner: function foo(a::Float, b::Float) end vs. function bar(a::Float64, b::Float64) end Júlio.
Re: [julia-users] Numerical types and machine word size
This makes sense? Please correct me if I'm saying nonsense. Júlio.
Re: [julia-users] Numerical types and machine word size
Float would always be Float64. On Jul 29, 2014, at 6:25 PM, Júlio Hoffimann julio.hoffim...@gmail.com wrote: I'm following the analogy for Int: if is(Int,Int64) typealias Float Float64 else typealias Float Float32 end User code would be cleaner: function foo(a::Float, b::Float) end vs. function bar(a::Float64, b::Float64) end Júlio.
Re: [julia-users] Numerical types and machine word size
I think the confusion is that Julio assumes Int is used for brevity, when it is actually used for cross-platform compability. -- John On Jul 29, 2014, at 3:29 PM, Stefan Karpinski stefan.karpin...@gmail.com wrote: Float would always be Float64. On Jul 29, 2014, at 6:25 PM, Júlio Hoffimann julio.hoffim...@gmail.com wrote: I'm following the analogy for Int: if is(Int,Int64) typealias Float Float64 else typealias Float Float32 end User code would be cleaner: function foo(a::Float, b::Float) end vs. function bar(a::Float64, b::Float64) end Júlio.
Re: [julia-users] Numerical types and machine word size
2014-07-29 19:32 GMT-03:00 John Myles White johnmyleswh...@gmail.com: I think the confusion is that Julio assumes Int is used for brevity, when it is actually used for cross-platform compability. -- John Yes, I assumed the Int alias had these two goals: brevity + portability. I still think a cleaner Float alias would be useful to avoid typing 64 everywhere. Júlio.
Re: [julia-users] Numerical types and machine word size
One of the things I like about the Julia community is a broad preference for clarity over brevity. Think of it as the opposite of the Perl culture. In this case, Float would be less, rather than more, clear because our Float would describe a type that most languages would call Double. -- John On Jul 29, 2014, at 3:45 PM, Júlio Hoffimann julio.hoffim...@gmail.com wrote: 2014-07-29 19:32 GMT-03:00 John Myles White johnmyleswh...@gmail.com: I think the confusion is that Julio assumes Int is used for brevity, when it is actually used for cross-platform compability. -- John Yes, I assumed the Int alias had these two goals: brevity + portability. I still think a cleaner Float alias would be useful to avoid typing 64 everywhere. Júlio.
[julia-users] help with improving performance of a matrix multiplication
From the profile output it looks like a lot of time is spent in getindex. I suppose that is bad news? Not sure how I could avoid any of the index lookups. On Tuesday, 29 July 2014, Dahua Lin linda...@gmail.com javascript:_e(%7B%7D,'cvml','linda...@gmail.com'); wrote: You may have to check which is the bottleneck: getindex or matrix multiplication. Dahua On Tuesday, July 29, 2014 4:22:32 PM UTC-5, Florian Oswald wrote: Hi all, I've got an algorithm that hinges critically on fast matrix multiplication. I put up the function on this gist https://gist.github.com/floswald/6dea493417912536688d#file-tensor-jl-L45 indicating the line (45) that takes most of the time, as you can see in the profile output that is there as well. I am trying to figure out if I'm doing something wrong here or if that line just takes as long as it takes. I have to do this many times, so if this takes too long I have to change my strategy. The core of the problem looks like that for imat in 2:nbm v0= copy(v1) stemp = ibm[ks[imat]] n = size(stemp,1) m = nall / n for i in 1:m v1[m*(0:(n-1)) + i] = stemp * v0[(n*(i-1)) + (1:n)] end end where v are vectors and stemp is a matrix. I spend a lot of time in the matrix multiplication line on the innermost loop. Any suggestions would be much appreciated. Thanks!
Re: [julia-users] Numerical types and machine word size
2014-07-29 19:50 GMT-03:00 John Myles White johnmyleswh...@gmail.com: In this case, Float would be less, rather than more, clear because our Float would describe a type that most languages would call Double. In my humble opinion we can call it Float without confusion and forget about other languages naming conventions (i.e. double). This is up to you, but to me Float is quite clear, it's the default floating point type. And except for graphics stuff (my limited view of science), no one needs such distinction between Float32 and Float64. Júlio.
Re: [julia-users] Numerical types and machine word size
Yes, Float is a bad name for Float64 since anyone coming from C or Fortran would expect Float = Float32 and Double = Float64. If you're writing Float64 a lot I think you may be over constraining your type signatures. Most algorithms that make sense for Float64 also make sense for Float32 and BigFloat and possibly also for integers and rationals, maybe all real number representations. Unless you very specifically need a 64-bit float for your code to work, why restrict it more than necessary? And if you really need a 64-bit float – not a 32-bit one or a 256-bit one – then it seems quite fitting to have 64 in the type signature. On Jul 29, 2014, at 6:50 PM, John Myles White johnmyleswh...@gmail.com wrote: One of the things I like about the Julia community is a broad preference for clarity over brevity. Think of it as the opposite of the Perl culture. In this case, Float would be less, rather than more, clear because our Float would describe a type that most languages would call Double. -- John On Jul 29, 2014, at 3:45 PM, Júlio Hoffimann julio.hoffim...@gmail.com wrote: 2014-07-29 19:32 GMT-03:00 John Myles White johnmyleswh...@gmail.com: I think the confusion is that Julio assumes Int is used for brevity, when it is actually used for cross-platform compability. -- John Yes, I assumed the Int alias had these two goals: brevity + portability. I still think a cleaner Float alias would be useful to avoid typing 64 everywhere. Júlio.
[julia-users] Trouble with BoundsError()
Hi Julia users, There are a number of things wrong with this script that I am working on, but for the time being, I am trying to resolve a BoundsError() triggered while slicing an array. Code is attached. The source of the BoundsError() appears to be this function. function spikecounter(Varray) #spiketimes = Int64[] Varraycut = splice!(Varray,1:spliceend) spikecount = 0 for i in Int64[1:len(Varraycut)] if Varraycut[i] = 0 Varraycut[i-1] 0 #= push!(spiketimes,i) other option of counting spikes is to append spiketimes to an array, and then count length of array =# spikecount += 1 end end return spikecount end Because of other errors in my code, Varray usually contains NaN entries. However, these NaN entries are still appending into my arrays, and I was thinking that if these entries exist, it should still be possible to splice the array. Do these NaN entries preclude Varray from being spliced? This is the exact error: ERROR: BoundsError() in getindex at array.jl:246 in spikecounter at /Users/xieh/Dropbox/spiking/j2test.jl:204 in moldakarimov at /Users/xieh/Dropbox/spiking/j2test.jl:223 in calcchi at /Users/xieh/Dropbox/spiking/j2test.jl:306 in mcmc at /Users/xieh/Dropbox/spiking/j2test.jl:319 while loading /Users/xieh/Dropbox/spiking/j2test.jl, in expression starting on line 365 Thanks, Wally
Re: [julia-users] Numerical types and machine word size
Ignoring other languages people are likely to be used to is not really the Julian way. People come from various language backgrounds and we'd like to make using Julia as comfortable for as many people as possible, if the cost is not too great. It's quite likely that many people will be working in both Julia and C quite a bit (I do this a lot). Inverting the meanings of a basic C type is just confusing. On Jul 29, 2014, at 7:03 PM, Júlio Hoffimann julio.hoffim...@gmail.com wrote: 2014-07-29 19:50 GMT-03:00 John Myles White johnmyleswh...@gmail.com: In this case, Float would be less, rather than more, clear because our Float would describe a type that most languages would call Double. In my humble opinion we can call it Float without confusion and forget about other languages naming conventions (i.e. double). This is up to you, but to me Float is quite clear, it's the default floating point type. And except for graphics stuff (my limited view of science), no one needs such distinction between Float32 and Float64. Júlio.
Re: [julia-users] Numerical types and machine word size
If only Float exists in Julia, then there is no door for confusion with Double. A user coming from a C background will soon notice that Float is the type he is looking for. Furthermore, a simple short note on the manual is enough to make it even clearer. Júlio.
Re: [julia-users] Delete function
Thank you Stefan Karpinski. 2014-07-26 21:37 GMT-03:00 Stefan Karpinski stefan.karpin...@gmail.com: It's technically quite difficult. Related to issue #265. On Jul 26, 2014, at 7:55 PM, Pedro Rafael pedro.rafael.mari...@gmail.com wrote: What I mean by the second question is: For what reasons julia does not have functions to delete a function or objects? There is some technical reason or simply such functions do not yet exist? Thank you very much for the replies. 2014-07-26 20:04 GMT-03:00 Kevin Squire kevin.squ...@gmail.com: If I read the original question correctly, a simple translation might be if not, why not? Cheers, Kevin On Saturday, July 26, 2014, Stefan Karpinski stefan.karpin...@gmail.com wrote: There is not. I don't really understand the second question. On Jul 26, 2014, at 4:52 PM, Pedro Rafael pedro.rafael.mari...@gmail.com wrote: Is there any way to delete a function definition? If not, what is the advantage of such a definition does not exist? Pedro.
Re: [julia-users] Numerical types and machine word size
I think you're assuming people's beliefs about programming languages are simpler to modify than they've proven to be in our experience. Here's an experiment you could try to see if I'm right: over the course of six months, reply to every e-mail you see on julia-users that derives from a misunderstanding of the manual. My hypothesis is that you'll find very early on in your experiment that short notes in the manual are almost never sufficient to prevent confusion. For example, there are many different notes in the manual about why you shouldn't do any programming in the global scope, but we get e-mails about performance in the global scope at least once a week from users that haven't understood that section of the manual. I contend that the name Float would have a similar effect. -- John On Jul 29, 2014, at 4:24 PM, Júlio Hoffimann julio.hoffim...@gmail.com wrote: If only Float exists in Julia, then there is no door for confusion with Double. A user coming from a C background will soon notice that Float is the type he is looking for. Furthermore, a simple short note on the manual is enough to make it even clearer. Júlio.
Re: [julia-users] Numerical types and machine word size
Except that we already have Int != int, which becomes unfortunate when first trying to write code for c-interop. (I don't see adding a Float alias as particularly helpful -- and we do have Cfloat, if someone feels the need to be pedantic/consistent in their ccall and type structs.) On Tuesday, July 29, 2014, Stefan Karpinski stefan.karpin...@gmail.com wrote: Yes, Float is a bad name for Float64 since anyone coming from C or Fortran would expect Float = Float32 and Double = Float64. If you're writing Float64 a lot I think you may be over constraining your type signatures. Most algorithms that make sense for Float64 also make sense for Float32 and BigFloat and possibly also for integers and rationals, maybe all real number representations. Unless you very specifically need a 64-bit float for your code to work, why restrict it more than necessary? And if you really need a 64-bit float – not a 32-bit one or a 256-bit one – then it seems quite fitting to have 64 in the type signature. On Jul 29, 2014, at 6:50 PM, John Myles White johnmyleswh...@gmail.com javascript:_e(%7B%7D,'cvml','johnmyleswh...@gmail.com'); wrote: One of the things I like about the Julia community is a broad preference for clarity over brevity. Think of it as the opposite of the Perl culture. In this case, Float would be less, rather than more, clear because our Float would describe a type that most languages would call Double. -- John On Jul 29, 2014, at 3:45 PM, Júlio Hoffimann julio.hoffim...@gmail.com javascript:_e(%7B%7D,'cvml','julio.hoffim...@gmail.com'); wrote: 2014-07-29 19:32 GMT-03:00 John Myles White johnmyleswh...@gmail.com javascript:_e(%7B%7D,'cvml','johnmyleswh...@gmail.com');: I think the confusion is that Julio assumes Int is used for brevity, when it is actually used for cross-platform compability. -- John Yes, I assumed the Int alias had these two goals: brevity + portability. I still think a cleaner Float alias would be useful to avoid typing 64 everywhere. Júlio.
Re: [julia-users] help with improving performance of a matrix multiplication
You may call gemv directly. Dahua On Tuesday, July 29, 2014 5:56:28 PM UTC-5, Florian Oswald wrote: From the profile output it looks like a lot of time is spent in getindex. I suppose that is bad news? Not sure how I could avoid any of the index lookups. On Tuesday, 29 July 2014, Dahua Lin linda...@gmail.com wrote: You may have to check which is the bottleneck: getindex or matrix multiplication. Dahua On Tuesday, July 29, 2014 4:22:32 PM UTC-5, Florian Oswald wrote: Hi all, I've got an algorithm that hinges critically on fast matrix multiplication. I put up the function on this gist https://gist.github.com/floswald/6dea493417912536688d#file-tensor-jl-L45 indicating the line (45) that takes most of the time, as you can see in the profile output that is there as well. I am trying to figure out if I'm doing something wrong here or if that line just takes as long as it takes. I have to do this many times, so if this takes too long I have to change my strategy. The core of the problem looks like that for imat in 2:nbm v0= copy(v1) stemp = ibm[ks[imat]] n = size(stemp,1) m = nall / n for i in 1:m v1[m*(0:(n-1)) + i] = stemp * v0[(n*(i-1)) + (1:n)] end end where v are vectors and stemp is a matrix. I spend a lot of time in the matrix multiplication line on the innermost loop. Any suggestions would be much appreciated. Thanks!
[julia-users] Re: help with improving performance of a matrix multiplication
Look more carefully into the pattern of your codes. It seems that you may be able to reshape v1 into a matrix of size (m, n) and v0 into a matrix of size (n, m), and you may do a matrix-matrix multiplication once without looping over multiple strided vectors. Also, if you are using ArrayViews, you can write view(v0, n*(i-1)+1:n*i) instead of v0[(n * (i-1)) + (1:n)]. Dahua On Tuesday, July 29, 2014 4:22:32 PM UTC-5, Florian Oswald wrote: Hi all, I've got an algorithm that hinges critically on fast matrix multiplication. I put up the function on this gist https://gist.github.com/floswald/6dea493417912536688d#file-tensor-jl-L45 indicating the line (45) that takes most of the time, as you can see in the profile output that is there as well. I am trying to figure out if I'm doing something wrong here or if that line just takes as long as it takes. I have to do this many times, so if this takes too long I have to change my strategy. The core of the problem looks like that for imat in 2:nbm v0= copy(v1) stemp = ibm[ks[imat]] n = size(stemp,1) m = nall / n for i in 1:m v1[m*(0:(n-1)) + i] = stemp * v0[(n*(i-1)) + (1:n)] end end where v are vectors and stemp is a matrix. I spend a lot of time in the matrix multiplication line on the innermost loop. Any suggestions would be much appreciated. Thanks!
Re: [julia-users] Numerical types and machine word size
While 3D graphics packages are still in early development for Julia, I believe that community uses 32 bit floats almost exclusively, probably because of bandwidth constraints to the GPU (but someone with more knowledge should correct me). Cheers, Kevin On Tuesday, July 29, 2014, Júlio Hoffimann julio.hoffim...@gmail.com wrote: 2014-07-29 19:32 GMT-03:00 John Myles White johnmyleswh...@gmail.com javascript:_e(%7B%7D,'cvml','johnmyleswh...@gmail.com');: I think the confusion is that Julio assumes Int is used for brevity, when it is actually used for cross-platform compability. -- John Yes, I assumed the Int alias had these two goals: brevity + portability. I still think a cleaner Float alias would be useful to avoid typing 64 everywhere. Júlio.
[julia-users] Re: questions about the format of function arguments in the documentation
Thanks, Ivar! I will review this thread. I wish the documentation alert readers that [, a,b,...] mean optional parameters.
Re: [julia-users] Numerical types and machine word size
There were also architectural problems related to SIMD width (I think) on most GPU designs until fairly recently, causing operations on 64-bit doubles to be significantly more than 2x slower than 32-bit singles. This is not so much the case any more, but old habits die hard and if single precision is good enough, then you still do get a factor of roughly 2 benefit in throughput on modern GPU's. There are examples in games (anyone here ever play Kerbal Space Program?) where ingrained habits of single precision have caused noticeable problems. On Tuesday, July 29, 2014 7:22:08 PM UTC-7, Kevin Squire wrote: While 3D graphics packages are still in early development for Julia, I believe that community uses 32 bit floats almost exclusively, probably because of bandwidth constraints to the GPU (but someone with more knowledge should correct me). Cheers, Kevin On Tuesday, July 29, 2014, Júlio Hoffimann julio.h...@gmail.com javascript: wrote: 2014-07-29 19:32 GMT-03:00 John Myles White johnmyleswh...@gmail.com: I think the confusion is that Julio assumes Int is used for brevity, when it is actually used for cross-platform compability. -- John Yes, I assumed the Int alias had these two goals: brevity + portability. I still think a cleaner Float alias would be useful to avoid typing 64 everywhere. Júlio.
