Hello dev list,
In recent months I changed some lines in Pd core code to make it double-precision-compilable. I'd like to help a bit with making Pd-extended ready for double precision as well. After puzzling on repository layout and build system, and figuring out a decent test method (together with Fred Jan Kraan), I am now ready to commit rewritten lines for one external lib, creb. It is for this library that I want to request commit access now, but it doesn't stop here. A brief description of the project:
Pd-double is a fork of Miller Puckette's Pure Data, patched with mentioned double-ready lines. It has (and will continue to have) the same API, apart from the option to compile in single or double precision at will. Pd-double enables double precision builds of vanilla Pd, and is tested to work well on OSX and Linux. I still have to work on the Windows side of things. In the meantime Pd-double is useful as a framework against which external libraries can be developed towards double-readiness. A usable development setup is described on http://puredata.info/dev/pd-double/PdDoubleDevelopment. Convenient unit-test abstractions are introduced here: http://www.katjaas.nl/pdunittests/pdunittests.html. I'd like to invite all Pd-devs to join in. Rewriting and testing classes assumes a fair knowledge of their functioning, and Pd-extended is huge. For me, doing one lib at a time works well, thoroughly testing the whole of it before committing. When starting on another lib, I'll ask commit access again. I could also submit patch files instead, if that is preferred in some case.
A few words on my background so you know who's wanting to poke in your code. During a one-year course at the Sonology Department of the Hague Conservatory (Holland), I learned the basics of dsp math and programming. That was 2007-2008, and I've never stopped music programming since, documenting my efforts and experiments on www.katjaas.nl. Pd has become my favourite environment, because of it's open source and active community, and because I like how you can prototype a neat audio tool quite fast, with GUI and all, while C code is still an option to solve details. A few Pd-externals and projects are shared online via mentioned site (nb 'slicycle' stuff and [soundtouch~]). I teach Pd workshops sometimes. The single-precisioness of Pd has been my only serious gripe. See http://www.katjaas.nl/doubleprecision/doubleprecision.html for illustrations of precision-bottlenecks. Working on this topic, I hope to contribute to the wonderful tool and the community supporting it.
Katja
Hey Katja,
Nice introduction, I am looking forward to your commits. I'll just let this sit a little bit for our lazy consensus then add you.
.hc
On Oct 31, 2011, at 9:44 PM, katja wrote:
Hello dev list,
In recent months I changed some lines in Pd core code to make it double-precision-compilable. I'd like to help a bit with making Pd-extended ready for double precision as well. After puzzling on repository layout and build system, and figuring out a decent test method (together with Fred Jan Kraan), I am now ready to commit rewritten lines for one external lib, creb. It is for this library that I want to request commit access now, but it doesn't stop here. A brief description of the project:
Pd-double is a fork of Miller Puckette's Pure Data, patched with mentioned double-ready lines. It has (and will continue to have) the same API, apart from the option to compile in single or double precision at will. Pd-double enables double precision builds of vanilla Pd, and is tested to work well on OSX and Linux. I still have to work on the Windows side of things. In the meantime Pd-double is useful as a framework against which external libraries can be developed towards double-readiness. A usable development setup is described on http://puredata.info/dev/pd-double/PdDoubleDevelopment. Convenient unit-test abstractions are introduced here: http://www.katjaas.nl/pdunittests/pdunittests.html. I'd like to invite all Pd-devs to join in. Rewriting and testing classes assumes a fair knowledge of their functioning, and Pd-extended is huge. For me, doing one lib at a time works well, thoroughly testing the whole of it before committing. When starting on another lib, I'll ask commit access again. I could also submit patch files instead, if that is preferred in some case.
A few words on my background so you know who's wanting to poke in your code. During a one-year course at the Sonology Department of the Hague Conservatory (Holland), I learned the basics of dsp math and programming. That was 2007-2008, and I've never stopped music programming since, documenting my efforts and experiments on www.katjaas.nl. Pd has become my favourite environment, because of it's open source and active community, and because I like how you can prototype a neat audio tool quite fast, with GUI and all, while C code is still an option to solve details. A few Pd-externals and projects are shared online via mentioned site (nb 'slicycle' stuff and [soundtouch~]). I teach Pd workshops sometimes. The single-precisioness of Pd has been my only serious gripe. See http://www.katjaas.nl/doubleprecision/doubleprecision.html for illustrations of precision-bottlenecks. Working on this topic, I hope to contribute to the wonderful tool and the community supporting it.
Katja
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin
I'm ready to add you, but I couldn't find your sourceforge account name. Can you send it?
.hc
On Oct 31, 2011, at 9:44 PM, katja wrote:
Hello dev list,
In recent months I changed some lines in Pd core code to make it double-precision-compilable. I'd like to help a bit with making Pd-extended ready for double precision as well. After puzzling on repository layout and build system, and figuring out a decent test method (together with Fred Jan Kraan), I am now ready to commit rewritten lines for one external lib, creb. It is for this library that I want to request commit access now, but it doesn't stop here. A brief description of the project:
Pd-double is a fork of Miller Puckette's Pure Data, patched with mentioned double-ready lines. It has (and will continue to have) the same API, apart from the option to compile in single or double precision at will. Pd-double enables double precision builds of vanilla Pd, and is tested to work well on OSX and Linux. I still have to work on the Windows side of things. In the meantime Pd-double is useful as a framework against which external libraries can be developed towards double-readiness. A usable development setup is described on http://puredata.info/dev/pd-double/PdDoubleDevelopment. Convenient unit-test abstractions are introduced here: http://www.katjaas.nl/pdunittests/pdunittests.html. I'd like to invite all Pd-devs to join in. Rewriting and testing classes assumes a fair knowledge of their functioning, and Pd-extended is huge. For me, doing one lib at a time works well, thoroughly testing the whole of it before committing. When starting on another lib, I'll ask commit access again. I could also submit patch files instead, if that is preferred in some case.
A few words on my background so you know who's wanting to poke in your code. During a one-year course at the Sonology Department of the Hague Conservatory (Holland), I learned the basics of dsp math and programming. That was 2007-2008, and I've never stopped music programming since, documenting my efforts and experiments on www.katjaas.nl. Pd has become my favourite environment, because of it's open source and active community, and because I like how you can prototype a neat audio tool quite fast, with GUI and all, while C code is still an option to solve details. A few Pd-externals and projects are shared online via mentioned site (nb 'slicycle' stuff and [soundtouch~]). I teach Pd workshops sometimes. The single-precisioness of Pd has been my only serious gripe. See http://www.katjaas.nl/doubleprecision/doubleprecision.html for illustrations of precision-bottlenecks. Working on this topic, I hope to contribute to the wonderful tool and the community supporting it.
Katja
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
"[T]he greatest purveyor of violence in the world today [is] my own government." - Martin Luther King, Jr.
Hello Hans,
My sourceforge account name is 'katjav'. Thanks for adding me. As mentioned, creb is the first lib tested ok in double precision. In the meantime I've also done smlib. There's unit tests for all objects in both libs. So I'd like to commit code and tests. The question is still where to put the tests in the directory layout, and get them installed. But that question is for another thread.
Katja
On Thu, Nov 3, 2011 at 3:57 AM, Hans-Christoph Steiner hans@at.or.at wrote:
I'm ready to add you, but I couldn't find your sourceforge account name. Can you send it?
Ok, you should be in everything, bug/patch tracker, SVN, shell access, SF site editor, etc. Welcome!
For tests, I'm going to start a new thread on that topic.
.hc
On Nov 3, 2011, at 5:28 AM, katja wrote:
Hello Hans,
My sourceforge account name is 'katjav'. Thanks for adding me. As mentioned, creb is the first lib tested ok in double precision. In the meantime I've also done smlib. There's unit tests for all objects in both libs. So I'd like to commit code and tests. The question is still where to put the tests in the directory layout, and get them installed. But that question is for another thread.
Katja
On Thu, Nov 3, 2011 at 3:57 AM, Hans-Christoph Steiner hans@at.or.at wrote:
I'm ready to add you, but I couldn't find your sourceforge account name. Can you send it?
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith
So now that Katja has a nice testing patch and has written a bunch of tests, I think we need to nail down a standard naming and location for the tests. I think that 'unittest' should be the standard name for them. Then the patches will be called 'osc~-unittest.pd', the library subfolder will be called 'unittests', and then I think we need a new section in trunk called 'unittests'.
This 'unittests' section will be for unit test patches that are not specific to a single library, but test interactions between objects from different libraries. It could also be the place where all of the testing frameworks go, like the scripts that automate the running of the tests, the *-unittest.pd templates, etc.
How does that sound?
.hc
Oops, I think I left one thing unclear in this proposal:
- each library would have a 'unittests' folder for the tests that are specific to that library. Ideally each object would have a test patch in the 'unittests' subfolder in the library, but we're a ways off of that.
.hc
On Nov 3, 2011, at 10:27 AM, Hans-Christoph Steiner wrote:
So now that Katja has a nice testing patch and has written a bunch of tests, I think we need to nail down a standard naming and location for the tests. I think that 'unittest' should be the standard name for them. Then the patches will be called 'osc~-unittest.pd', the library subfolder will be called 'unittests', and then I think we need a new section in trunk called 'unittests'.
This 'unittests' section will be for unit test patches that are not specific to a single library, but test interactions between objects from different libraries. It could also be the place where all of the testing frameworks go, like the scripts that automate the running of the tests, the *-unittest.pd templates, etc.
How does that sound?
.hc
----------------------------------------------------------------------------
Mistrust authority - promote decentralization. - the hacker ethic
On Thu, Nov 3, 2011 at 3:28 PM, Hans-Christoph Steiner hans@at.or.at wrote:
- each library would have a 'unittests' folder for the tests that are specific to that
library. Ideally each object would have a test patch in the 'unittests' subfolder in the library, but we're a ways off of that.
If I understand you well, one would get a subdir 'unittests' for every lib like so: externals/creb/unittest/, externals/miXed/cyclone/unittest/, externals/unauthorized/unittest/ etc. A copy of the test abstractions should be in every lib's unittest/ dir, no? (In case a lib is copied individually from SVN).
A few remarks on unit test abstractions. There's two flavours now:
- [unit-test-frame~] for signal objects - [unit-test-frame] for control objects with numeric output (floats and/or lists of floats)
Both flavours store a 512 points reference file as 32 bit float .wav, the most precise storage method in single precision vanilla Pd. See http://www.katjaas.nl/pdunittests/pdunittests.html for screenshots and .zip file with abstractions and some examples.
Of course, when testing an object, all other objects in the test patch are part of the system under test as well. This is not only a theoretic concern, as I soon found when testing double-precision-built externals against their Pd-extended 0.42 reference. Signal classes in Pd are designed for speed, not for accuracy. It is sometimes inevitable to accumulate inaccuracies, for example when using [phasor~] as test input signal for a filter object. Obviously, it is impossible to test the exact accuracy of double precision objects against a reference in single precision. Large deviations tell real troubles, that is where the tests are most useful. For example, when a double is read as type float due to erroneous pointer aliasing, output is totally ridiculous. Or aggressive optimization may sometimes induce unintended order of operations, mostly leading to crap output.
For all creb and smlib classes, unit tests are now written in this sense, over 70 tests together. A fraction of the total to be done for Pd-extended. Test development still takes more time than the actual rewriting of bits in the code, even while the test abstractions save loads of work. But for Pd-double in particular, it is indispensable.
Katja
On Nov 3, 2011, at 3:56 PM, katja wrote:
On Thu, Nov 3, 2011 at 3:28 PM, Hans-Christoph Steiner hans@at.or.at wrote:
- each library would have a 'unittests' folder for the tests that are specific to that
library. Ideally each object would have a test patch in the 'unittests' subfolder in the library, but we're a ways off of that.
If I understand you well, one would get a subdir 'unittests' for every lib like so: externals/creb/unittest/, externals/miXed/cyclone/unittest/, externals/unauthorized/unittest/ etc.
Right, that's what I'm thinking, except having the folder called 'unittests' for grammatical consistency.
A copy of the test abstractions should be in every lib's unittest/ dir, no? (In case a lib is copied individually from SVN).
I think the test abstractions should probably be distributed as a regular library, and included in Pd-extended.
A few remarks on unit test abstractions. There's two flavours now:
- [unit-test-frame~] for signal objects
- [unit-test-frame] for control objects with numeric output (floats
and/or lists of floats)
Both flavours store a 512 points reference file as 32 bit float .wav, the most precise storage method in single precision vanilla Pd. See http://www.katjaas.nl/pdunittests/pdunittests.html for screenshots and .zip file with abstractions and some examples.
Of course, when testing an object, all other objects in the test patch are part of the system under test as well. This is not only a theoretic concern, as I soon found when testing double-precision-built externals against their Pd-extended 0.42 reference. Signal classes in Pd are designed for speed, not for accuracy. It is sometimes inevitable to accumulate inaccuracies, for example when using [phasor~] as test input signal for a filter object. Obviously, it is impossible to test the exact accuracy of double precision objects against a reference in single precision. Large deviations tell real troubles, that is where the tests are most useful. For example, when a double is read as type float due to erroneous pointer aliasing, output is totally ridiculous. Or aggressive optimization may sometimes induce unintended order of operations, mostly leading to crap output.
For all creb and smlib classes, unit tests are now written in this sense, over 70 tests together. A fraction of the total to be done for Pd-extended. Test development still takes more time than the actual rewriting of bits in the code, even while the test abstractions save loads of work. But for Pd-double in particular, it is indispensable.
The standard deviation stuff is definitely very valuable, its great you got that working.
.hc
----------------------------------------------------------------------------
I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone." --Bjarne Stroustrup (creator of C++)
On Thu, Nov 3, 2011 at 10:06 PM, Hans-Christoph Steiner hans@at.or.at wrote:
I think the test abstractions should probably be distributed as a regular library, and included in Pd-extended.
That is easier to manage indeed. So you would have externals/unittests/ with abstractions, and dirs like externals/creb/unittests/ with the actual tests, only working when the unittest lib is loaded. With the unit tests being dependent on a unittests lib, there should be a readme in each lib's unittests/ subdir about that. Additional unit test abstractions could be developed, for example to test objects with symbol output messages. But wait, does it all make sense.... The unit tests are in SVN, but not included in the build packages. Why have externals/unittest/ lib then? Or is it your intention to include unit tests in the distributed builds as well?
Katja
On Nov 3, 2011, at 7:48 PM, katja wrote:
On Thu, Nov 3, 2011 at 10:06 PM, Hans-Christoph Steiner hans@at.or.at wrote:
I think the test abstractions should probably be distributed as a regular library, and included in Pd-extended.
That is easier to manage indeed. So you would have externals/unittests/ with abstractions, and dirs like externals/creb/unittests/ with the actual tests, only working when the unittest lib is loaded. With the unit tests being dependent on a unittests lib, there should be a readme in each lib's unittests/ subdir about that. Additional unit test abstractions could be developed, for example to test objects with symbol output messages. But wait, does it all make sense.... The unit tests are in SVN, but not included in the build packages. Why have externals/unittest/ lib then? Or is it your intention to include unit tests in the distributed builds as well?
I think the library of abstractions should be called something other than 'unittests', more like 'testbed', 'testframework', 'testtools', 'testy', or whatever.
The idea of the library structure is to have everything that the library needs in the library's folder. So for example the Makefile is included there, and works as a standalone Makefile, or with Pd-extended. If someone distributes a library, it shouldn't need things outside of its folder to work. Obviously, it would need Pd somewhere, and for the tests, it would need the testing framework.
.hc
----------------------------------------------------------------------------
"Free software means you control what your computer does. Non-free software means someone else controls that, and to some extent controls you." - Richard M. Stallman
-
Hans-Christoph Steiner -
katja