Re: [julia-users] Re: newbie questions (was undefined reference error)

[Cedric St-Jean]

I can't read assembly very well, but if I'm not mistaken it seems to be 
moving the .g and .b to xmm0 and xmm1, then back again. Timing it with 
@benchmark shows that it's a negligible ~2% difference though. Cool!

function full_red!(vec::Vector{RGB{Float64}})
for i in 1:length(vec)
vec[i] = RGB(1.0, vec[i].g, vec[i].b)
end
vec
end

# compiles to

L56:cmpq8(%rdi), %rcx
jae L128
imulq   $-3, %rdx, %rax
movq(%rdi), %rsi
movsd   8(%rsi,%rax,8), %xmm0 
movsd   16(%rsi,%rax,8), %xmm1
imulq   $-24, %rdx, %rax
movsd   %xmm1, 16(%rsi,%rax)
movsd   %xmm0, 8(%rsi,%rax)
movq%r8, (%rsi,%rax)
incq%rcx
decq%rdx
cmpq%rdx, %r9
jne L56




function modify_3(vec::Vector{Float64})
for i in 1:3:length(vec)
vec[i] = 1.0
end
vec
end

#compiles to

L73 cmpq%rax, %rsi
jae L129
movq(%r14), %rdi
leaq(,%rdx,8), %rbx
negq%rbx
movq%r8, (%rdi,%rbx)
addq$3, %rsi
addq$-3, %rdx
cmpq%rdx, %rcx
jne L73




On Wednesday, May 11, 2016 at 8:09:50 AM UTC-4, Yichao Yu wrote:
>
> On Wed, May 11, 2016 at 8:01 AM, Cedric St-Jean  > wrote: 
> > Tim, 
> > 
> > Isn't there an inefficiency here though? If my immutable had thirty 
> fields 
> > and I wanted to change the second field for each instance in an array of 
> 1M 
> > elements, I would have to read/write the whole array instead of just 
> writing 
> > one out of every thirty elements. 
>
> What's described here is the schematics, not necessarily what it compiles 
> to. 
> LLVM is reasonably good at doing this optimization. 
> There's also https://github.com/JuliaLang/julia/issues/11902 to add 
> better syntax support. 
>
> > 
> > Cédric 
> > 
> > On Tue, May 10, 2016 at 9:42 PM, Tim Holy  > wrote: 
> >> 
> >> The right way to think about it is that an immutable is like a number: 
> >> you're 
> >> used to being able to have an array of Float64 and replace those, 
> right? 
> >> You're not redefining the meaning of "5.2", you're overwriting the 
> value 
> >> stored 
> >> in that slot. Arrays of immutables work exactly the same way: the 
> >> container is 
> >> not immutable, but the individual values stored in it are. That doesn't 
> >> prevent you from replacing them. 
> >> 
> >> Best, 
> >> --Tim 
> >> 
> >> On Tuesday, May 10, 2016 08:43:04 PM Boylan, Ross wrote: 
> >> > But if I make an array of immutables I won't be able to change them 
> >> > afterwards.  Though I can replace them. 
> >> > 
> >> > With the old code except for 
> >> > 
> >> > immutable Stuff 
> >> > a::Int 
> >> > b::Int 
> >> > end 
> >> > 
> >> > I now have 
> >> >  julia> v=Array(TT.Stuff, 2) 
> >> >  2-element Array{TT.Stuff,1}: 
> >> >   TT.Stuff(140124021836848,140124000460928) 
> >> >   TT.Stuff(140124048730192,0) 
> >> > 
> >> >  julia> v[1].a=44  # what I'd like to do 
> >> >  ERROR: type Stuff is immutable 
> >> > 
> >> >  julia> v[1]=TT.Stuff(3, 4)  # work-around 
> >> >  TT.Stuff(3,4) 
> >> > 
> >> > !julia> v 
> >> >  2-element Array{TT.Stuff,1}: 
> >> >   TT.Stuff(3,4) 
> >> >   TT.Stuff(140124048730192,0) 
> >> > 
> >> > With immutable, is everything in the array laid out contiguous in 
> >> > memory? 
> >> > It seems sort of odd that the type is immutable yet I can overwrite 
> data 
> >> > of 
> >> > that type.  I suppose that would only be prohibited if the array were 
> >> > immutable. 
> >> > 
> >> > Thanks for the tip about using Type to get the zero to work. 
> >> > Ross 
> >> > 
> >> >  
> >> > From: julia...@googlegroups.com  [
> julia...@googlegroups.com ] on 
> >> > behalf 
> >> > of Cedric St-Jean [cedric...@gmail.com ] Sent: Tuesday, 
> May 10, 2016 
> >> > 1:20 PM 
> >> > To: julia-users 
> >> > Subject: [julia-users] Re: newbie questions (was undefined reference 
> >> > error) 
> >> > 
> >> > "normal" types are by definition heap-allocated, and are always 
>

