The diffs are helpful - I would probably want to go and re-do all the edits by hand to be sure I understand everything. A couple of things probably will need tweaking to get it all up to date too.
The binary compatibility problem needs careful thought. I think the ugliest issue is that for Macintosh, the fat binary format can't very easily hold two versions of the same extern, same architecture, but different float types - so there would have to be d_fat with 32-bit and IA64, 32-bit-float versions (as now) and yet another extent (.d_double?) to hold the 64-bit-double version in a separate file. Yuck.... But all doable. cheers Miller On Tue, Feb 03, 2015 at 06:16:39PM +0100, katja wrote: > A set of 'double precision' diffs is on Pd-double github as the patch > files were applied in a single commit on vanilla 0.43 (in 2011): > > https://github.com/pd-projects/pd-double/commit/982ad1aa1a82b9bcd29c5b6a6e6b597675d5f300 > > The patch set may need some modifications and additions to make it > work for Pd 0.46, but more important, the following was still left to > be done: > > 1. graceful handling of binary incompatibility between core <> > externals of different precision > > 2. make it work for Windows too > > 3. type-specify t_float literals consistently throughout the code > > > My focus was to make Pd work in double precision builds while at the > same time preserving all functionality and performance in single > precision builds. For Linux and OSX on Intel this was tested OK. > Nowadays one would include ARM platforms in the tests. Unlike Intel, > ARM isn't so fond of doubles, therefore it's extra important to > type-specify all t_float literals to avoid unintended conversions. > > Regarding binary incompatibility between builds of different > precision, this is a serious problem which can't be resolved under the > quick-and-easy approach of specifying t_float at compile time. I would > therefore suggest that double precision binaries should not be > distributed until we have at least some method to prevent loading > externals of the wrong precision. In the meantime, the curious could > build double precision from source for evaluation, at their own risk. > > Whether the benefits of double precision will outweigh the dangers, is > impossible to say because the benefits vary with the purpose someone > has for using Pd. When working on Pd-double in 2011 I was interested > in 'scientific' applications of Pd like impulse response measurement, > where double precision is crucial in some calculations. My current > focus is more on live performance and I've never felt a need for > doubles in this realm. Still I would be happy to help out with > doublyfication of Pd 0.46. Shouldn't we have freedom of precision? > > By the way here's a video about precision in Pd, with the latter part > showing double precision in action: > > https://www.youtube.com/watch?v=93632nc8LVs > > Katja > > > On Mon, Feb 2, 2015 at 7:58 PM, Miller Puckette <m...@ucsd.edu> wrote: > > More than that - I'm hoping to look at Katja's version and adopt the > > changes, > > whether or not there turns out to be a set of formatted diffs available > > anywhere... > > > > cheers > > M > > > > > > On Mon, Feb 02, 2015 at 06:34:54PM +0000, Jonathan Wilkes via Pd-list wrote: > >> One other question: would you accept patches for Pd Vanilla that make it > >> _possible_ to compile with t_float at double-precision (something Pd > >> Vanilla cannot currently do)? That would give the Pd Vanilla user the > >> option to compile to double-precision if they wish, which IIUC is the > >> whole point of t_float in the first place. (Plus Vanilla users would get > >> the small performance increase in the relevant tilde classes.) > >> _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list