Re: [julia-users] shared array of user defined type
Thank you Mauro. If I understand correctly, this means that in SharedArrays I cannot use immutable types whose fields contain arrays. Is that right? Thanks a lot, Alex On Friday, October 14, 2016 at 1:57:42 AM UTC-5, Mauro wrote: > > On Fri, 2016-10-14 at 00:02, Alexandros Fakos <alexand...@gmail.com > > wrote: > > Hi, > > > > Is there a way to create a shared array of a user defined composite > > type? > > Yes, but only for isbits types, i.e. immutables which do not contain > non-immutable fields. Otherwise you could look into the new & > experimental threads support in 0.5. > > > I want to parallelize using pmap() on a function f() which has as > > arguments user defined composite types. >
[julia-users] shared array of user defined type
Hi, Is there a way to create a shared array of a user defined composite type? I want to parallelize using pmap() on a function f() which has as arguments user defined composite types. Thanks, Alex
[julia-users] newest stable version of julia on EC2 AWS instances - starcluster
Hi, I am trying to run julia in parallel on EC2 AWS. I use the starcluster package to create a cluster of instances. The problem is that the instances have already installed the 0.3.0 prerelease. I log in the starcluster master node and use the instructions from http://julialang.org/downloads/platform.html sudo add-apt-repository ppa:staticfloat/juliareleases sudo add-apt-repository ppa:staticfloat/julia-deps sudo apt-get update (this command is giving me errors: W:Failed to fetch http://us-west-1.ec2.archive.ubuntu.com/ubuntu/distrs/raring etc. and other similar messages) sudo apt-get install julia Unfortunately, when I type julia in the terminal the 0.3.0 prerelease comes up. Note that in my regular EC2 instance the above commands work and install julia 0.4.6 As a general question, how can I launch instances with the latest stable version of julia preinstalled? If I cannot do that, how can I install the latest version of julia in all my cluster nodes? Thanks a lot, Alex
[julia-users] Re: whole arrays pass by reference while matrix columns by value?
thank you all for your helpful suggestions! alex On Wednesday, September 7, 2016 at 7:00:00 PM UTC-5, Alexandros Fakos wrote: > > Hi, > > a=rand(10,2) > b=rand(10) > sort!(b) modifies b > but sort!(a[:,1]) does not modify the first column of matrix a > > why is that? Does this mean that i cannot write functions that modify > their arguments and apply it to columns of matrices? > > Is trying to modify columns of matrices bad programming style? Is there a > better alternative? > How much more memory am I allocating if my functions return output > instead of modifying their arguments (matlab background - I am completely > unaware of memory allocation issues)? > > Thanks, > Alex >
[julia-users] whole arrays pass by reference while matrix columns by value?
Hi, a=rand(10,2) b=rand(10) sort!(b) modifies b but sort!(a[:,1]) does not modify the first column of matrix a why is that? Does this mean that i cannot write functions that modify their arguments and apply it to columns of matrices? Is trying to modify columns of matrices bad programming style? Is there a better alternative? How much more memory am I allocating if my functions return output instead of modifying their arguments (matlab background - I am completely unaware of memory allocation issues)? Thanks, Alex
[julia-users] Re: Question about how to use uninitialized fields for Composite type
Thanks Toivo, Best, Alex On Friday, May 8, 2015 at 4:55:38 AM UTC-4, Toivo Henningsson wrote: You can also use whichever order you want if you create the new instance with just new() in the constructor and then fill in all the fields that you want just after.
[julia-users] Re: Question about how to use uninitialized fields for Composite type
If I don't want to leave fields uninitialized what is the easiest and most
correct way to initialize them? Put them all zero with an inner constructor?
Thanks a lot,
Alex
On Thursday, May 7, 2015 at 12:56:35 PM UTC-4, Alexandros Fakos wrote:
Andrew,
I found your suggestion very helpful. However, it seems complicated to
place uninitialized fields last. Why is this? The field have names and when
calling *new() *you are using these names.
For example:
*julia type foo*
* a :: Int64*
* b :: Int64*
* function foo()*
* b=3*
* return new(b)*
* end*
* end*
*julia var = foo()*
*foo(3,0)*
*julia xdump(var)*
*foo *
* a: Int64 3*
* b: Int64 0*
Even if I ask b to be initialized, a is initialized instead. Why is this?
On Sunday, April 20, 2014 at 10:51:29 AM UTC-4, andrew cooke wrote:
yes, you can do this. just place those fields last and use an internal
constructor to define everything else.
its described at
http://julia.readthedocs.org/en/latest/manual/constructors/#incomplete-initialization
(types are so important in julia that the info is in several chapters - you
need to read the types and the constructors chapters to get a good
understanding).
andrew
On Saturday, 19 April 2014 21:50:05 UTC-3, Spencer Lyon wrote:
Say I have a type that defines a model. Something like this:
abstract Model
type Results
# Details not shown here
end
type IFP{T : FloatingPoint} : Model
# Model parameters
rho::T
beta::T
r::T
R::T
gamma::T
# Grid parameters for a
n_a::Integer
a_max::T
a::Vector{T}
# Parameters for y
n_y::Integer
y::Vector{T}
P::Matrix{T}
Sol::Results
end
I would like to be able to initialize an object of type IFP, work with
it for a while, pass it to a solution routine, and then fill in the Sol
field at a later time.
Is there a way to leave Sol as an uninitialized field and then fill it
in after the solution has been determined (which will be after constructing
the IFP object and playing around with it for a while)? I suppose one
way would be to have the inner constructor directly call the solution
routine to get the Sol object. However, I want to avoid that because I
may want to manipulate IFP between its construction and actually
solving the model it describes.
--
One more note. In this specific use case Sol could effectively be
replaced by two other fields:
c::Matrix{T}
ap::Matrix{T}
Would that be an easier way to work with them as uninitialized fields?
If so, why?
[julia-users] Re: Question about how to use uninitialized fields for Composite type
Thanks a lot Spencer,
So when I create a type I should first think which fields are going to be
initialized in the constructor. It makes sense.
Best,
Alex
On Thursday, May 7, 2015 at 4:17:20 PM UTC-4, Spencer Lyon wrote:
Uninitialized fields need to be declared last because the way you
construct an incompletely initialized type is to call `new` with less than
the total number of fields. Then, elsewhere (preferably via a function call
later in the constructor) you will fill in the fields that didn't make it
into `new`.
Your question about why `a` was given the value `3` instead of `b` in your
example is a confusion about how he `new` function works. The `new`
function takes only *positional* arguments, not *keyword* arguments. This
means that no matter what the variable is named locally when you call `new`
from an inner constructor, the first argument to `new` will always fill in
the value for the first field listed when you declared all the types on the
field. In your example you assigned `b=3`locally in the function, then
passed `b` as the first argument to `new` which made assigned it to be the
value of the first field in your type (the `a` field).
So to me, this comment:
it seems complicated to place uninitialized fields last. Why is this?
The field have names and when calling *new() *you are using these names
is actually more salient in reverse: you list the fields in the order you
create them within a constructor, then whenever you are actually using the
type (e.g. not in the constructor) you (most commonly) refer to fields by
name so the order in which they were declared doesn't matter.
On Thursday, May 7, 2015 at 2:04:36 PM UTC-4, Alexandros Fakos wrote:
If I don't want to leave fields uninitialized what is the easiest and
most correct way to initialize them? Put them all zero with an inner
constructor?
Thanks a lot,
Alex
On Thursday, May 7, 2015 at 12:56:35 PM UTC-4, Alexandros Fakos wrote:
Andrew,
I found your suggestion very helpful. However, it seems complicated to
place uninitialized fields last. Why is this? The field have names and when
calling *new() *you are using these names.
For example:
*julia type foo*
* a :: Int64*
* b :: Int64*
* function foo()*
* b=3*
* return new(b)*
* end*
* end*
*julia var = foo()*
*foo(3,0)*
*julia xdump(var)*
*foo *
* a: Int64 3*
* b: Int64 0*
Even if I ask b to be initialized, a is initialized instead. Why is
this?
On Sunday, April 20, 2014 at 10:51:29 AM UTC-4, andrew cooke wrote:
yes, you can do this. just place those fields last and use an internal
constructor to define everything else.
its described at
http://julia.readthedocs.org/en/latest/manual/constructors/#incomplete-initialization
(types are so important in julia that the info is in several chapters -
you
need to read the types and the constructors chapters to get a good
understanding).
andrew
On Saturday, 19 April 2014 21:50:05 UTC-3, Spencer Lyon wrote:
Say I have a type that defines a model. Something like this:
abstract Model
type Results
# Details not shown here
end
type IFP{T : FloatingPoint} : Model
# Model parameters
rho::T
beta::T
r::T
R::T
gamma::T
# Grid parameters for a
n_a::Integer
a_max::T
a::Vector{T}
# Parameters for y
n_y::Integer
y::Vector{T}
P::Matrix{T}
Sol::Results
end
I would like to be able to initialize an object of type IFP, work with
it for a while, pass it to a solution routine, and then fill in the
Sol field at a later time.
Is there a way to leave Sol as an uninitialized field and then fill
it in after the solution has been determined (which will be after
constructing the IFP object and playing around with it for a while)?
I suppose one way would be to have the inner constructor directly call
the
solution routine to get the Sol object. However, I want to avoid that
because I may want to manipulate IFP between its construction and
actually solving the model it describes.
--
One more note. In this specific use case Sol could effectively be
replaced by two other fields:
c::Matrix{T}
ap::Matrix{T}
Would that be an easier way to work with them as uninitialized fields?
If so, why?
Re: [julia-users] Asking for generic-data-type definition advice
Thank you all so much! All your comments were really helpful !
Best,
Alex
On Thursday, May 7, 2015 at 5:52:39 AM UTC-4, Tim Holy wrote:
See also
http://docs.julialang.org/en/release-0.3/manual/faq/#how-do-abstract-or-ambiguous-fields-in-types-interact-with-the-compiler
--Tim
On Wednesday, May 06, 2015 11:20:30 PM Kevin Squire wrote:
To add a little detail to Mauro's response:
The overly-specific types suggestion really applies to functions, not
types. That is because a different version of every function is
generated
based on the types of the arguments (as described at the end of the
section
you linked to). The main reason to add type annotations to functions is
to
restrict the types of the parameters, which can sometimes be useful, but
is
often unnecessary (and as described in that link, can make for less
generic
code).
I'll give my answers your questions below, but if you haven't done so
yet,
I would suggest a long read through the manual to help understand these
issues.
*Questions*
*1)* Is there any reason to define fieldtypes instead leaving fields
with
no type annotation?
Any field of a type which itself does not have a concrete type will be
boxed--essentially, stored as a pointer with type information. That
makes it very difficult to generate fast code for compound objects of
this
type, because the compiler doesn't know the type of that field a compile
time, and unlike functions, it doesn't automatically specialize the type
based on the field types.
So, it will always work, but without concrete types for the fields, the
compiler always has to generate extra code to check the type of the
field,
and then generate code which will do the right thing for the discovered
type. Whereas, with typed fields, the compiler knows the type of the
field
at compile time, and can compile fast code immediately.
*2) *How much performance do I sacrifice by defining a field as
*Any*
instead
of *Array *or instead of Array{Float64,2} or Array{Number,2}?
For functions, nothing. For types, see the answer to 1 above. A real
answer depends on what you want to do, and could range from not much
effect (e.g., if you're working with a struct defining a GUI interface)
to
won't work at all (e.g., if you're trying to call a BLAS function on
an
Array{Number,2})
*3)* suppose I define:
type Mytype
a:: Array{Number,1}
b:: Array
c
end
then I create an object by
*var=Mytype( [1;2] , [1;2], [1;2] )*
julia typeof(var.a)
Array{Number,1}
julia typeof(var.b)
Array{Int64,1}
julia typeof(var.c)
Array{Int64,1}
Why field a is Array{Number,1} while b and c is Array{Int64,1} ?
Isn't
Number generic enough to be turned into Int64?
First, to repeat what I said above, functions are specialized based on
the
types of their arguments, but types are not--they are only specialized
if
the type is parameterized
http://julia.readthedocs.org/en/latest/manual/types/#man-parametric-types)
!
Given that, the types of the fields of Mytype as you defined it are
always
julia Mytype.types
(Array{Number,1},Array{T,N},Any)
where
- Array{Number,1} is a concrete type with abstract elements.
- Array === Array{T,N} is an abstract type
- Any is also an abstract type.
So, val.a has to have the concrete type Array{Number,1}, and val.b and
val.c
must be values with types which are subtypes of Array and Any
respectively.
It's also useful to know that, when you construct a type, Julia converts
the parameters to the correct type, if necessary. For var.b and var.c,
no
conversion is necessary, since typeof([1;2]) == Array{Int64,1} is a
subtype
of both Array{T,N} and Any (in Julia).
julia typeof([1;2])
Array{Int64,1}
julia Array{Int64,1} : Array
true
However for the first field, Array{Int64,1} is *not* a subtype of
Array{Number,1}:
julia Array{Int64,1} : Array{Number,1}
false
So [1;2] is converted to an Array{Number,1}, and then stored. (For this
last point, see
http://julia.readthedocs.org/en/release-0.3/manual/types/#parametric-composi
te-types )
If any of this is confusing (and it quite probably is), I recommend
reading
the Julia manual section on types
http://julia.readthedocs.org/en/release-0.3/manual/types/, as well
as the Wikipedia
article on Covariance and Contravariance
http://en.wikipedia.org/wiki/Covariance_and_contravariance_%28computer_scie
nce%29 .
Moral: you should almost always give fields concrete types (with
concrete
subtypes), and for more flexibility, you can use parameterized types.
Cheers,
Kevin
[julia-users] Re: Question about how to use uninitialized fields for Composite type
Andrew,
I found your suggestion very helpful. However, it seems complicated to
place uninitialized fields last. Why is this? The field have names and when
calling *new() *you are using these names.
For example:
*julia type foo*
* a :: Int64*
* b :: Int64*
* function foo()*
* b=3*
* return new(b)*
* end*
* end*
*julia var = foo()*
*foo(3,0)*
*julia xdump(var)*
*foo *
* a: Int64 3*
* b: Int64 0*
Even if I ask b to be initialized, a is initialized instead. Why is this?
On Sunday, April 20, 2014 at 10:51:29 AM UTC-4, andrew cooke wrote:
yes, you can do this. just place those fields last and use an internal
constructor to define everything else.
its described at
http://julia.readthedocs.org/en/latest/manual/constructors/#incomplete-initialization
(types are so important in julia that the info is in several chapters - you
need to read the types and the constructors chapters to get a good
understanding).
andrew
On Saturday, 19 April 2014 21:50:05 UTC-3, Spencer Lyon wrote:
Say I have a type that defines a model. Something like this:
abstract Model
type Results
# Details not shown here
end
type IFP{T : FloatingPoint} : Model
# Model parameters
rho::T
beta::T
r::T
R::T
gamma::T
# Grid parameters for a
n_a::Integer
a_max::T
a::Vector{T}
# Parameters for y
n_y::Integer
y::Vector{T}
P::Matrix{T}
Sol::Results
end
I would like to be able to initialize an object of type IFP, work with it
for a while, pass it to a solution routine, and then fill in the Sol
field at a later time.
Is there a way to leave Sol as an uninitialized field and then fill it
in after the solution has been determined (which will be after constructing
the IFP object and playing around with it for a while)? I suppose one
way would be to have the inner constructor directly call the solution
routine to get the Sol object. However, I want to avoid that because I
may want to manipulate IFP between its construction and actually solving
the model it describes.
--
One more note. In this specific use case Sol could effectively be
replaced by two other fields:
c::Matrix{T}
ap::Matrix{T}
Would that be an easier way to work with them as uninitialized fields? If
so, why?
[julia-users] show fields of a variable of a composite type
Hi,
Suppose I have
type dat
a :: Array{Float64,1}
b :: Float64
end
and variable *data *of type *dat*
is there a function that prints out the fields of *data* with some
information about each field?
Thanks a lot,
Alex
[julia-users] Re: show fields of a variable of a composite type
Thanks a lot Simon! xdump works.
Do the other functions require some package to be installed? I am running
julia 0.3.6 and the command
*fieldnames(data) * gives
*ERROR: fieldnames not defined*
On Wednesday, May 6, 2015 at 10:35:59 AM UTC-4, Simon Danisch wrote:
Checkout:
xdump(data)
fieldnames(data)
fieldnames(dat)
fieldtype(data, :a)
Best,
Simon
Am Mittwoch, 6. Mai 2015 16:27:24 UTC+2 schrieb Alexandros Fakos:
Hi,
Suppose I have
type dat
a :: Array{Float64,1}
b :: Float64
end
and variable *data *of type *dat*
is there a function that prints out the fields of *data* with some
information about each field?
Thanks a lot,
Alex
[julia-users] Asking for generic-data-type definition advice
Hi,
Reading the Julia style guide I see avoid writing overly-specific types
http://julia.readthedocs.org/en/latest/manual/style-guide/#avoid-writing-overly-specific-types
*The main reason I use composite types is in order to aggregate variables
and avoid variable name conflicts (the same reason I use structures in
Matlab)*.
So when I define a data type, I usually define the fieldtypes as* Any or
Array* or *Number* or *Integer *
*Questions*
*1)* Is there any reason to define fieldtypes instead leaving fields with
no type annotation?
*2) *How much performance do I sacrifice by defining a field as *Any* instead
of *Array *or instead of Array{Float64,2} or Array{Number,2}?
*3)* suppose I define:
type Mytype
a:: Array{Number,1}
b:: Array
c
end
then I create an object by
*var=Mytype( [1;2] , [1;2], [1;2] )*
julia typeof(var.a)
Array{Number,1}
julia typeof(var.b)
Array{Int64,1}
julia typeof(var.c)
Array{Int64,1}
Why field a is Array{Number,1} while b and c is Array{Int64,1} ? Isn't
Number generic enough to be turned into Int64?
Thanks a lot,
Alex
[julia-users] Re: show fields of a variable of a composite type
Great! now it works. Thanks a lot,
Alex
On Wednesday, May 6, 2015 at 11:07:02 AM UTC-4, Simon Danisch wrote:
Ah yeah it was renamed in 0.4.
Its just names(...) in 0.3...
Am Mittwoch, 6. Mai 2015 16:27:24 UTC+2 schrieb Alexandros Fakos:
Hi,
Suppose I have
type dat
a :: Array{Float64,1}
b :: Float64
end
and variable *data *of type *dat*
is there a function that prints out the fields of *data* with some
information about each field?
Thanks a lot,
Alex
[julia-users] using variables from the workspace to define JuMP problem
Hi,
z is a variable in the workspace
Ideally I would like to define variable x for the optimization problem like:
@defVar(m, x[ 1 : length(z) ] = z )
which gives the error
ERROR: `Variable` has no method matching Variable(::Model,
::Array{Float64,1}, ::Float64, ::Symbol, ::ASCIIString, ::Float64)
in anonymous at julia/v0.3/JuMP/src/macros.jl:81
Is there any way to do it?
Thanks,
Alex
[julia-users] Re: using variables from the workspace to define JuMP problem
Thank you so much Joey!
Alex
On Monday, May 4, 2015 at 9:08:23 PM UTC-4, Joey Huchette wrote:
Yes:
@defVar(m, x[ i = 1 : length(z) ] = z[i] )
This error message is really opaque, though; I’ve updated it on JuMP
master to be a little more informative.
-Joey
On Monday, May 4, 2015 at 6:23:45 PM UTC-4, Alexandros Fakos wrote:
Hi,
z is a variable in the workspace
Ideally I would like to define variable x for the optimization problem
like:
@defVar(m, x[ 1 : length(z) ] = z )
which gives the error
ERROR: `Variable` has no method matching Variable(::Model,
::Array{Float64,1}, ::Float64, ::Symbol, ::ASCIIString, ::Float64)
in anonymous at julia/v0.3/JuMP/src/macros.jl:81
Is there any way to do it?
Thanks,
Alex
Re: [julia-users] Re: function similar to matlab tabulate
I see your point. Thanks a lot. Alex On Thursday, April 30, 2015 at 9:47:00 PM UTC-4, Tim Holy wrote: See collect. But in julia, it's often the case that you don't need to do things that way. For example, for (key,value) in mydict # do something with key and value end might be faster because it does not end up allocating any memory. --Tim On Thursday, April 30, 2015 02:05:37 PM Alexandros Fakos wrote: Thanks a lot. countmap returns a dictionary but I would prefer an array. How can I do that? Thank you On Thursday, April 30, 2015 at 4:41:43 PM UTC-4, Johan Sigfrids wrote: countmap in the StatsBase.jl package does this. On Thursday, April 30, 2015 at 11:11:37 PM UTC+3, Alexandros Fakos wrote: Hi, Is there a way to get a table of frequencies of the unique values in an array in Julia? Something like matlab's tabulate Thanks a lot, Alex
[julia-users] function similar to matlab tabulate
Hi, Is there a way to get a table of frequencies of the unique values in an array in Julia? Something like matlab's tabulate Thanks a lot, Alex
[julia-users] broadcast comparison operators
Hi,
Why the following commands give different results?
julia broadcast(.==,[1.0],[0.0,1.0])
2-element Array{Float64,1}:
0.0
1.0
julia repmat([1.0],2,1).==[0.0,1.0]
2x1 BitArray{2}:
false
true
How can I use broadcast for array comparisons (with a bit array as output)?
Thanks,
Alex
[julia-users] Re: function similar to matlab tabulate
Thanks a lot. countmap returns a dictionary but I would prefer an array. How can I do that? Thank you On Thursday, April 30, 2015 at 4:41:43 PM UTC-4, Johan Sigfrids wrote: countmap in the StatsBase.jl package does this. On Thursday, April 30, 2015 at 11:11:37 PM UTC+3, Alexandros Fakos wrote: Hi, Is there a way to get a table of frequencies of the unique values in an array in Julia? Something like matlab's tabulate Thanks a lot, Alex
Re: [julia-users] broadcast comparison operators
Thank you so much Stefan.
I feel like an idiot that I didn't try [1.0] .== [0.0,1.0] at first
Best,
Alex
On Thursday, April 30, 2015 at 5:31:52 PM UTC-4, Stefan Karpinski wrote:
The broadcast function assumes that the output array is the same type as
the input arrays. You can do something like this with the mutating
broadcast! function:
julia broadcast!(==, falses(2,2), [1,2], [2,1]')
2x2 BitArray{2}:
false true
true false
Also, you can just use the .== function, which automatically does the
correct broadcasting for you:
julia [1.0] .== [0.0,1.0]
2-element BitArray{1}:
false
true
On Thu, Apr 30, 2015 at 2:50 PM, Alexandros Fakos alexand...@gmail.com
javascript: wrote:
Hi,
Why the following commands give different results?
julia broadcast(.==,[1.0],[0.0,1.0])
2-element Array{Float64,1}:
0.0
1.0
julia repmat([1.0],2,1).==[0.0,1.0]
2x1 BitArray{2}:
false
true
How can I use broadcast for array comparisons (with a bit array as
output)?
Thanks,
Alex