Re: [julia-users] Re: newbie questions (was undefined reference error)

[Yichao Yu]

On Wed, May 11, 2016 at 8:01 AM, Cedric St-Jean  wrote:
> Tim,
>
> Isn't there an inefficiency here though? If my immutable had thirty fields
> and I wanted to change the second field for each instance in an array of 1M
> elements, I would have to read/write the whole array instead of just writing
> one out of every thirty elements.

What's described here is the schematics, not necessarily what it compiles to.
LLVM is reasonably good at doing this optimization.
There's also https://github.com/JuliaLang/julia/issues/11902 to add
better syntax support.

>
> Cédric
>
> On Tue, May 10, 2016 at 9:42 PM, Tim Holy  wrote:
>>
>> The right way to think about it is that an immutable is like a number:
>> you're
>> used to being able to have an array of Float64 and replace those, right?
>> You're not redefining the meaning of "5.2", you're overwriting the value
>> stored
>> in that slot. Arrays of immutables work exactly the same way: the
>> container is
>> not immutable, but the individual values stored in it are. That doesn't
>> prevent you from replacing them.
>>
>> Best,
>> --Tim
>>
>> On Tuesday, May 10, 2016 08:43:04 PM Boylan, Ross wrote:
>> > But if I make an array of immutables I won't be able to change them
>> > afterwards.  Though I can replace them.
>> >
>> > With the old code except for
>> >
>> > immutable Stuff
>> > a::Int
>> > b::Int
>> > end
>> >
>> > I now have
>> >  julia> v=Array(TT.Stuff, 2)
>> >  2-element Array{TT.Stuff,1}:
>> >   TT.Stuff(140124021836848,140124000460928)
>> >   TT.Stuff(140124048730192,0)
>> >
>> >  julia> v[1].a=44  # what I'd like to do
>> >  ERROR: type Stuff is immutable
>> >
>> >  julia> v[1]=TT.Stuff(3, 4)  # work-around
>> >  TT.Stuff(3,4)
>> >
>> > !julia> v
>> >  2-element Array{TT.Stuff,1}:
>> >   TT.Stuff(3,4)
>> >   TT.Stuff(140124048730192,0)
>> >
>> > With immutable, is everything in the array laid out contiguous in
>> > memory?
>> > It seems sort of odd that the type is immutable yet I can overwrite data
>> > of
>> > that type.  I suppose that would only be prohibited if the array were
>> > immutable.
>> >
>> > Thanks for the tip about using Type to get the zero to work.
>> > Ross
>> >
>> > 
>> > From: julia-users@googlegroups.com [julia-users@googlegroups.com] on
>> > behalf
>> > of Cedric St-Jean [cedric.stj...@gmail.com] Sent: Tuesday, May 10, 2016
>> > 1:20 PM
>> > To: julia-users
>> > Subject: [julia-users] Re: newbie questions (was undefined reference
>> > error)
>> >
>> > "normal" types are by definition heap-allocated, and are always
>> > manipulated
>> > them through pointers. What you want is
>> >
>> > immutables<http://docs.julialang.org/en/release-0.4/manual/types/#immutable
>> > -composite-types>
>> >
>> > immutable Stuff
>> > a::Int
>> > b::Int
>> > end
>> >
>> > # Also, for zeros to work,
>> >
>> > function zero(x::Type{Stuff})
>> > Stuff(0, 0)
>> > end
>> >
>> >
>> > On Tuesday, May 10, 2016 at 4:04:37 PM UTC-4, Boylan, Ross wrote:
>> > I'm puzzled that a type  consisting  only of 2 integers doesn't qualify
>> > as
>> > "bitstype".  Further experiment shows that the array seems to be an
>> > array
>> > of references, I don't know how to implement zero, and generally that
>> > I'm a
>> > bit lost :)  My goal is to get a densely packed array of data.  I assume
>> > that will use less memory and generate faster code; if not, maybe I
>> > should
>> > change my goal.
>> >
>> > BTW, my real use has a type more heterogeneous than 2 Int's, so a
>> > solution
>> > that uses a 2D array doesn't really generalize appropriately for me.
>> >
>> > module TT
>> > import Base.zero
>> >
>> > type Stuff
>> > a::Int
>> > b::Int
>> > end
>> >
>> > function zero(x::Stuff)
>> > Stuff(0, 0)
>> > end
>> >
>> > end
>> >
>> > julia> v=Array(TT.Stuff, 3)  #as before
>> >  3-element Array{TT.Stuff,1}:
>> &g

