[PD] why does PD round numbers? (in tables, in messageboxes, etc)

[katja]

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 at 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 at iem.at mailing list
>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list