[PD] Workarounds for number truncation >6 digits?

Hans-Christoph Steiner hans at eds.org
Thu Feb 26 03:32:23 CET 2009

On Feb 25, 2009, at 5:48 PM, Mathieu Bouchard wrote:

> On Wed, 25 Feb 2009, Hans-Christoph Steiner wrote:
>> I forgot to add, ideally we could fix the GUI stripping things down  
>> to 6 digits.  Anyone have teh documentation on this issue?  I  
>> looked around but couldn't find it.  I think IOhannes outlined it  
>> at one point.
> It's hidden deep inside. You'd think it were in some obvious place  
> like gatom_redraw in g_text.c. but this only calls glist_retext in  
> g_graph.c. this in turn only calls rtext_retext in g_rtext.c. So you  
> can see it does something about reducing width of numbers if they  
> are too wide, but they don't decide the original width. They  
> actually use the result from binbuf_gettext, which is in m_binbuf.c.  
> But it is not doing that job, it's delegating it to atom_string,  
> which is in m_atom.c. There you can find a sprintf "%g", but if you  
> modify it, you also modify the way numbers are saved in patchfiles  
> and in [textfile], the way numbers are sent over [netsend], the way  
> numbers are [print]ed in the console, etc.

It turns out that [print] has its own sprintf("%g") so it needs to be  
changed there too, and a few other places:

hans at palatschinken-711.local:src > grep printf * | grep '%g'
g_array.c:        if (fprintf(fd, "%g\n",
g_numbox.c:    sprintf(x->x_buf, "%g", f);
g_template.c:        else sprintf(sbuf, "%g",  
g_text.c:    sprintf(buf, "pdtk_gatom_dialog %%s %d %g %g %d {%s} {%s}  
m_atom.c:        sprintf(buf, "%g", a->a_w.w_float);
m_atom.c:        sprintf(tbuf, "%g", a->a_w.w_float);

As far as I can tell, a 32-bit float can represent 7.5ish digits of  
precision.  So it seems that all of these could be changed to  
sprintf("%.7g") so that the GUI/text/sends don't lose precision.  It  
seems to me that changing this would only cause problems with really  
obscure situations where a patch relies on Pd stripping off precision.

Using some bitwise operations on the float, it should be possible to  
test when 7 or 8 decimal digits  would be appropriate then create  
something like float2buf() that would convert the float to decimal  
while preserving as much of the precision as possible.



"[W]e have invented the technology to eliminate scarcity, but we are  
deliberately throwing it away to benefit those who profit from  
scarcity."        -John Gilmore

More information about the Pd-list mailing list