Re: [julia-users] Re: newbie questions (was undefined reference error)

[Cedric St-Jean]

Tim,

Isn't there an inefficiency here though? If my immutable had thirty fields
and I wanted to change the second field for each instance in an array of 1M
elements, I would have to read/write the whole array instead of just
writing one out of every thirty elements.

Cédric

On Tue, May 10, 2016 at 9:42 PM, Tim Holy  wrote:

> The right way to think about it is that an immutable is like a number:
> you're
> used to being able to have an array of Float64 and replace those, right?
> You're not redefining the meaning of "5.2", you're overwriting the value
> stored
> in that slot. Arrays of immutables work exactly the same way: the
> container is
> not immutable, but the individual values stored in it are. That doesn't
> prevent you from replacing them.
>
> Best,
> --Tim
>
> On Tuesday, May 10, 2016 08:43:04 PM Boylan, Ross wrote:
> > But if I make an array of immutables I won't be able to change them
> > afterwards.  Though I can replace them.
> >
> > With the old code except for
> >
> > immutable Stuff
> > a::Int
> > b::Int
> > end
> >
> > I now have
> >  julia> v=Array(TT.Stuff, 2)
> >  2-element Array{TT.Stuff,1}:
> >   TT.Stuff(140124021836848,140124000460928)
> >   TT.Stuff(140124048730192,0)
> >
> >  julia> v[1].a=44  # what I'd like to do
> >  ERROR: type Stuff is immutable
> >
> >  julia> v[1]=TT.Stuff(3, 4)  # work-around
> >  TT.Stuff(3,4)
> >
> > !julia> v
> >  2-element Array{TT.Stuff,1}:
> >   TT.Stuff(3,4)
> >   TT.Stuff(140124048730192,0)
> >
> > With immutable, is everything in the array laid out contiguous in memory?
> > It seems sort of odd that the type is immutable yet I can overwrite data
> of
> > that type.  I suppose that would only be prohibited if the array were
> > immutable.
> >
> > Thanks for the tip about using Type to get the zero to work.
> > Ross
> >
> > 
> > From: julia-users@googlegroups.com [julia-users@googlegroups.com] on
> behalf
> > of Cedric St-Jean [cedric.stj...@gmail.com] Sent: Tuesday, May 10, 2016
> > 1:20 PM
> > To: julia-users
> > Subject: [julia-users] Re: newbie questions (was undefined reference
> error)
> >
> > "normal" types are by definition heap-allocated, and are always
> manipulated
> > them through pointers. What you want is
> > immutables<
> http://docs.julialang.org/en/release-0.4/manual/types/#immutable
> > -composite-types>
> >
> > immutable Stuff
> > a::Int
> > b::Int
> > end
> >
> > # Also, for zeros to work,
> >
> > function zero(x::Type{Stuff})
> > Stuff(0, 0)
> > end
> >
> >
> > On Tuesday, May 10, 2016 at 4:04:37 PM UTC-4, Boylan, Ross wrote:
> > I'm puzzled that a type  consisting  only of 2 integers doesn't qualify
> as
> > "bitstype".  Further experiment shows that the array seems to be an array
> > of references, I don't know how to implement zero, and generally that
> I'm a
> > bit lost :)  My goal is to get a densely packed array of data.  I assume
> > that will use less memory and generate faster code; if not, maybe I
> should
> > change my goal.
> >
> > BTW, my real use has a type more heterogeneous than 2 Int's, so a
> solution
> > that uses a 2D array doesn't really generalize appropriately for me.
> >
> > module TT
> > import Base.zero
> >
> > type Stuff
> > a::Int
> > b::Int
> > end
> >
> > function zero(x::Stuff)
> > Stuff(0, 0)
> > end
> >
> > end
> >
> > julia> v=Array(TT.Stuff, 3)  #as before
> >  3-element Array{TT.Stuff,1}:
> >   #undef
> >   #undef
> >   #undef
> >
> >  julia> s=TT.Stuff(3, 5)
> >  TT.Stuff(3,5)
> >
> >  julia> v=fill(s, 2)
> >  2-element Array{TT.Stuff,1}:
> >   TT.Stuff(3,5)
> >   TT.Stuff(3,5)
> >
> >  julia> s.a=900
> >  900
> >
> >  julia> v  ###OOPS: every array element points to the same instance
> >  2-element Array{TT.Stuff,1}:
> >   TT.Stuff(900,5)
> >   TT.Stuff(900,5)
> >
> >  julia> zero(TT.Stuff)  # This is probably what needs to work for
> zeros() to
> > work ERROR: MethodError: `zero` has no method matching
> > zero(::Type{TT.Stuff})
> >
> > !julia> zero(TT.Stuff(1, 1))  # this at least calls the right c'tor
> >  TT.Stuff(0,0)
> >
> > Ross
> > 
> > From: julia...@googlegroups.com
> > [julia...@googlegroups.com] on behalf of Lutfullah
> > Tomak [tomak...@gmail.com] Sent: Tuesday, May 10,
> > 2016 12:04 AM
> > To: julia-users
> > Subject: [julia-users] undefined reference error
> >
> > You need to initialize array entries if you don't have eltype as
> bitstype.
> > Here, undefined reference means you had not initialize the entry. And,
> full
> > type assignment works because it initializes the entry.
>
>

