David Bateman wrote:
>It also includes a support oct-file _errcore.cc that makes biterr.m and
>symerr.m run in a reasonable time without relying on the bitxor.oct file
>from another directory of octave-forge.
>
I haven't looked, but matlab's bit functions work on 'flints', which use
the 53(?)
bit mantissa of floating point numbers, whereas Kai Habel's functions use
32 bit integers. I don't know how matlab's or your biterr is
implemented, but
that is something to look out for.
As for relying on other octave forge directories, this is a problem.
We've avoided it so far by delivering octave-forge as a monolithic
entity, but that will fail as octave-forge expands.
One strategy is to use Matlab's distribution system. When a
function is needed by another toolbox, it is included in both,
but both install to the same place so there is no ambiguity.
I don't know what happens if you install a new signal processing
toolbox beside an old image processing toolbox, but it might
be that you have to update all the toolboxes when you
update the core, so this is never an issue.
Another strategy is to layer the toolboxes. If you want to
install image or comm, you must first install signal for example.
This runs into the same consistency problems.
A third strategy is to copy e.g., the necessary signal processing
functions into the image toolbox before building the
image toolbox distribution. For this strategy to work we
will need some sort of namespace mechanism in octave
so that a directory can have private copies of public names.
You could do this by renaming, e.g., conv to image_conv
when copying it from the signal to the image directory, and
using the name image_conv internally.
A fourth strategy is to put all functions shared by multiple
packages in a common base so that the remaining
packages are much more independent of each other.
Picking and choosing functions from other directories
becomes particularly problematic if those functions
are C++ functions. They may require configuration
steps to check the availability of certain libraries and
functions, and they may have complicated build
rules. So rather than having one configure file per
directory, each oct file will have to carry its own
dependency/configure/build information.
For now I'm inclined to be lazy and stick with the monolith.
If anyone is feeling inspired they can break it up into packages.
BTW, it would be especially nice if whatever packaging tools
we create would also support installing for matlab (after
suitable source munging of course).
>The tar-ball also includes modified versions of
>
>Makefile
>randint.cc
>comms.txi
>INDEX
>
>with addition of functions, typos in the doc and a bug in randint fixed.
>
>Must have been bored if I found the time to do these functions, what with
>all the work I have at the moment. Anyway, the comm directory of octave-forge
>is looking more like Matlab every day :-)
>
It's like potato chips --- its very hard to
writing just one more simple function. E.g.,
I had no business writing strsort yesterday,
which with the help of dispatch and PKG_ADD,
allows you to write s = sort('string').
Paul Kienzle
pki...@us...
|
