Hello,
I did another array-update performance test, following Jonathan's earlier suggestion. A 800 pt array (this is also the visual size) is updated every 50 milliseconds. This is very cpu-intensive anyhow. For Pd-double ~4% more than for Pd-extended 0.43.1. Pd-double translates a number to maximally 20 characters (like in -0.00029718922544271) and Pd-extended to a maximum of 12 characters (like in -0.000958107). The small performance difference indicates that the conversions are relatively fast, compared to other aspects of the array update. Indeed, Tcl code is responsible for most of the cpu load in array updates. I've checked it with Shark.app performance profiler.
It seems to me that an ASCII decimal representation with more decimal digits, like the %.14lg used in Pd-double, does not seriously hurt (the performance of) storage and transmission to Pd-gui. When printing numbers in boxes on screen however, simply using more than six significant decimals would not give the desired effect for single precision numbers.
Since printing numbers in boxes happens relatively seldom, a more detailed routine could be spent on that, to display the desired precision. In the sense of Miller's suggestion, convert a number as typed in a box into a number representable by Pd's float type. Allow numbers to be printed with full precision up to a reasonable number of significant decimal digits For example, %lg14 no matter what float type, would be sufficient for all practical purposes. However, numbers should not be printed with more characters than originally typed in the box. If you'd type 4294967297 it would be converted to 4294967296 (in single precision case). But if you typed 0.01, Pd should not print 0.0099999999977648.
Katja
On Wed, Apr 11, 2012 at 10:01 PM, Miller Puckette msp@ucsd.edu wrote:
Hi all -
this section 9.3.1 describes how to convert strings to numbers - but isn't the real problem how Pd converts numbers to strings?
I think the ideal solution when the number of characters isn't an issue is to specify that whatever prints out should be a string that, when scanned using scanf("%f", ...) (or scanf("%lf", ...)) returned the exact 32-bit number. I'm not 100% sure this is possible, since there might be 32 bit values that scanf can't ever return, but I bet there's a way to get really really close :)
Miller
On Wed, Apr 11, 2012 at 09:35:14PM +0200, Krzysztof Czaja wrote:
On 04/10/2012 02:20 PM, katja wrote: ...
http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf
Then in section 9 the conversion rules are presented in greatest detail, with 'number to string' in section 9.3.1. Krzysztof, do you think that MaxMsp uses the same rules for printing numbers in boxes? If so, it could be used as a guideline for Pd as well.
not really. The old, six decimals after point limit still remains all over Max6. But if you force something more sane into Pd, they'll likely follow...
Krzysztof
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list