Re: [julia-users] Re: newbie questions (was undefined reference error)

[Tim Holy]

The right way to think about it is that an immutable is like a number: you're 
used to being able to have an array of Float64 and replace those, right? 
You're not redefining the meaning of "5.2", you're overwriting the value stored 
in that slot. Arrays of immutables work exactly the same way: the container is 
not immutable, but the individual values stored in it are. That doesn't 
prevent you from replacing them.

Best,
--Tim

On Tuesday, May 10, 2016 08:43:04 PM Boylan, Ross wrote:
> But if I make an array of immutables I won't be able to change them
> afterwards.  Though I can replace them.
> 
> With the old code except for
> 
> immutable Stuff
> a::Int
> b::Int
> end
> 
> I now have
>  julia> v=Array(TT.Stuff, 2)
>  2-element Array{TT.Stuff,1}:
>   TT.Stuff(140124021836848,140124000460928)
>   TT.Stuff(140124048730192,0)
> 
>  julia> v[1].a=44  # what I'd like to do
>  ERROR: type Stuff is immutable
> 
>  julia> v[1]=TT.Stuff(3, 4)  # work-around
>  TT.Stuff(3,4)
> 
> !julia> v
>  2-element Array{TT.Stuff,1}:
>   TT.Stuff(3,4)
>   TT.Stuff(140124048730192,0)
> 
> With immutable, is everything in the array laid out contiguous in memory? 
> It seems sort of odd that the type is immutable yet I can overwrite data of
> that type.  I suppose that would only be prohibited if the array were
> immutable.
> 
> Thanks for the tip about using Type to get the zero to work.
> Ross
> 
> 
> From: julia-users@googlegroups.com [julia-users@googlegroups.com] on behalf
> of Cedric St-Jean [cedric.stj...@gmail.com] Sent: Tuesday, May 10, 2016
> 1:20 PM
> To: julia-users
> Subject: [julia-users] Re: newbie questions (was undefined reference error)
> 
> "normal" types are by definition heap-allocated, and are always manipulated
> them through pointers. What you want is
> immutables<http://docs.julialang.org/en/release-0.4/manual/types/#immutable
> -composite-types>
> 
> immutable Stuff
> a::Int
> b::Int
> end
> 
> # Also, for zeros to work,
> 
> function zero(x::Type{Stuff})
> Stuff(0, 0)
> end
> 
> 
> On Tuesday, May 10, 2016 at 4:04:37 PM UTC-4, Boylan, Ross wrote:
> I'm puzzled that a type  consisting  only of 2 integers doesn't qualify as
> "bitstype".  Further experiment shows that the array seems to be an array
> of references, I don't know how to implement zero, and generally that I'm a
> bit lost :)  My goal is to get a densely packed array of data.  I assume
> that will use less memory and generate faster code; if not, maybe I should
> change my goal.
> 
> BTW, my real use has a type more heterogeneous than 2 Int's, so a solution
> that uses a 2D array doesn't really generalize appropriately for me.
> 
> module TT
> import Base.zero
> 
> type Stuff
> a::Int
> b::Int
> end
> 
> function zero(x::Stuff)
> Stuff(0, 0)
> end
> 
> end
> 
> julia> v=Array(TT.Stuff, 3)  #as before
>  3-element Array{TT.Stuff,1}:
>   #undef
>   #undef
>   #undef
> 
>  julia> s=TT.Stuff(3, 5)
>  TT.Stuff(3,5)
> 
>  julia> v=fill(s, 2)
>  2-element Array{TT.Stuff,1}:
>   TT.Stuff(3,5)
>   TT.Stuff(3,5)
> 
>  julia> s.a=900
>  900
> 
>  julia> v  ###OOPS: every array element points to the same instance
>  2-element Array{TT.Stuff,1}:
>   TT.Stuff(900,5)
>   TT.Stuff(900,5)
> 
>  julia> zero(TT.Stuff)  # This is probably what needs to work for zeros() to
> work ERROR: MethodError: `zero` has no method matching
> zero(::Type{TT.Stuff})
> 
> !julia> zero(TT.Stuff(1, 1))  # this at least calls the right c'tor
>  TT.Stuff(0,0)
> 
> Ross
> 
> From: julia...@googlegroups.com
> [julia...@googlegroups.com] on behalf of Lutfullah
> Tomak [tomak...@gmail.com] Sent: Tuesday, May 10,
> 2016 12:04 AM
> To: julia-users
> Subject: [julia-users] undefined reference error
> 
> You need to initialize array entries if you don't have eltype as bitstype.
> Here, undefined reference means you had not initialize the entry. And, full
> type assignment works because it initializes the entry.

