Perl 6 - the future is here, just unevenly distributed

IRC log for #opentreeoflife, 2015-05-07

| Channels | #opentreeoflife index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:26 jar286 joined #opentreeoflife
00:39 kcranstn joined #opentreeoflife
01:11 josephwb joined #opentreeoflife
01:52 jimallman joined #opentreeoflife
02:12 kcranstn joined #opentreeoflife
11:07 jar286 joined #opentreeoflife
13:19 kcranstn joined #opentreeoflife
14:06 josephwb joined #opentreeoflife
14:21 jar286 joined #opentreeoflife
14:22 kcranstn jar286?
14:22 jar286 here
14:23 kcranstn do you understand the meaning of “ingroup property” ?
14:23 kcranstn is this something other than the set of taxa?
14:23 kcranstn or neo4j jargon?
14:23 jar286 hang on, let me look at context
14:23 kcranstn Basic description of the TAG sectin
14:24 kcranstn section
14:25 jar286 I think what’s meant is ingroup(v) and outgroup(v).  I hesitate to call these sets the ingroup and outgroup of v
14:25 kcranstn why?
14:26 kcranstn what’s the diff between “the ingroup of v” and “ingroup(v)"
14:27 jar286 uh… thinking… maybe it’s ok, my thinking is that the first has a meaning in discussion of phylogenetic studies, while the second is something we define formally
14:27 jar286 maybe the meanings are consistent, but (personally) I’d want to confirm that
14:28 kcranstn ok, back to “ingroup property”
14:29 kcranstn is that a list of nodes stored as a node property in neo4j?
14:30 jar286 I think it’s a bit set
14:30 josephwb it is a property of the node, yes
14:30 jar286 wp: In cladistics or phylogenetics, an outgroup is a group of organisms that serve as a reference group when determining the evolutionary relationship among three or more monophyletic groups of organisms.
14:31 kcranstn so you can get the ingroup property from the node itself, without needing to traverse
14:31 josephwb it is a list of descendant node ids
14:31 jar286 not exactly accurate in our case, but maybe close enough to not confuse readers
14:31 kcranstn thanks, josephwb
14:31 jar286 not a bit set? really?
14:32 josephwb longs, i believe
14:32 josephwb *checking*
14:32 josephwb array of longs
14:33 kcranstn is the ingroup property all of the descdent nodes, or just the tip nodes?
14:33 josephwb tips
14:33 kcranstn thanks
14:34 josephwb https://github.com/OpenTreeOfLife/treemachine/blob/rootward-synth/src/main/java/opentree/constants/NodeProperty.java
14:35 josephwb jar286 not sure why it is not a bit set
14:35 jar286 if you’re still using neo4j, then you can store an array of longs as a node property, but not a java bit set.
14:36 josephwb ah, that's why then
14:36 jar286 but you could roll your own bit sets, and store those encoded in a form neo4j can cope with
14:36 josephwb it is converted to a bit set for many operations in loading and synthesis
14:36 jar286 of course they’re very easy to recompute when needed, so there’s no reason to put them in neo4j at all
14:37 blackrim joined #opentreeoflife
14:37 jar286 the array of long form uses probably 100x more space than a bit set (or more)
14:38 josephwb yeah
14:38 kcranstn ok, getting distracted from what’s needed to finish the supplemental doc
14:44 kcranstn when creating merger nodes, this is only within subproblems, right?
14:46 blackrim that is correct
14:47 mtholder joined #opentreeoflife
14:53 mtholder who didn't ask for ORCIDs, jar286? (re: email thread)
14:53 jar286 oxford
14:54 mtholder I don't recall that being a part of the submission.
14:54 mtholder it would have been the original submission. so it has been a while
14:55 jar286 I’m just interested in (informally) tracking orcid uptake. Maybe this is one publisher that’s not on board yet.
14:56 kcranstn hate to be the grumpy one here, but orcids = distraction from finishing supplemental doc
14:56 kcranstn this needs to get done, or we aren’t resubmitting
14:57 jar286 yep
14:59 kcranstn in the merger nodes for the root, I am not clear on the diff between q_k and m_k
14:59 kcranstn section Merger nodes for the root of one tree to nodes in other trees
15:00 mtholder m_k is a node in an input phylogeny.
15:00 mtholder q_k is a TAG node that represents it.
15:01 kcranstn ok
15:06 josephwb mtholder is there a way to get the number of nodes supported by an input (not taxonomy) for an individual clade?
15:06 josephwb otc-find-unsupported-nodes considers taxonomy as an input
15:07 mtholder I don't think that it does.
15:07 mtholder i think that it just needs the taxonomy.
15:08 josephwb 4747 internal nodes where flagged as being supported by an input (including taxonomy)
15:08 mtholder IIRC that is the sum of supported nodes and nodes w/ internal labels.
15:09 josephwb but labelled nodes may or may not have tree support
15:09 kcranstn how many subproblems are there? (and what is the size range of the subproblems, i.e. the number of tree + taxonomy fragments)?
15:09 kcranstn is that easy to get?
15:10 josephwb 5733
15:10 kcranstn turns out taht number is in josephwb’s brain
15:10 kcranstn nice
15:10 josephwb yes. yes it is.
15:11 mtholder http://phylo.bio.ku.edu/ot/subproblem-stats-v3.tsv
15:11 mtholder has stats
15:12 mtholder described at https://github.com/OpenTreeOfLife/otcetera#calculating-stats-for-the-subproblems
15:12 josephwb actual number is smaller. treemachine skips trivial cases
15:12 kcranstn mtholder is the documentation king
15:13 mtholder yeah. I think otcetera spit out 8537 subproblems, but many are trivial
15:14 mtholder josephwb, I just checked. find-unsupported-nodes does not look to the taxonomy for support.
15:14 mtholder it is not an efficient impl
15:14 mtholder and I figured that the taxonomic nodes would have labels.
15:14 josephwb so the summary statement is incorrect?
15:15 mtholder I think so.
15:15 josephwb ok, that makes it easy for us then
15:15 josephwb thanks
15:15 josephwb joined #opentreeoflife
15:15 kcranstn looks like range of column NT is 0 to 16,
15:16 kcranstn so min # fragments = 1 (OTT only) and max is 16
15:17 kcranstn do we remove redundant nodes from the TAG? or just create new mapping nodes?
15:17 blackrim kcranstn, we don't create redundant nodes unless I miss the reference
15:17 kcranstn “After creating new nodes from the subproblems, we then check whether the TAG contains compatible nodes with the same ingroup/outgroup properties. In such cases, we align the compatible nodes, removing redundant nodes. “
15:18 josephwb kcranstn: the number of subprobs used by treemachine is 2792
15:18 josephwb 5733 are given as input, but many skipped as trivial
15:19 josephwb we get to 5733 in the first place by discarding taxonomy-onoy subprobs
15:19 mtholder tm does not read the taxonomy.
15:19 mtholder so NT < 3 is trivial
15:19 kcranstn ok
15:19 josephwb yes
15:19 mtholder 2804 are taxonomy only
15:19 kcranstn “For the taxonomy and input trees used in this version of the synthetic tree, there are 2792 non-trivial subproblems with between 2 and 15 tree fragments.
15:19 kcranstn
15:20 mtholder 3582 have just 1 phylo input
15:20 kcranstn oops, right
15:20 blackrim kcranstn, I believe that sentence should be removed but i will have it as a comment to cody to make sure that I am not missing something
15:21 kcranstn “The nodes created in the previous subproblem-specific sections (the members of the sets R, B and D) have ingroup and outgroup properties that reflect between 1 and 4 trees.”
15:21 kcranstn why between 1 and 4?
15:22 mtholder keep reading
15:22 kcranstn *keeps reading*
15:22 kcranstn ah, got it
15:24 blackrim I have a student meeting so have to go away but will be back ASAP
15:29 kcranstn can I move the nestedchildof definition from cody’s text up to the WalkPaths section? the definition in WalkPaths seems to vague (page  14)
15:29 kcranstn too vague
15:29 kcranstn and nestedchildof seems important
15:30 mtholder what is missing?
15:30 mtholder from the def?
15:30 kcranstn We say that p is a nested child of q if: node p and q are phylogenetically compatible,
15:30 kcranstn but no def of phylogenetically compatible
15:31 mtholder oh. the standard def: there exists a tree that shows both.  but you can use cody's def.
15:31 kcranstn and “Consider a pair of TAG node p and q, and the set w which is the intersection of outgroup(I) and ingroup(I)"
15:31 kcranstn ok
15:32 mtholder yeah that is wrong
15:32 jar286 a tree that shows both *in which p is descended from q*
15:32 jar286 (and different from)
15:32 mtholder that is correct
15:34 kcranstn cody’s def for nestedchild: ““v is a nested child of w”) if ingroup(v) ∩ outgroup(w) = ∅ and outgroup(v) ∩ ingroup(w) ≠ ∅”
15:35 jar286 that’s equivalent
15:35 kcranstn equivalent to what?
15:35 kcranstn “phylogenetically compatible"
15:35 jar286 yes
15:36 kcranstn and set w which is the intersection of outgroup(p) and ingroup(q)
15:36 mtholder you can be phylogenetically compatible by being disjunct (wrt ingroup) or nested.
15:36 mtholder nested is just ruling out the disjunct case
15:36 mtholder nested children, that is.
15:37 kcranstn so the opinion is that “phylogenetically compatible” is generic enough to not need defining? it only occurs twice in the text
15:37 mtholder your correction to w is correct.
15:37 kcranstn and the second instance refers to “definitions above"
15:39 kcranstn ok, added def to make myself feel better
15:39 kcranstn :)
15:42 josephwb i have a talk from 12:00-13:00, but will add in the "missing children" bit after that
15:42 kcranstn cool, thanks
15:48 kcranstn going to go get lunch
15:50 josephwb mtholder i think you might be wrong about taxonomy not being counted as support
15:50 josephwb for mammals i get:
15:50 josephwb 4056 internal nodes where flagged as being supported by an input (including taxonomy).
15:51 josephwb 1862 of these were named (some of the support could just be the taxonomic expansion of tips).
15:51 josephwb 2194 of these were unnamed.
15:51 josephwb 1862 + 2194 = 4056
15:51 josephwb unless for mammals every named node has tree support...
15:52 mtholder That should be the case
15:52 mtholder every taxonomic node should be named.
15:52 josephwb yes
15:52 mtholder every other node should be supported by a phylo input
15:52 josephwb but not every taxonomic node will have tree support
15:52 mtholder (non taxonomic)
15:52 mtholder correct.
15:52 mtholder here is what it does:
15:53 mtholder count every named node as supported.
15:53 josephwb but you said taxonomy does not count as support?
15:53 mtholder it does not check those nodes
15:53 josephwb ah
15:53 josephwb well, i need that
15:53 mtholder oblate the names.
15:53 josephwb i guess i could unname them
15:53 mtholder (internals that is)
15:54 josephwb we are sympatico
15:55 josephwb will it be a problem that the same node has a name in the taxonomy tree, but not in the synthetic tree?
15:56 josephwb i guess i could delete them from both
15:56 josephwb now i need to deal with those freaking newick labels...
15:56 mtholder I think that you just need to remove the internal names from the synth.
15:56 josephwb ok
15:56 mtholder leave the taxonomy unchanged.
15:57 josephwb gotta go to my talk now
15:57 josephwb l8r
16:12 jar286 ‘supported by’ sure occurs in the document a lot
16:12 jar286 I think it’s used in 3 different ways but I can’t tell because there are no definitions
16:13 mtholder yes. I'm not sure that the 'testSums' implements what I think of as "supported by"
16:16 mtholder also note that what I call the "no unsupported groups" rule is equivalent to Semple(2003)'s def. of "minor-minimal" trees
16:16 codiferous joined #opentreeoflife
16:16 mtholder some notes at section 1.3 of http://phylo.bio.ku.edu/ot/summarizing-taxonomy-plus-trees.pdf
16:16 pmidford2 joined #opentreeoflife
16:20 mtholder Oh, and jar286, I had defined what I meant by "unsupported" in the "Overview of synthesis method" section.
16:20 mtholder I agree that it is unclear whether or not that corresponds to the "testSums" code
16:20 jar286 yes, I saw that, but does it have anything to do with the method we’re trying to document?
16:21 mtholder dunno. I thought we had a greed on it as a req. but i don't understand testSums or exactly how the edges are formed in the TAG.
16:22 mtholder so I tried to document what is there because I don't know what else to do.
16:22 mtholder s/a greed/agreed/
16:23 jar286 cody just added a para deescribing how pretag edges are created for sum nodes
16:23 kcranstn where in the doc?
16:23 jar286 third para of “Nested child relationships”
16:24 jar286 will send some email that might help
16:24 kcranstn ok, thanks
16:30 jar286 email sent
16:40 snacktavish joined #opentreeoflife
16:43 mtholder I think that the bit of the email about the TAG vs PreTAG node is correct.
16:43 mtholder so I prefer not even mentioning "pre-TAG"
16:44 mtholder just describing how the TAG is built up.
16:44 mtholder I don't understand the edge creation, which is why my write-up ended before that.
16:44 jar286 I agree, but something in the writeup has to account for the non-imaged edges going away
16:44 mtholder looking at the code, I think there needs to be a description of how the root nodes are mapped
16:45 mtholder then Cody's description of the edges might be sufficient.
16:45 mtholder (that is the "Map Trees" section)
16:47 mtholder If I understand correctly, only the STREE nodes matter in synthesis.
16:47 mtholder So, I think we just have to explain how they get there.
16:48 mtholder (as opposed to introducing the concept of nested child of edges that later "go away")
16:48 kcranstn agree about getting rid of the pre-TAG if we can
16:49 mtholder I think that what codiferous referred to as the "pre-TAG" is all in memory data structures that are ephemeral.
16:53 jar286 all it would take is a single sentence to the effect that unimaged edges are not added to the TAG.  the fact that the code adds and then removes them is an implementation detail.
16:53 kcranstn and a description of “imaged”
16:53 jar286 yes
16:53 codiferous the pretag edges are stored in the db, but that is just an implementation detail
16:54 codiferous they could easily just be ephemeral in memory
16:54 codiferous the only edges that matter for synth are the STREE edges (as mark said)
16:54 codiferous (not STREE nodes, btw...)
16:54 mtholder gotta go. I'll check in later.
16:56 codiferous also, just to be clear, the code does not remove the pretag edges (those are MRCA edges), they just are only used during tree mapping
16:57 kcranstn codiferous, in the section “Addition of merger nodes for pairs of nodes” can you clarify what edges get added? currently, that only describes nodes
16:58 jar286 cody has already written that up… I can take a stab at a higher level treatment later today, I think there’s a way to say it that’s not too detailed
16:59 kcranstn ah, ok
16:59 kcranstn thanks, jar286
16:59 kcranstn can you point me to that writeup?
16:59 kcranstn i.e. what section in the doc
16:59 jar286 it’s what I said earlier, third para of “Nested child relationships”
17:00 kcranstn does that include both merger nodes and accumulation nodes?
17:01 jar286 no, that’s a distinct problem
17:02 kcranstn I don’t udnerstand that answer
17:02 jar286 sorry.
17:02 jar286 it’s a problem that the accumulation node edges are not documented (I’d have to double check, but I think they aren’t)
17:03 codiferous i haven't finished rewriting the addition of edges during the "accumulation nodes" (aka walking paths) step
17:03 codiferous it is there but it is still in the original notation and is not easy to read
17:04 kcranstn is “nested child relationships” synomymous with “nested child edges”
17:04 codiferous not really. only some of the possible relationships are actually created as edges
17:05 kcranstn I don’t see that the 3rd paragraph under nested child relationships refers to merger nodes rather than accumulation nodes
17:05 jar286 it only makes sense for merger nodes
17:06 kcranstn we don’t define nested child relationships until after merger nodes
17:06 jar286 nested child is defined in cody’s definitions section, yes?
17:07 jar286 oh, you’re talking about the upper writeup?
17:07 kcranstn yes
17:07 jar286 if it were me I’d say up front that the edges in the TAG are all NCO relationships (and define NCO at that point)
17:07 jar286 this is the most important thing about the TAG
17:08 kcranstn the upper writeup has no mention of edges between initial loading of OTT / subproblems and synthesis
17:08 jar286 I noticed that.  possibly due to the fact the Cody’s writeup similarly had no mention in the sums and paths sections
17:10 jar286 I’m going to get some lunch.  backson  http://winnie-pooh.org/rabbit-busy-day.htm
17:15 codiferous i did not mention tag edges until after the sums and paths because we don't create actual edge objects until after the sums and paths
17:15 kcranstn how do we walk paths without edges?
17:15 codiferous but we do record a lot of nco relationships during the sums and paths, which are logically equivalent to pretag edges
17:16 codiferous we walk the recorded nco rels that we save in memory
17:16 kcranstn ah, ok. This is an implementation detail causing conceptual challenges
17:16 codiferous then once we find all the nco rels we *want* to use as edges, we load them all into the graph at once
17:17 mtholder joined #opentreeoflife
17:17 codiferous yes, there is no reason to describe the tag exactly the way the implementation works
17:18 codiferous thats just how its organized in my head
17:19 kcranstn so when we create a merger node, we don’t actually create a neo4j edge, we just keep track of the two nodes being “merged"
17:19 codiferous yes
17:19 kcranstn and those conceptual edges are directed or undirected?
17:20 codiferous directed
17:21 codiferous we also record nco rels during that procedure that relate the sum nodes to the other input tree nodes
17:22 kcranstn are the “merger nodes” actually neo4j nodes?
17:22 kcranstn or, same as edges, we just keep track of them somewhere else
17:24 codiferous we create actual node objects as we go
17:24 kcranstn that are unconnected to other nodes in the TAG
17:25 codiferous no nodes are actually connected in the database itself until we finish the merger nodes and accumulation nodes steps
17:25 codiferous just an implementation detail
17:26 codiferous we collect the information about which nodes to make edges for during those procedures
17:26 kcranstn In the text, I think it’s easier to describe creating edges when we create nodes. You agree?
17:27 codiferous as far as the description, it is probably simpler to just talk about defining the actual edges as we go
17:27 codiferous yes, was just saying that as you did :p
17:28 codiferous basically, the function H that is discussed in the text is equivalent to the edge definitions
17:28 codiferous where i say let v be an element of H(w), that means a pretag edge (v,w) (i.e. v is the parent of w)
17:32 codiferous i am going to go now, will try to work on writing improved text for the testsums procedure later today with stephen
17:32 kcranstn ok
17:34 kcranstn I am so confused
17:35 mtholder 'bout what?
17:35 mtholder oh. I see.
17:35 kcranstn so we create merger nodes that represent cases where node p and node q might be the same node
17:36 kcranstn and conceptually, we also create directed edges
17:36 mtholder that is my way of thinking about it.
17:36 mtholder yes.
17:36 kcranstn so p <- w -> q
17:36 kcranstn w has in-degree 0?
17:36 kcranstn and out-degree 2/
17:36 kcranstn or the other way around?
17:37 mtholder sorry. where in the text? is that
17:37 mtholder ?
17:37 kcranstn it isn’t
17:37 kcranstn trying to figure out how we walkpaths to nodes without edges
17:37 mtholder Ah.
17:37 kcranstn or, how we describe walkpaths without describing edges
17:37 mtholder nodes in the TAG are (now) distinct combinations of ingroup + outgroup
17:38 mtholder we don't need them to be connected (initially).
17:38 mtholder the goal (as I understand it) is to express the possible sets of ingroups in nodes.
17:38 mtholder and then connect them later.
17:39 mtholder the nodes (with their ingroup + outgroup properties) are define a sort of search space for edge creation.
17:40 kcranstn do we need an edge creation section, or is that in “Generating the synthetic tree"?
17:40 kcranstn noting that the synthetic tree section immediately refers to edges
17:41 mtholder we need an edge creation section.
17:41 mtholder Cody's Map Trees is the only part that describes edges (AFAIK)
17:41 mtholder I found it to be incomplete.
17:41 mtholder or at least not comprehensible to me.
17:42 mtholder but it should go after node creation and before "generating the synthetic tree"
17:42 jar286 joined #opentreeoflife
17:43 kcranstn section added
17:43 kcranstn jar286 - added a edge creation section immediately before synthesis
17:43 jar286 back from lunch
17:43 kcranstn *goes off to read Map Trees*
17:43 jar286 that makes sense
17:44 jar286 reading irc log
17:44 mtholder I couldn't follow the "Map Trees" because it does not make sense if the set m starts empty.
17:45 mtholder nothing will get added to it.
17:45 mtholder in the code, you find a procedure for mapping root nodes
17:45 mtholder that needs to be described - it is what populates the set m.
17:46 mtholder and then the traversal is postorder. So it makes sense to make the existence of a parent node in the map as precondition for an edge.
17:46 blackrim weird root mapping use to be in the doc. will poke cody to see where it went and add back
17:47 kcranstn search for “Merger nodes from the root of one tree to nodes in other trees"
17:47 kcranstn or look in TOC
17:48 blackrim aha ok.
17:48 kcranstn (things have been shuffling around as we re-write and re-organize)
17:48 mtholder I think that is all about nodes, not  the mapping that creates edges.
17:49 kcranstn right
17:49 mtholder I think that "Procedurally, the imaging operation is performed recursively over all nodes in each t starting at root(t), where root(t) is first mapped to all taxon nodes u such that ingroup(root(t)) ⊆ ingroup(u)."
17:49 mtholder is it.
17:50 mtholder I don't understand why the roots are always mapped to taxonomy node.
17:50 mtholder FWIW
17:51 jar286 mtholder, cody did add some text about how edges are created for merger nodes (3rd para under “Nested child relationships”), I think last night
17:53 jar286 he said he intends to write about edges for the accumulation nodes, but my guess is they’re very similar (connect each one to the parents and children of the node from which it’s derived; presumably filtering out cases where NCO doesn’t hold)
17:54 jar286 I haven’t looked into the situation with roots
17:54 kcranstn I don’t know how to merge section 2.2 with the upper sections about Merger Nodes, Accumulation Nodes and Creating TAG Edges
17:55 mtholder 2.2.1 = merger nodes
17:55 jar286 they are parallel… what’s the plan, are we keeping Cody’s writeup for the supplement, or attempting to make the main writeup self-sufficient?
17:55 mtholder 2.3 = accumulation nodes
17:56 kcranstn I’d like to merge the two
17:56 kcranstn i.e. move detail from cody’s sections up where we need it
17:57 kcranstn but an open to debate
17:57 jar286 that’s going to be hard. how do we decide whether we need something? what’s the bar?
17:57 kcranstn right now it is two parallel methods papers
17:57 kcranstn which is redundant and confusing
17:57 jar286 true but incomplete, or true and complete (reproducible: enough information that someone can rewrite the code)?
17:58 jar286 it looked to me like we were going to discard the original description, and submit something that’s somewhat elliptical
17:59 kcranstn Mark convinced me that this should contain more detail than I originally anticipated
18:00 jar286 I’ve seen this many times, where the methods description isn’t adequate to permit writing the code, and the reference implementation is opaque. I don’t like doing that, but maybe no choice
18:02 jar286 it’s PR review time… only 2 PRs, but maybe jimallman and I should converse on a different channel
18:04 jar286 jimallman, join me on channel opentreeoflife-pr
18:04 jar286 and anyone else who cares
18:04 jimallman ok, see you there
18:16 snacktavish joined #opentreeoflife
18:18 jar286 josephwb, blackrim, I see no pull request for treemachine - I thought we talked about this on Tuesday?  really need it.
18:18 jar286 there is a PR on the ot-base repo, that’s all
18:20 jimallman looks like it should be branch ’rootward-synth’? that’s what we’re running on devapi
18:20 josephwb wasn't sure what was going on with jade
18:20 josephwb i can submit a PR
18:20 josephwb for treemachine
18:21 jar286 that would be nice
18:21 jimallman it looks like we’re running jade branch ‘new-synth-update’ on devapi. do we need a PR for that as well?
18:21 jar286 I don’t think jade is an opentreeoflife repo
18:21 snacktavish I'm starting a read through of what is in the supplemental - should I consider "Synthesis (original text)" as part of intro, or is that getting removed?
18:22 kcranstn getting removed
18:22 kcranstn feel free to remove it
18:22 snacktavish on it!
18:22 jar286 josephwb, can you join us on channel #opentreeoflife-pr?
18:22 kcranstn thanks, snacktavish!
18:22 kcranstn swoosh!
18:23 snacktavish dropped it in after the refs in case of emergency (?)
18:23 kcranstn I have a copy of this doc before the wild editing started
18:23 snacktavish ah cool
18:26 pmidford2 joined #opentreeoflife
18:51 snacktavish mtholder I wrote some comments directed at you in the decomp section
18:55 mtholder ok
18:56 snacktavish mostly just that I wasn't 100% on meaning of "Each subproblem is guaranteed to exist in the final supertree"
18:56 kcranstn FYI, I am starting to move stuff from Cody’s section up (starting with definitions)
18:57 kcranstn I think some of those defs are useful and will help with consistency
18:57 snacktavish and that meaning of 'OTT' ,'taxonomy' and 'pruned taxonomy' seem to jump around between step 1 and 4, not sure what best option is
18:57 kcranstn yeah, I was noticing that and trying to be specific about “the taxonomy after pre-processing step 1"
18:57 kcranstn which is clear but awkward
18:58 snacktavish can we name that 'pruned taxonomy' or 'taxonomy tree' in step 1?'
18:59 kcranstn not pruned, becasue there are two prunign steps
18:59 kcranstn taxonomy tree might work
19:00 kcranstn Maybe step 1 should be more explicit “remove questionable taxa from OTT”
19:00 kcranstn or non-evolutionary taxa
19:01 snacktavish I think  “remove questionable taxa from OTT” works better
19:01 kcranstn ok. go for it
19:01 snacktavish non-evolutionary implies.... Texas
19:01 kcranstn ha
19:03 jar286 when I add a comment, who sees it? just Cody? is there a way to subscribe to comments on a document?
19:03 snacktavish you can email tag people
19:03 kcranstn we all see it
19:03 kcranstn and you can tag people
19:04 kcranstn what snacktavish said
19:04 jar286 sorry, what I meant is, who gets notified by email, if no one is tagged?
19:04 kcranstn no one
19:05 kcranstn you only get notified in replies to your own comments
19:16 jar286 what’s the strategy here - is it to move information from the Cody-part to the upper part? what level of detail are we looking for, i.e. are there details we can just forget about?
19:16 kcranstn strategy is to homogenize into single description of the methods
19:17 jar286 and we’re looking for a very specific description, not just an overview?  are we trying to allow someone to implement the method given the writeup?
19:18 kcranstn I doubt we are going to be able to get that level of detail
19:18 kcranstn I am aiming for someone to understand what the method does
19:21 jar286 I guess there are two kinds of understanding.  there’s understand motivation and strategy, and there’s understanding to the point of being able to implement.
19:22 kcranstn which are two extremes
19:22 kcranstn we probably won’t get to the latter, but I would like to get close
19:23 kcranstn but I think having two essentially different writeups with different vocab is not helping people know what to focus on
19:23 kcranstn so trying to merge
19:24 snacktavish yeah, I don't think the 2 overlapping but differnet is helpful
19:25 snacktavish I think that write up should allow readers to understand expected behavior
19:25 snacktavish and potenial caveats
19:25 josephwb you around for a bit mtholder?
19:25 kcranstn he went to bed
19:25 mtholder a little longer
19:25 kcranstn oops
19:25 josephwb sending email now
19:25 mtholder but not much longer
19:25 josephwb [very easy stuff]
19:27 josephwb there, now really sent
19:28 mtholder can you send me the trees?
19:28 josephwb on the way
19:28 mtholder it might be an out-degree=1 thing
19:29 josephwb "knuckles"? yeah, that is my thinking too
19:30 josephwb sent
19:36 josephwb mtholder the 10 seems listed by:
19:36 josephwb Unsupported node ancestor 1 node(s) before MRCA...
19:37 mtholder I think I'll need to look at this in the morning. I suspect that it is not being careful to exclude the out-degree=1 nodes from the calculations at every point - leading to inconsistent behavior.
19:37 josephwb ok
19:37 josephwb thanks
19:37 mtholder Can you send or post the Mammalia_processed.trees file?
19:37 josephwb didn't i send it?
19:38 mtholder whoops. you did. overlooked it.
19:38 josephwb i see it in the email
19:38 josephwb ok
19:38 josephwb good
19:38 mtholder that is a signal that this cold/fever/whatever-the-hell-it-is is getting the best of me.
19:38 mtholder good night.
19:38 josephwb bye
19:38 mtholder left #opentreeoflife
19:44 snacktavish I still really don't get what happens with root nodes of trees :(
19:50 blackrim you mean this section "Merger nodes from the root of one tree to nodes in other trees" doesn't make sense?
19:52 kcranstn joined #opentreeoflife
19:59 kcranstn I think you just missed the line that defines set B
19:59 kcranstn vs set D
20:00 kcranstn search for “Let B” and “Let D"
20:18 jar286 Not sure how I can be most helpful
20:18 jar286 I’d like to print it out and read it through at some point
20:19 jar286 not sure when that should be
20:20 blackrim cody and i are working on making the supported by readable
20:20 jar286 good
20:26 kcranstn blackrim - Q about nestedchildof (section 2.2.2)
20:29 kcranstn I am still confused as to when new TAG edges actually get created
20:30 kcranstn section 2.2.2 only describes a function that is a set of nestedchildof nodes
20:38 * blackrim checking
20:39 jar286 I just did some work on the ‘creating TAG edges’ section
20:39 jar286 kcranstn ^
20:39 kcranstn yes, just replied to one of your comments
20:39 blackrim kcranstn, unless i am missing something it is in the 4. Map trees
20:39 kcranstn yeah, thats what I thought
20:40 kcranstn everything up to that point is just recording lists of nestedchildof nodes
20:40 kcranstn ^jar286
20:42 jar286 a collection of lists of nestedchildof nodes, one per node, *is* a graph. formerly it was called the preTAG
20:43 jar286 I’m not sure it helps the exposition to say that the edges are held up so the mapnames filtering step can be done as a batch operation
20:43 jar286 I’d rather say the filter is applied on the fly
20:43 kcranstn mapnames? you mean maptrees?
20:43 jar286 maptrees, yes
20:44 jar286 the explanation is simpler, I think.
20:44 kcranstn let’s give that a try in the Creating TAG edges section
20:45 kcranstn I agree that it might be simpler
21:02 jar286 the map trees section doesn’t explain what happens at the root… incomplete.  arg
21:28 jar286 well I think I got this right (characterization of preTAG/TAG difference), can be checked now.
21:28 jar286 i.e. replacement for ‘map trees’ section.
21:34 kcranstn joined #opentreeoflife
21:39 kcranstn thanks
21:40 kcranstn what do people think about the long nestedchildof explanation (wtih table and figure)? should we keep it?
21:41 kcranstn some of it feels like it would fit better in the TAG creation / synthesis section than as part of the nestedchildof definitin
21:41 kcranstn definition
21:46 kcranstn My brain is now fried after staring at the doc for 8 hours. Plus, I need to do a review tonight.
21:51 jar286 this is so frustrating…
23:58 kcranstn joined #opentreeoflife

| Channels | #opentreeoflife index | Today | | Search | Google Search | Plain-Text | summary