[L2Ork-dev] New developer interested in doing a GSOC18 project

[pranay gupta]

Hello Jonathan,
I have started with the proposal and I had a few doubts,
I wanted to ask you if there is a specific list of external libraries that
you want me to include in this project?
Also can you please explain to me a little bit about the testing of
purr-data and the in general?
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?

Thanks.

Link to proposal
<https://docs.google.com/document/d/1iX5obdBEbLhn0pe72ef2kuyHx20qlD7B7I7bYHl5kCQ/edit?usp=sharing>


Sincerely,
Pranay Gupta

On Sat, Mar 24, 2018 at 3:27 AM, Jonathan Wilkes <jon.w.wilkes at gmail.com>
wrote:

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