Re: [julia-users] Re: newbie questions (was undefined reference error)

[Cedric St-Jean]

> It seems sort of odd that the type is immutable yet I can overwrite data 
of that type.  I suppose that would only be prohibited if the array were 
immutable.

It's not the array that's immutable, it's the values contained therein. I 
agree that it's a bit weird to have to replace the whole immutable rather 
than just the field you want. IIRC there are plans to improve on that.

On Tuesday, May 10, 2016 at 6:43:56 PM UTC-4, Kristoffer Carlsson wrote:
>
> Bitstypes are laid out contiguosly in memory. Your "workaround" way is a 
> good way of doing it and will be fast.

RE: [julia-users] Re: newbie questions (was undefined reference error)

[Kristoffer Carlsson]

Bitstypes are laid out contiguosly in memory. Your "workaround" way is a good 
way of doing it and will be fast.

RE: [julia-users] Re: newbie questions (was undefined reference error)

[Boylan, Ross]

But if I make an array of immutables I won't be able to change them afterwards. 
 Though I can replace them.

With the old code except for

immutable Stuff
a::Int
b::Int
end

I now have
 julia> v=Array(TT.Stuff, 2)
 2-element Array{TT.Stuff,1}:
  TT.Stuff(140124021836848,140124000460928)
  TT.Stuff(140124048730192,0)

 julia> v[1].a=44  # what I'd like to do
 ERROR: type Stuff is immutable

 julia> v[1]=TT.Stuff(3, 4)  # work-around
 TT.Stuff(3,4)

!julia> v
 2-element Array{TT.Stuff,1}:
  TT.Stuff(3,4)
  TT.Stuff(140124048730192,0)

With immutable, is everything in the array laid out contiguous in memory?  It 
seems sort of odd that the type is immutable yet I can overwrite data of that 
type.  I suppose that would only be prohibited if the array were immutable.

Thanks for the tip about using Type to get the zero to work.
Ross


From: julia-users@googlegroups.com [julia-users@googlegroups.com] on behalf of 
Cedric St-Jean [cedric.stj...@gmail.com]
Sent: Tuesday, May 10, 2016 1:20 PM
To: julia-users
Subject: [julia-users] Re: newbie questions (was undefined reference error)

"normal" types are by definition heap-allocated, and are always manipulated 
them through pointers. What you want is 
immutables<http://docs.julialang.org/en/release-0.4/manual/types/#immutable-composite-types>

immutable Stuff
a::Int
b::Int
end

# Also, for zeros to work,

function zero(x::Type{Stuff})
Stuff(0, 0)
end


On Tuesday, May 10, 2016 at 4:04:37 PM UTC-4, Boylan, Ross wrote:
I'm puzzled that a type  consisting  only of 2 integers doesn't qualify as 
"bitstype".  Further experiment shows that the array seems to be an array of 
references, I don't know how to implement zero, and generally that I'm a bit 
lost :)  My goal is to get a densely packed array of data.  I assume that will 
use less memory and generate faster code; if not, maybe I should change my goal.

