Dear all, here are a few explanations of the suggested changes and some subjective comments.
First to Dave It's hard to evaluate the effect of (5) without knowing what functions we > are talking about. I will point out that invisible returns are very > confusing to novice R users. > -Dave > We are talking about functions with side effects, i.e. functions which usually do not return an object. Examples are plot(), print(), summary() and as you see these functions are often generic functions. The tidyverse relies heavily on this for piping. In phangorn this allows you to do things like pml_bb(alignment, "JC") |> plot() |> print(). And users would not be confused, as the object is returned invisible. If you don't assign the output you won't notice. However they might wonder nowadays why piping is not working. and now to Vojtěch > Hello, > this a perfect idea. :-) I'd love to see one two things: > 1) Support for parallelization whenever possible (various distance, work > with > multi.whatever objects, ...) to speed things up. > This is generally a good idea. The problem is that parallelization depends on the hardware (cluster, multicore machine) of the user, the operating system (usually easy on Linux, tricky on OSX and Windows) and additionally whether you run R inside a GUI or from the console. Additionally some matrix algebra code might already be parallelized. This depends on the BLAS library you use, so if you use parallelization on top you might slow down your computer. This is why I started using the future and future.apply packages in phangorn instead of mclapply. This puts the user in control to choose the parallelization framework to use and I don't need to check the operating system, number of cores, GUI etc. Some low level openMP stuff in C/C++ code might be still nice. > 2) Removal of all the *.mutliPhylo functions, i.e. IMHO the best would be > if > every relevant function would support phylo as well as multiPhylo objects. > Now > it's a bit confusing whenever to use which function... > I think there might be a misconception here. We introduced a lot of generic functions to ape, e.g. root, is.rooted, is.ultrametric etc. Now while there exist is.rooted.phylo() and is.rooted.multiPhylo(), users should only need to use is.rooted(x) and don't need to care about the phylo or multiPhylo versions. Maybe it is more a problem with the documentation? > So here are my proposals for the discussion. :-) > Sincerely, > V. Cheers, Klaus > > On Mon, Jan 26, 2026 at 9:31 AM Emmanuel Paradis <[email protected]> > wrote: > > > Dear all, > > > > We are in the process of reviewing the "old" code in ape (some written in > > 2001). Here are a few things that came out recently: > > > > 1) During a recent discussion, we wondered if the option "..." of > > read.tree() is useful; it is passed internally to scan(). A review of the > > CRAN packages suggests this option is useless so it could be removed, at > > least without breaking those packages. There may be other bits of code > that > > can be removed safely in other functions. > > > > 2) Printing of objects could be improved. > > > > 3) I've (re)introduced a function mafft() in ape. A function with the > same > > name was formerly in ips which is now orphaned on CRAN. > > > > 4) A review of the man pages (help) would be useful. For instance, in > > ?read.tree one can read: "If there are two root edges (e.g., > > "(((A:1,B:1):10):10);"), then the tree is not read and an error message > is > > issued." [1] which is wrong since all types of Newick tree can be read. > > There are certainly similar outdated statements in the 300 pages of the > > manual. > > > > 5) Klaus suggests to have more functions returning their "return value" > > invisibly to make easier the use of pipe operators (|> or %>%). > > > > Any thoughts, ideas, or comments are welcome. > > > > Best, > > > > Emmanuel > > > > [1] In version 5.8-1 currently on CRAN; now fixed on GitHub. > > > > _______________________________________________ > > R-sig-phylo mailing list - [email protected] > > https://stat.ethz.ch/mailman/listinfo/r-sig-phylo > > Searchable archive at > > http://www.mail-archive.com/[email protected]/ > > > > [[alternative HTML version deleted]] > > _______________________________________________ > R-sig-phylo mailing list - [email protected] > https://stat.ethz.ch/mailman/listinfo/r-sig-phylo > Searchable archive at > http://www.mail-archive.com/[email protected]/ > -- Klaus Schliep Senior Scientist Institute of Molecular Biotechnology TU Graz https://www.imbt.tugraz.at [[alternative HTML version deleted]] _______________________________________________ R-sig-phylo mailing list - [email protected] https://stat.ethz.ch/mailman/listinfo/r-sig-phylo Searchable archive at http://www.mail-archive.com/[email protected]/
