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/982ad1aa1a82b9bcd29c5b6a6e6b...
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:
- graceful handling of binary incompatibility between core <>
externals of different precision
make it work for Windows too
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 msp@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.)