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
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
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
2012/4/9 IOhannes m zmölnig zmoel...@iem.at:
A non-decimal ASCII format instead, would make
existing patches unreadable.
right; i think this is also the reason why Pd doesn't do any binary
storage/transmission: it makes debugging so easy if you can actually
understand what is going on
hi IOhannes, Katja,
On 04/10/2012 10:33 AM, katja wrote:
2012/4/9 IOhannes m zmölnigzmoel...@iem.at:
A non-decimal ASCII format instead, would make
existing patches unreadable.
...
for the record: Max abandoned binary patch storage format quite
some time ago. They tend to use JSON now for
On Tue, Apr 10, 2012 at 12:50 PM, Krzysztof Czaja cz...@chopin.edu.pl wrote:
for the record: Max abandoned binary patch storage format quite
some time ago. They tend to use JSON now for pretty much
everything, and it works well.
Declarative format is more flexible and easier to extend than
On 04/10/12 10:33, katja wrote:
I mean to say that switching to any format other than decimal ASCII
would make it impossible for Pd to interpret patch files using the
current format.
why?
Large tables are mostly stored in an audio format, rather than text.
i was talking about pd/pd-gui
2012/4/10 IOhannes m zmölnig zmoel...@iem.at:
On 04/10/12 10:33, katja wrote:
i was talking about pd/pd-gui communication (and keep the number format for
both saving and pd/gui communication the same).
when displaying/updating a table every single number is converted to text
using printf,
- Original Message -
From: IOhannes m zmölnig zmoel...@iem.at
To: pd-list@iem.at
Cc:
Sent: Tuesday, April 10, 2012 8:32 AM
Subject: Re: [PD] why does PD round numbers? (in tables, in messageboxes, etc)
On 04/10/12 10:33, katja wrote:
I mean to say that switching to any
- Original Message -
From: katja katjavet...@gmail.com
To: pd-list@iem.at
Cc:
Sent: Tuesday, April 10, 2012 9:45 AM
Subject: Re: [PD] why does PD round numbers? (in tables, in messageboxes, etc)
2012/4/10 IOhannes m zmölnig zmoel...@iem.at:
On 04/10/12 10:33, katja wrote:
i
does PD round numbers? (in tables, in messageboxes,
etc)
2012/4/10 IOhannes m zmölnig zmoel...@iem.at:
On 04/10/12 10:33, katja wrote:
i was talking about pd/pd-gui communication (and keep the number format for
both saving and pd/gui communication the same).
when displaying/updating
To: pd-list@iem.at
Cc:
Sent: Tuesday, April 10, 2012 9:45 AM
Subject: Re: [PD] why does PD round numbers? (in tables, in messageboxes,
etc)
2012/4/10 IOhannes m zmölnig zmoel...@iem.at:
On 04/10/12 10:33, katja wrote:
i was talking about pd/pd-gui communication (and keep
network is more
specifically tested.
Katja
On Tue, Apr 10, 2012 at 7:05 PM, Jonathan Wilkes jancs...@yahoo.com wrote:
- Original Message -
From: katja katjavet...@gmail.com
To: pd-list@iem.at
Cc:
Sent: Tuesday, April 10, 2012 9:45 AM
Subject: Re: [PD] why does PD round
- Original Message -
From: Hans-Christoph Steiner h...@at.or.at
To: Miller Puckette m...@ucsd.edu
Cc: pd-list@iem.at
Sent: Tuesday, April 10, 2012 1:38 PM
Subject: Re: [PD] why does PD round numbers? (in tables, in messageboxes, etc)
Makes sense to me. Each individual point can
-list@iem.at
Sent: Tuesday, April 10, 2012 1:38 PM
Subject: Re: [PD] why does PD round numbers? (in tables, in messageboxes,
etc)
Makes sense to me. Each individual point can have its own coords, fill,
color,
tags, etc. while a polygon just has one set of all those for the whole thing
- Original Message -
From: Hans-Christoph Steiner h...@at.or.at
To: Jonathan Wilkes jancs...@yahoo.com
Cc: Miller Puckette m...@ucsd.edu; pd-list@iem.at pd-list@iem.at
Sent: Tuesday, April 10, 2012 2:43 PM
Subject: Re: [PD] why does PD round numbers? (in tables, in messageboxes, etc
On Tue, Apr 10, 2012 at 7:32 AM, IOhannes m zmölnig zmoel...@iem.at wrote:
On 04/10/12 10:33, katja wrote:
I mean to say that switching to any format other than decimal ASCII
would make it impossible for Pd to interpret patch files using the
current format.
why?
I think that using any
On Mon, Apr 9, 2012 at 1:23 AM, Matteo Sisti Sette
matteosistise...@gmail.com wrote:
On 04/08/2012 04:27 PM, katja wrote:
I've once compiled (vanilla) Pd with the format specifiers changed to
print up to 8 significant digits, and soon found why it is normally
done with 6 digits max. You get
On 04/09/12 12:39, katja wrote:
Doing it better would require a lot of modifications, more than
changing some format specifiers. It's a pity we can't see MaxMsp's
code, the issues seem to be neatly solved there, like:
i haven't looked at the actual behaviour, but max has a (default) binary
2012/4/9 IOhannes m zmölnig zmoel...@iem.at:
On 04/09/12 12:39, katja wrote:
Doing it better would require a lot of modifications, more than
changing some format specifiers. It's a pity we can't see MaxMsp's
code, the issues seem to be neatly solved there, like:
i haven't looked at the
On 2012-04-09 07:31, IOhannes m zmölnig wrote:
On 04/09/12 12:39, katja wrote:
Doing it better would require a lot of modifications, more than
changing some format specifiers. It's a pity we can't see MaxMsp's
code, the issues seem to be neatly solved there, like:
i haven't looked at the
On Apr 9, 2012, at 11:34 AM, Martin Peach wrote:
On 2012-04-09 07:31, IOhannes m zmölnig wrote:
On 04/09/12 12:39, katja wrote:
Doing it better would require a lot of modifications, more than
changing some format specifiers. It's a pity we can't see MaxMsp's
code, the issues seem to be
On Mon, Apr 9, 2012 at 6:14 PM, Hans-Christoph Steiner h...@at.or.at wrote:
We could still store numbers as ASCII and not lose precision. For example,
we could store the actual bits as base64 or hex. Let's say it'll store
64-bits to have one number format for both single and double
On 04/09/12 20:06, katja wrote:
On Mon, Apr 9, 2012 at 6:14 PM, Hans-Christoph Steinerh...@at.or.at wrote:
We could still store numbers as ASCII and not lose precision. For example, we
could store the actual bits as base64 or hex. Let's say it'll store 64-bits to
have one number format
If this happens, then it should be really given some thought.
thinking out loud
I guess one of the downsides of graphical dataflow is that we see what we
get (kinda like WYSIWIG editors), therefore there should be a way to always
get dirty and non rounded numbers on screen and onto loaded
On 04/08/2012 04:58 AM, Martin Peach wrote:
It's because Pd saves the value by printing it as text into the patch
file using a reduced precision format specifier (%g instead of %f, or
%0.6f) so that the numbers look good on screen, with no extra zeros for
example.
I don't like it either.
I
On Sun, Apr 8, 2012 at 1:33 PM, Matteo Sisti Sette
matteosistise...@gmail.com wrote:
On 04/08/2012 04:58 AM, Martin Peach wrote:
It's because Pd saves the value by printing it as text into the patch
file using a reduced precision format specifier (%g instead of %f, or
%0.6f) so that the
The main reason why this is still like this is because no one has written
better code, then done thorough testing in order to prove that the new code
doesn't break anything. People have written better code for this before, no
one has done the thorough testing part...
.hc
On Apr 7, 2012, at
On Sun, Apr 8, 2012 at 8:43 PM, Hans-Christoph Steiner h...@at.or.at wrote:
The main reason why this is still like this is because no one has written
better code, then done thorough testing in order to prove that the new code
doesn't break anything. People have written better code for this
Here's a patch I submitted:
http://sourceforge.net/tracker/?func=detailaid=2952880group_id=55736atid=478072
Martin
On 2012-04-08 15:17, katja wrote:
On Sun, Apr 8, 2012 at 8:43 PM, Hans-Christoph Steinerh...@at.or.at wrote:
The main reason why this is still like this is because no one has
On 04/08/2012 04:27 PM, katja wrote:
I've once compiled (vanilla) Pd with the format specifiers changed to
print up to 8 significant digits, and soon found why it is normally
done with 6 digits max. You get things like this:
33 * 0.3 = 9.91
That is completely unrelated. That is an issue
Whops, I should have read the other replies first :$
On 04/09/2012 01:23 AM, Matteo Sisti Sette wrote:
On 04/08/2012 04:27 PM, katja wrote:
I've once compiled (vanilla) Pd with the format specifiers changed to
print up to 8 significant digits, and soon found why it is normally
done with 6
On Apr 8, 2012, at 3:17 PM, katja wrote:
On Sun, Apr 8, 2012 at 8:43 PM, Hans-Christoph Steiner h...@at.or.at wrote:
The main reason why this is still like this is because no one has written
better code, then done thorough testing in order to prove that the new code
doesn't break
On 2012-04-08 20:45, Hans-Christoph Steiner wrote:
On Apr 8, 2012, at 3:17 PM, katja wrote:
On Sun, Apr 8, 2012 at 8:43 PM, Hans-Christoph Steinerh...@at.or.at wrote:
The main reason why this is still like this is because no one has written
better code, then done thorough testing in order
http://en.wikipedia.org/wiki/Floating_point
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
that's not what i mean.
i mean, that when i write 12345678 (must be 100% accurate within 32bit
float with 24bit mantissa) into an array and read it from there, it's still
12345678.
but when i save that patch, close it and reload it, and i read from the
array, i get 12345700.
nothing to do with
It's because Pd saves the value by printing it as text into the patch
file using a reduced precision format specifier (%g instead of %f, or
%0.6f) so that the numbers look good on screen, with no extra zeros for
example.
I don't like it either.
Martin
On 2012-04-07 22:40, Angakok Thoth
37 matches
Mail list logo
