Michael Goffioul wrote: > On Wed, Jul 18, 2012 at 9:46 PM, Alexander Barth > <barth.alexan...@gmail.com <mailto:barth.alexan...@gmail.com>> wrote: > > On Wed, Jul 18, 2012 at 3:14 PM, Michael Goffioul > <michael.goffi...@gmail.com <mailto:michael.goffi...@gmail.com>> wrote: > > On Wed, Jul 18, 2012 at 12:44 PM, Alexander Barth > > <barth.alexan...@gmail.com <mailto:barth.alexan...@gmail.com>> wrote: > >> > >> Sorry for poor spelling in my last email. The email was sent > >> inadvertently before I could check it. > >> Source packages are here: > >> > >> > >> > > http://modb.oce.ulg.ac.be/mediawiki/upload/Alex/ncArray/ncarray-1.0.0.tar.gz > >> > >> > > http://modb.oce.ulg.ac.be/mediawiki/upload/Alex/ncArray/ncarray-html.tar.gz > >> > >> Can somebody update the server? > >> Best regards, > >> Alex > >> > >> > >> On Wed, Jul 18, 2012 at 1:30 PM, Alexander Barth > >> <barth.alexan...@gmail.com <mailto:barth.alexan...@gmail.com>> > wrote: > >> > Dear all, > >> > > >> > I have released a new package called ncArray for manipulating > netcdf > >> > files. It depends on the functions ncread, ncwrite and ncinfo from > >> > octcdf. Maybe someday, these functions will be implemented in > octave > >> > (as they are in matlab) and ncArray will be independent from > octcdf. > >> > > >> > The package allows to access a single or a collection of > NetCDF files > >> > (or OPeNDAP URLs) as a multi-dimensional array. > >> > For a collection of NetCDF files, the variables are > concatenated along > >> > a given dimension similar to the command cat. The ncArray object > >> > contains only a reference to the underlying files. The data is > loaded > >> > only, if the array is indexed. > >> > > >> > For example, if the current directory containts file1.nc > <http://file1.nc>, file2.nc <http://file2.nc> and > >> > file3.nc <http://file3.nc> and each file contains the 20 x 30 > variable temp, then: > >> > > >> > A = ncCatArray(3,'file*.nc','temp') > >> > > >> > would create and array A of size 20 x 30 x 3 without actually > loading > >> > the files. Only when the array is index e.g., A(:,:,2:3), the file > >> > file2.nc <http://file2.nc> and file3.nc <http://file3.nc> are > loaded. > >> > > >> > Also, reduction operators are implement. For example, sum(A,3) > would > >> > compute the sum over the 3rd dimension and sequentially > loading all > >> > files. > >> > > >> > ncArray allows thus to write code for dataset which are too > big to be > >> > loaded in memory and still to write code that are independent > on the > >> > way the data is stored and how a data set is split across files. > >> > > >> > More example how to use this package are available here: > >> > http://modb.oce.ulg.ac.be/mediawiki/index.php/NcArray > >> > > >> > Best rega > >> > > > > Is there a reason not to integrate these functions into the > octcdf package > > directly? > > > > Michael. > > > > Yes, ncArray contains pure m-scripts that work also with matlab. > octcdf is mostly written in C++ code that are specific to octave. A > matlab user thus only needs the package ncArray. > > > OK, thanks. I was just asking, because from a packager point of view, > the proliferation of single niche-specific packages is a pain and > increases the workload. For instance, I would also see ncArray to fit > into the io package.
Michael, You mean (Linux) distro packagers? Binary Octave distribution packagers? If so, I see your point, but packagers and OF package maintainers may have a few opposite interests. The io package may not be a good example here as by its very nature it constitutes a sort of dumping ground for all kinds of I/O code. OTOH because of that, it does have some fine examples for the issues below: (A) Right now in the io package there are already several functions that I cannot maintain as I'm more or less clueless about: (1) What purpose they serve (Nastran PCH?); (2) Because of (1), how they relate to other OF or core Octave functions; (3) How they actually work. Several contributed function files lack even the most basic code documentation (xmlread/-write), let alone formal tests (everything save the spreadsheet stuff which has test scripts). Just don't mention documentation for users. Adding in functions maintained by someone else might work but I have trouble imagining how that would help reduce total workload (for who?). In contrast, I think smaller packages would help distribute workload for maintainers in a more natural way. Plus, if a package maintainer disappears and the package becomes orphaned, it would be isolated and not silently pollute better maintained packages with unmaintained and bit-rotting code. What may help packagers here is some development setup that allows automated building all OF packages with just "one or two" commands. I'm afraid most of such a setup would need to be at the packagers' side. (B) Another issue is formed by the growing dependency chains of OF packages. As to io, I'd frown on having it also depend on the octcdf package. It would imply that the statistics package, which since a few months depends on io (because of just one function), depends on the octcdf package in turn. Etc. I suppose these dependency chains increase complexity, viz. workload, for packagers. Am I wrong here? So, contrary to your packagers' POV, as package maintainer I'd rather have a wider collection of smaller OF packages, perhaps even with overlapping functionality, but with clear distinctions between (sub-)purpose, dependencies and between maintained and unmaintained code. Philip ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Octave-dev mailing list Octave-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/octave-dev