BTW, my real use has a type more heterogeneous than 2 Int's, so a solution that 
uses a 2D array doesn't really generalize appropriately for me.

module TT
import Base.zero

type Stuff
a::Int
b::Int
end

function zero(x::Stuff)
Stuff(0, 0)
end

end

julia> v=Array(TT.Stuff, 3)  #as before
 3-element Array{TT.Stuff,1}:
  #undef
  #undef
  #undef

 julia> s=TT.Stuff(3, 5)
 TT.Stuff(3,5)

 julia> v=fill(s, 2)
 2-element Array{TT.Stuff,1}:
  TT.Stuff(3,5)
  TT.Stuff(3,5)

 julia> s.a=900
 900

 julia> v  ###OOPS: every array element points to the same instance
 2-element Array{TT.Stuff,1}:
  TT.Stuff(900,5)
  TT.Stuff(900,5)

 julia> zero(TT.Stuff)  # This is probably what needs to work for zeros() to 
work
 ERROR: MethodError: `zero` has no method matching zero(::Type{TT.Stuff})

!julia> zero(TT.Stuff(1, 1))  # this at least calls the right c'tor
 TT.Stuff(0,0)

Ross

From: julia...@googlegroups.com 
[julia...@googlegroups.com] on behalf of Lutfullah Tomak 
[tomak...@gmail.com]
Sent: Tuesday, May 10, 2016 12:04 AM
To: julia-users
Subject: [julia-users] undefined reference error

You need to initialize array entries if you don't have eltype as bitstype. 
Here, undefined reference means you had not initialize the entry. And, full 
type assignment works because it initializes the entry.

[julia-users] Re: newbie questions (was undefined reference error)

[Cedric St-Jean]

"normal" types are by definition heap-allocated, and are always manipulated 
them through pointers. What you want is immutables 


immutable Stuff
a::Int
b::Int
end

# Also, for zeros to work,

function zero(x::Type{Stuff})
Stuff(0, 0)
end


On Tuesday, May 10, 2016 at 4:04:37 PM UTC-4, Boylan, Ross wrote:
>
> I'm puzzled that a type  consisting  only of 2 integers doesn't qualify as 
> "bitstype".  Further experiment shows that the array seems to be an array 
> of references, I don't know how to implement zero, and generally that I'm a 
> bit lost :)  My goal is to get a densely packed array of data.  I assume 
> that will use less memory and generate faster code; if not, maybe I should 
> change my goal.
>
> BTW, my real use has a type more heterogeneous than 2 Int's, so a solution 
> that uses a 2D array doesn't really generalize appropriately for me.
>
> module TT
> import Base.zero
>
> type Stuff
> a::Int
> b::Int
> end
>
> function zero(x::Stuff)
> Stuff(0, 0)
> end
>
> end
>
> julia> v=Array(TT.Stuff, 3)  #as before
>  3-element Array{TT.Stuff,1}:
>   #undef
>   #undef
>   #undef
>
>  julia> s=TT.Stuff(3, 5)
>  TT.Stuff(3,5)
>
>  julia> v=fill(s, 2)
>  2-element Array{TT.Stuff,1}:
>   TT.Stuff(3,5)
>   TT.Stuff(3,5)
>
>  julia> s.a=900
>  900
>
>  julia> v  ###OOPS: every array element points to the same instance
>  2-element Array{TT.Stuff,1}:
>   TT.Stuff(900,5)
>   TT.Stuff(900,5)
>
>  julia> zero(TT.Stuff)  # This is probably what needs to work for zeros() 
> to work
>  ERROR: MethodError: `zero` has no method matching zero(::Type{TT.Stuff})
>
> !julia> zero(TT.Stuff(1, 1))  # this at least calls the right c'tor
>  TT.Stuff(0,0)
>
>
> Ross
> 
> From: julia...@googlegroups.com  [julia...@googlegroups.com 
> ] on behalf of Lutfullah Tomak [tomak...@gmail.com 
> ]
> Sent: Tuesday, May 10, 2016 12:04 AM
> To: julia-users
> Subject: [julia-users] undefined reference error
>
> You need to initialize array entries if you don't have eltype as bitstype. 
> Here, undefined reference means you had not initialize the entry. And, full 
> type assignment works because it initializes the entry.
>
>