[PD] more about float limitation

[Miller Puckette]

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 <msp at 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.)
> >>