I see, I've hardcoded the most common attributes stored in nodes into the
nodes themselves - branch-lengths and confidence values and so on. I can
see this get's mind-bending in cases where nodes have different types and
so on. I wonder if a different approach is better - I've just had an idea
to do this differently, which might be a lot better. I'll write up some
solid code later and post back.



On Tue, Feb 24, 2015 at 8:25 AM, Mauro <mauro...@runbox.com> wrote:

> Sorry my first sentence should have read:
> > Julia will *not* be able to produce specialised code for any
> non-concrete type
> > in your PhyNode.
>
>
> > It does not matter whether it's Any or some other
> > abstract/parameter-less type.  At least that is how I read the docs:
> >
> http://docs.julialang.org/en/latest/manual/performance-tips/#type-declarations
> >
> > However, I think a method will only be slow if it actually uses the
> > PhyNode.extensions field, otherwise it should be fine.
> >
> > Anyway, can you not construct your type like so:
> > type PhyExtension{T}
> >   value::T
> > end
> >
> > type PhyNode{T}
> >   name::String
> >   branchlength::Float64
> >   confidence::Float64
> >   extensions::Vector{PhyExtension{T}}
> >   children::Vector{PhyNode{T}}
> >   parent::PhyNode{T}
> > end
> >
> > If a user needs to have different types of things in PhyNode.extensions
> > she can choose PhyExtension{Any} and loose some performance, otherwise a
> > concrete type, like PhyExtension{Float64}, will be fast.
> >
> > On Tue, 2015-02-24 at 02:30, Ben Ward <axolotlfan9...@gmail.com> wrote:
> >> Hi,
> >>
> >> In Julia, if you are not sure of an arguments type beforehand, you can
> use
> >> 'Any', or if you know it comes under an abstract type, you can use that.
> >>
> >> I've been working on a type for BioJulia which allows for
> representation of
> >> a node of a phylogenetic tree that will allow annotation with biological
> >> data in the form of other types from the packages from BioJulia:
> >>
> >> @doc """
> >> PhyExtension allows defining arbitrary metadata to annotate nodes.
> >>
> >>
> >> this allows the PhyNode type to support any phylogenetic tree format
> >> that includes annotations (e.g. PhyloXML, NeXML), and allows
> programmatic
> >> extension of nodes with annotations.
> >> """ ->
> >> type PhyExtension{T}
> >>   value::T
> >> end
> >>
> >>
> >> @doc """
> >> PhyNode represents a node in a phylogenetic tree.
> >>
> >>
> >> A node can have:
> >>
> >>
> >> - `name`
> >> - `branchlength`
> >> - one or more `extensions`
> >> - a reference to its `parent` PhyNode
> >> - reference to one or more `children`
> >> """ ->
> >> type PhyNode
> >>   name::String
> >>   branchlength::Float64
> >>   confidence::Float64
> >>   extensions::Vector{PhyExtension}
> >>   children::Vector{PhyNode}
> >>   parent::PhyNode
> >>  # Inner constructor goes here.
> >>
> >> As you can see - PhyExtension is parametric so can be constructed to
> >> contain any type.
> >>
> >> I'm wondering, though is this the best that can be done, can I handle
> the
> >> potential to hold any number of types with unknown variables any better
> -
> >> if so, how?
> >>
> >> Is specifying a Vector of PhyExtension, where a PhyExtenision is a type
> >> that contains any other type really giving that much information to the
> >> Julia system to work on efficiently?
> >>
> >> My understanding is that PhyExtension is parametric so a version is
> >> effectively defined for every possible {T} (including user defined
> >> composite types they might come up with). But then I imagine that's not
> >> much information when creating the Vector{PhyExtension} as an element
> could
> >> be any of the many possible PhyExtensions - the compiler has to allow
> for
> >> an array that can store any PhyExtension? Or is it that the array
> contains
> >> references to PhyExtensions so actually the array is simple?
> >>
> >> Thanks,
> >> Ben.
>
>

Reply via email to