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 maxi
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
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 printi
On Tue, Apr 10, 2012 at 7:32 AM, IOhannes m zmölnig 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 non-dec
- Original Message -
> From: Hans-Christoph Steiner
> To: Jonathan Wilkes
> Cc: Miller Puckette ; "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)
>
>
> Yes
: Miller Puckette
>> 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 have its own coords, fill,
>>
- Original Message -
> From: Hans-Christoph Steiner
> To: Miller Puckette
> 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 individua
t; Katja
>>
>>
>>
>> On Tue, Apr 10, 2012 at 7:05 PM, Jonathan Wilkes wrote:
>>> - Original Message -
>>>
>>>> From: katja
>>>> To: pd-list@iem.at
>>>> Cc:
>>>> Sent: Tuesday, April 10, 2012 9:45
e, Apr 10, 2012 at 7:05 PM, Jonathan Wilkes wrote:
> > - Original Message -
> >
> >> From: katja
> >> To: pd-list@iem.at
> >> Cc:
> >> Sent: Tuesday, April 10, 2012 9:45 AM
> >> Subject: Re: [PD] why does PD round numbers? (in tables, i
do another test where transmission over network is more
specifically tested.
Katja
On Tue, Apr 10, 2012 at 7:05 PM, Jonathan Wilkes wrote:
> - Original Message -
>
>> From: katja
>> To: pd-list@iem.at
>> Cc:
>> Sent: Tuesday, April 10, 2012 9:45 AM
>> Su
- Original Message -
> From: katja
> 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 :
>> On 04/10/12 10:33, katja wrote:
>
- Original Message -
> From: IOhannes m zmölnig
> 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 t
2012/4/10 IOhannes m zmölnig :
> 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, send over the
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 com
On Tue, Apr 10, 2012 at 12:50 PM, Krzysztof Czaja 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
> procedural, e
hi IOhannes, Katja,
On 04/10/2012 10:33 AM, katja wrote:
2012/4/9 IOhannes m zmölnig:
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 pretty much
ever
2012/4/9 IOhannes m zmölnig :
>> 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 without an
On 04/09/12 20:06, katja wrote:
On Mon, Apr 9, 2012 at 6:14 PM, Hans-Christoph Steiner 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
On Mon, Apr 9, 2012 at 6:14 PM, Hans-Christoph Steiner 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 precision.
> Usi
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
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 act
2012/4/9 IOhannes m zmölnig :
> 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 act
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
f
On Mon, Apr 9, 2012 at 1: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 digits max. You get things like this:
>>
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 Steiner 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
On Apr 8, 2012, at 3:17 PM, katja wrote:
> On Sun, Apr 8, 2012 at 8:43 PM, Hans-Christoph Steiner 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. P
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 digi
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 i
Here's a patch I submitted:
http://sourceforge.net/tracker/?func=detail&aid=2952880&group_id=55736&atid=478072
Martin
On 2012-04-08 15:17, katja wrote:
On Sun, Apr 8, 2012 at 8:43 PM, Hans-Christoph Steiner wrote:
The main reason why this is still like this is because no one has written
be
On Sun, Apr 8, 2012 at 8:43 PM, Hans-Christoph Steiner 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 before, no
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 1
On Sun, Apr 8, 2012 at 1:33 PM, Matteo Sisti Sette
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 numbers look good on
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 wond
If this happens, then it should be really given some thought.
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 patches.
Otherwise we ar
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 wrote:
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 li
http://en.wikipedia.org/wiki/Floating_point
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
37 matches
Mail list logo
