<div dir="ltr">Hello Jonathan,<div>I have started with the proposal and I had a few doubts, </div><div>I wanted to ask you if there is a specific list of external libraries that you want me to include in this project?</div><div>Also can you please explain to me a little bit about the testing of purr-data and the in general?<br></div><div>Also I have attached a link to my proposal draft below. Could you please review it and tell me if I am going in the right direction with it and how can I further improve it?<br></div><div><br></div><div>Thanks.<br></div><div><br></div><div><a href="https://docs.google.com/document/d/1iX5obdBEbLhn0pe72ef2kuyHx20qlD7B7I7bYHl5kCQ/edit?usp=sharing">Link to proposal</a> </div><div><br></div><div>Sincerely,</div><div>Pranay Gupta</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Mar 24, 2018 at 3:27 AM, Jonathan Wilkes <span dir="ltr"><<a href="mailto:jon.w.wilkes@gmail.com" target="_blank">jon.w.wilkes@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Pranay,<br>
<br>
I'll respond point by point for clarity below.<br>
<span class=""><br>
On Fri, Mar 23, 2018 at 1:33 PM, pranay gupta<br>
<<a href="mailto:pranayguptastudent@gmail.com">pranayguptastudent@gmail.com</a>> wrote:<br>
> Hello Jonathan,<br>
><br>
> I have gone through all the mails and tried to go through some files also,<br>
> what I understood was that, wherever algorithms have been implemented using<br>
> single precision I have to change that to double precision and some external<br>
> libraries that are being called in the core functions might also need<br>
> changes.<br>
<br>
</span>There are basically two categories of work: the core and the external<br>
libraries (essentially plugins) which ship with Purr Data.<br>
<br>
For the core there is prior art with the Pd Double project which can<br>
be found here:<br>
<br>
<a href="https://github.com/pd-projects/pd-double" rel="noreferrer" target="_blank">https://github.com/pd-<wbr>projects/pd-double</a><br>
<br>
One of the challenges here is that our core code has diverged substantially<br>
from that codebase. However, the overall structure of the code is still very<br>
similar as are the core DSP algorithms and message dispatching/parsing<br>
code.<br>
<br>
The second category-- external libraries-- is a bit more<br>
difficult because the quality varies considerably for each library.<br>
Some of them are straightfoward and just require recompiling<br>
and testing. Some freely mix "t_float" and "float", probably under<br>
the assumption that the "t_float" type would never change. Still<br>
others may use type-punning or other tricks that depend on<br>
"t_float" being equal to "float".<br>
<br>
I think a workable approach here is to prioritize a handful of these<br>
libraries to make ready for double precision and then document<br>
common types of problems for the rest. That is to say I don't think<br>
this project idea needs to aim to make every single library ready<br>
for double precision.<br>
<span class=""><br>
> Also, support for backward compatibility, and an option to the<br>
> users whether to run purr date using single precision or double precision<br>
> should be added.<br>
<br>
</span>I don't think this is possible. The public API essentially<br>
requires external library developers to typecast raw pointers to<br>
arrays of t_float. So either everything is compiled with a<br>
uniform t_float value, or you get either:<br>
<br>
a) data corruption (double-precision mode with single-instance library loaded)<br>
b) data corruption and buffer overflow (single-precision mode with<br>
double-precision lib)<br>
<br>
I'm actually just guessing on the type of errors-- there may be<br>
some part of the API I'm forgetting which causes crashes in both cases.<br>
<span class=""><br>
> And in case any of the single precision or double precision<br>
> catches an error, the one that works has to be used.<br>
<br>
</span>As above, I don't think that's possible. But we can test both<br>
precision types in the CI (perhaps switching out one of the older<br>
Ubuntu runners for a single precision build runner).<br>
<span class=""><br>
> Also, you mentioned<br>
> about single precision binaries performing better with better algorithms as<br>
> compared to double precision with a basic implementation when compared to<br>
> vanilla binaries as per the results of some tests.<br>
<br>
</span>I didn't measure any difference on my Rockchip Chromebook.<br>
But I'd say it would be a good idea to set up some performance<br>
tests to measure the differences.<br>
<span class=""><br>
><br>
> I had a few doubts regarding the project,<br>
><br>
> 1) What should be the main points that I should focus more on in my<br>
> proposal?<br>
<br>
</span>Probably on making it possible to compile Purr Data for both types<br>
of precision, to make sure the core runs reliably in each case, and<br>
to make sure some of the more popular external libraries run reliably<br>
in each and document a process for testing/working on the rest.<br>
<span class=""><br>
><br>
> 2) Also will any of the algorithms that are already implemented require any<br>
> implementation changes when adding support for double precision?<br>
<br>
</span>In the core-- yes. These were replaced and tested with new implementations<br>
in the pd double project. I *think* they are the files assigned to the<br>
TYPE_PUNNING_SRC variable in purr-data/pd/src/<a href="http://makefile.in" rel="noreferrer" target="_blank">makefile.in</a>.<br>
<span class=""><br>
><br>
> 3) And it would be really helpful if you could provide me a few resources<br>
> that might make it easier for me to understand the project better?<br>
<br>
</span>General resources or specific to this project idea?<br>
<br>
For the former-- here's a great resource Albert created:<br>
<br>
<a href="https://agraef.github.io/purr-data-intro/" rel="noreferrer" target="_blank">https://agraef.github.io/purr-<wbr>data-intro/</a><br>
<br>
Let us know if you have any more questions.<br>
<div class="HOEnZb"><div class="h5"><br>
-Jonathan<br>
______________________________<wbr>_________________<br>
L2Ork-dev mailing list<br>
<a href="mailto:L2Ork-dev@disis.music.vt.edu">L2Ork-dev@disis.music.vt.edu</a><br>
<a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer" target="_blank">https://disis.music.vt.edu/<wbr>listinfo/l2ork-dev</a></div></div></blockquote></div><br></div>