Hi Toby,
> So, GSoC 2013 is drawing to a close. I've got a tarball produced by
> `make dist-src` on my branch that will build and install PyViennaCL for
> Python 2 and Python 3 (depending on how you configure it, with Python 3
> as default for now).
Very nice! :-)
> Now,
> there are a couple of quirks remaining with the vector tests (such that
> I had to disable the inner product test because NumPy doesn't seem to be
> precise enough as I've written it, and because using slice and range on
> vectors seems to produce a weird result for the scaled add test), but
> the crucial stuff passes fine.
Are you sure about the lack of precision in NumPy? Do you get relative
errors in the 10^{-6} range? Please let me know if there are any issues
with slice and range (or any other operations) in whatever scenarios.
> The tarball is versioned as 1.4.998-py, because I want to clean some
> final things up before I call it a release (at version 1.5.0), but
> obviously I want something tangible to submit for the end of
> GSoC.
I think we should use a similar model as e.g. for the KDE development
libraries, i.e. ViennaCL and pyViennaCL each have their own version
numbers. For consistency, I opt for starting with PyViennaCL 1.0.0,
increment the last digit whenever minor bug fixes (or similar) without
changing the API are introduced, and increment the digit in the center
whenever features are added.
> Here's my list of things for the first release:
>
> + Fix vector_operations test
> + Add __all__ and __version__, so that docs are prettier
> + Fix sphinx warnings
> + Decide on version scheme
> (useful to have a separate version number for the extension
> only, to keep track of features added and bugs fixed given a
> different schedule and different demands)
> [perhaps: ViennaCLVersion.PyViennaCLVersion, eg, 1.5.0.1]
> + Auto-determine Python / Boost-Python version
> + Debian package
Great, that looks like a pretty short list already. I'm slowly
recovering from the relocation pain and find some time for
science/coding again, so I can help you with platform tests and the like.
> Most of those are pretty straightforward (maybe excepting the
> range/slice issue on the vector test), which I'll report more formally
> on in a couple of days. The important things for me, for the first
> release, are sorting out the automatic determination of the Python
> version etc, and the PyViennaCL versioning scheme.
I think the most important bits and pieces for the first release are the
installation and the documentation. There is no existing user base yet,
so everybody *has* to go through this step. We don't want to lose any
users during these first steps, do we?
> Oh, and I coded up and added tests for the elementwise exponentiation,
> and added support for (u)int and (u)long integer types. char and short
> seem more problematic, but I don't mind about those. When the outer
> product for vectors becomes available in the scheduler, I can easily add
> that, too. For now, it's still just computed the old way.
char/short and outer products will be fixed within the next few days.
> So, for submission, I don't know what's best or correct. Is there
> somewhere I should upload this tarball? As for build dependencies, they
> are as before, just with the addition of "sphinx" for Python
> documentation. On Ubuntu, it's in the package, `python-sphinx`.
>
> The tarball is called, `ViennaCL-1.4.998-py-src.tar.gz`.
You should get instructions for the upload via email directly from
Google during this week. So far this has always been a fairly painless
process, so no need to worry about it :-)
> Finally, the build process is RAM intensive right now. An item on my
> roadmap for my second release (after I've got the basic first 1.5.0
> release out) is splitting up the C++ source so that it requires less
> than four gigabytes of memory. Which it does at the moment, with g++ 4.8
> and Boost 1.53 on my system.
Hmm, this is indeed a lot. Do you consistently use vector_base and
matrix_base as types for functions in order to avoid an explosion of
instantiation for {vector, vector_range, vector_slice} and {matrix,
matrix_range, matrix_slice}?
Best regards,
Karli
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
ViennaCL-devel mailing list
ViennaCL-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/viennacl-devel
