From: Victor Lazzarini <Victor.L<azzarini@nu...> - 2011-08-22 08:06:38
I guess this is what Richard Dobson envisaged, to keep in line with
disk storage, which is 32-bit.
I think we can move all that to MYFLT, but just make sure that
anything that writes or reads to disk is 32bit.
On 22 Aug 2011, at 08:53, john ffitch wrote:
> Throughout the PVS code there are remarks that some fields must be
> 32bit (ie floats). Why? I cannot see why we do not use doubles for
> spectral code. What am I missing?
> ==John ffitch
> uberSVN's rich system and user administration capabilities and model
> configuration take the hassle out of deploying and managing
> Subversion and
> the tools developers use with it. Learn more about uberSVN and get a
> download at: http://p.sf.net/sfu/wandisco-dev2dev
> Csound-devel mailing list
Dr Victor Lazzarini
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie
From: Richard Dobson <richarddobson@bl...> - 2011-08-22 09:53:50
On 22/08/2011 09:06, Victor Lazzarini wrote:
> I guess this is what Richard Dobson envisaged, to keep in line with
> disk storage, which is 32-bit.
> I think we can move all that to MYFLT, but just make sure that
> anything that writes or reads to disk is 32bit.
Yes, the file format is only defined for 32bits (doubles would be
extravagant to a fault, and make for even more huge files than we
already have, and is really not necessary). The pvoc engine itself can
certainly be in doubles (and will in some situations give clearly better
quality, especially for the SPV - all to do with the phase accumulate
aspect); my code comments ~should~ all relate to reading/writing a
PVOCEX file. IIRC the code respects/employs the standard "in-memory"
loading of files (in effect, a plain load into a generic Csound memory
buffer), so that the float requirement may be more extensive than might
be expected. Whether that memory buffer itself can be in doubles
(arguably unnecessary) depends entirely on whether that is felt to be
reasonable (can swallow up memory really quickly), and whether it might
lead to more extenseive changes elsewhere that might not be convenient.
It would also depend on the overhead in converting between floats and
doubles; which may or may not have an impact on real-time performance.