Re: RFC: new task-science package
>>>>> "Dirk" == Dirk Eddelbuettel <edd@master.debian.org> writes:
> Maybe even task-plotting though I am not sure if grouping
> gnuplot, plotmtv, grave, plplot, plotutils really gains
> anything coherent.
I'm not sure it does either :) but it aught to include dx as
well. Also xmgr, yorick, gist and others. There are lots of
libraries and extensions that might want to be a part of
task-science and offshoots - netcdf and hdf, a variety of fft
libs, NumPy, BLT and many more. On top of that, a number of
things would tend to fall into multiple tasks - dx, yorick and
octave could be included as part of plotting and numeric tasks.
As scientist who primarily uses debian and other unix systems in
the lab and on my desk, I've found task-science to be of limited
use. Most of the things I use for distinctly "scientific" tasks
are not in task-science. We already have a package system that
makes it easy to install a given package so the utility of the
task packages for applications is not that high. The development
and library task packages address a somewhat more well defined
area of use and so don't seem to be at as large a risk of
dependency bloat as science. The issue is similar to that of the
"what goes into the math section" discussion - and I don't think
there is a clear answer for that either. I won't let that stop
me from proposing one though!
Given the recent related discussion about what some see as too
many task packages, I wonder if it might be worthwhile to create
a new section called tasks where we could accumulate lots of
smaller collections of packages. That might help cover up (but
not solve :) the problem of proliferating tasks. This would
likely result in even greater proliferation of tasks. If the
task package docs included a detailed description of how the
dependencies are related and why they make performing the task an
all around better thing, this could be a plus.
As an example: task-fft could include fftw2, NumPy and a complete
collection of the other packages that include fft routines. Add
in some graphics packages for plotting (or a dependency to
task-plotting?) the results and a summary discussion of the
relative merits of the different fft algorithms used and you'll
see what I'm getting at. A related task could be task-2D-fft,
which would depend on task-fft and various image processing
packages.
Mike
--
Michael A. Miller mmiller3@iupui.edu
Krannert Institute of Cardiology, IU School of Medicine
Indiana Center for Vascular Biology and Medicine
Reply to: