Hi,
I'm picking up a thread here from November last year: As IOhannes has pointed out at http://lists.puredata.info/pipermail/pd-list/2008-11/065883.html the Pd editor truncates long numbers to 6 digits (which of course has nothing to do with Pd's floating point resolution).
IOhannes has also noted that behind the GUI, the "correct" numbers (i.e. the ones that were initially typed) are still being used, leading to interesting situations like two [route 1e+06] boxes with different behavior.
However, when the patch is closed and re-opened, the _truncated_ (i.e. "incorrect") numbers are applied. While this complies with Pd's "the picture is the patch" philosophy, it obviously can lead to problematic situations.
A workaround was suggested by Nick Mariette: http://lists.puredata.info/pipermail/pd-list/2008-11/065890.html
I was wondering whether anybody else would share their strategies with regards to this problem?
I am guessing that another workaround would be to totally bypass the editor and run Pd without the GUI? (Which doesn't seem to make the development process very convenient, though.)
Any other ideas?
Thanks, flo.H
I did a similar thing with UNIX time in the past, I think I separated
the number into something like "days" and "seconds".
.hc
On Feb 24, 2009, at 3:28 PM, Florian Hollerweger wrote:
Hi,
I'm picking up a thread here from November last year: As IOhannes has pointed out at http://lists.puredata.info/pipermail/pd-list/2008-11/065883.html the Pd editor truncates long numbers to 6 digits (which of course has nothing to do with Pd's floating point resolution).
IOhannes has also noted that behind the GUI, the "correct" numbers
(i.e. the ones that were initially typed) are still being used, leading to interesting situations like two [route 1e+06] boxes with different
behavior.However, when the patch is closed and re-opened, the _truncated_ (i.e. "incorrect") numbers are applied. While this complies with Pd's "the picture is the patch" philosophy, it obviously can lead to problematic situations.
A workaround was suggested by Nick Mariette: http://lists.puredata.info/pipermail/pd-list/2008-11/065890.html
I was wondering whether anybody else would share their strategies with regards to this problem?
I am guessing that another workaround would be to totally bypass the editor and run Pd without the GUI? (Which doesn't seem to make the development process very convenient, though.)
Any other ideas?
Thanks, flo.H
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
All information should be free. - the hacker ethic
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.
.hc
On Feb 24, 2009, at 3:28 PM, Florian Hollerweger wrote:
Hi,
I'm picking up a thread here from November last year: As IOhannes has pointed out at http://lists.puredata.info/pipermail/pd-list/2008-11/065883.html the Pd editor truncates long numbers to 6 digits (which of course has nothing to do with Pd's floating point resolution).
IOhannes has also noted that behind the GUI, the "correct" numbers
(i.e. the ones that were initially typed) are still being used, leading to interesting situations like two [route 1e+06] boxes with different
behavior.However, when the patch is closed and re-opened, the _truncated_ (i.e. "incorrect") numbers are applied. While this complies with Pd's "the picture is the patch" philosophy, it obviously can lead to problematic situations.
A workaround was suggested by Nick Mariette: http://lists.puredata.info/pipermail/pd-list/2008-11/065890.html
I was wondering whether anybody else would share their strategies with regards to this problem?
I am guessing that another workaround would be to totally bypass the editor and run Pd without the GUI? (Which doesn't seem to make the development process very convenient, though.)
Any other ideas?
Thanks, flo.H
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an
idea, which an individual may exclusively possess as long as he keeps
it to himself; but the moment it is divulged, it forces itself into
the possession of everyone, and the receiver cannot dispossess himself
of it. - Thomas Jefferson
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's fun. it's a big, big fun." -- Louis 19
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
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@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",
template_getfloat(drawnumber_motion_template,
g_text.c: sprintf(buf, "pdtk_gatom_dialog %%s %d %g %g %d {%s} {%s}
{%s}\n",
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.
.hc
"[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
-
Florian Hollerweger -
Hans-Christoph Steiner -
Mathieu Bouchard