Re: [PD] packed floats to select object changes the select value

[Matt Davey]

Just for background, here's the reason why it caused so much difficulty:

I'm working on a really big complex project with hundreds of abstractions.
Lots of parameters feeding into each other with state saving, automations,
gui interaction...etc
In one synth channel, we have a [sel $1] object to update parameters
according to the channel they correspond to.
That channel abstraction was written several years ago, and never had an
issue.

About a year ago, we modified one of those channels to have 9 voices.  The
voices get a $2 argument from 1-9.  In the original channels without the 9
voices, the creation argument is left off and therefore just stays as 0.

So last week i was doing a cleanup to merge the single voice channels with
the 9 voice channel, and sending a channel message or a packed channel /
voice message.   Started to get weird behaviour, somewhat akin to execution
order issues.  Some values were being sent correctly the first few times,
and then only coming out wrong later on.  I religiously use triggers
everywhere, even when they are not essential, but i went over the whole
section again and checked the order.  All seemed fine.

Never even thought for a moment that the old [sel $1] object would change
its selection value when presented with packed floats.

The reason it was so hard to detect, is that the first outlet of [sel]
outputs a bang, and not a value.  So if the bang is not output, instead of
getting a wrong value that is easy to track down, it just quietly sends the
value through its right outlet (which in this case was not connected).

Turns out that by sending the channel / voice messages to the 9 voice
channel, and then merging that with the single voice channels, that all the
single voice channels were also receiving packed channel / voice messages
to the [sel] object, and thus changing its selection value.  It wasn't
until i literally put a print on either side of the [sel] object that i
noticed something was super weird.

***

Can understand that it's just following protocol of other objects that take
a list and distribute it to cold inlets, but the difference here is that
those other objects will still output SOMETHING through their left outlet,
so at least you get an idea that something is wrong.  With [sel] it just
stops sending the bang, and if you don't have anything connected to the
right outlet, you'd not notice that unless you are directly monitoring that
bang.

The only other object that i can think of which would behave that same way
is [moses], but even with that, you're inputting floats and outputting
floats, so much more likely to track down the cause if you accidentally set
the cold inlet of that one.

Anyway, i'm on no crusade.  I've learnt my lesson with this one, and spent
a few days tracking down that one bug, so won't make that mistake again.
There does seem to be a big reluctance here to change the behaviour though,
so whatever
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] packed floats to select object changes the select value

[Matt Davey]

Here’s my proposal:

If a sel object is created with arguments, add a list method to truncate
incoming lists to the first item.

If a sel object is created without any arguments, behaviour stays the way
it currently is.

Would that work?
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] problem with correct numbers in pd double precision

[hans w. koch]

thanks johannes,

for the clarification! 
always better to know, there is no magic involved :-)
(though i wasn´t implying [text] but the .txt format, which i believed to be 
“external" to pd, if that makes sense - appearantly not).

as long as there are workarounds, i can live with that.
a fix is quite likely waaayyy beyond my capabilities.
but would it warrant opening an issue on github?
i am a bit shy for finding the correct wording…

best

hans


> Am 20.09.2020 um 17:32 schrieb IOhannes m zmölnig :
> 
> Am 20. September 2020 16:41:56 MESZ schrieb "hans w. koch" 
> :
>> yeah, this is consistent with my findings too…
>> it just mystifies me, why writing the contents of [text] containing
>> symbols to a .txt file and reloading converts them silently back to
>> floats, perserving precision.
>> seems like the .txt file format does some behind-the-scenes magic.
> 
> 
> hmm, no.
> the behaviour you are seeing is exactly because [text] does NOT do any behind 
> the scenes magic.
> 
> all the problems come from the fact that the default string-representation 
> (and only the string-representation) of numbers is too coarse for 
> double-precision.
> 
> 
> mfg.hft.fsl
> IOhannes
> 
> 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] packed floats to select object changes the select value

[IOhannes m zmölnig]

> you can easily fix your patch by using unpack or something. 

[t f] is probably the most efficient.

> If no one actually relies on this list
> behaviour
> you may have a point.


like always, I'm pretty sure that I actually used this at least once.

but more importantly, I definitely do you use the list-to-inlets feature with 
objects like [+], [pack] and [line]; and I think that the behaviour should be 
consistent (as it currently is).


mfg.hft.fsl
IOhannes


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] problem with correct numbers in pd double precision

[IOhannes m zmölnig]

Am 20. September 2020 16:41:56 MESZ schrieb "hans w. koch" 
:
> yeah, this is consistent with my findings too…
> it just mystifies me, why writing the contents of [text] containing
> symbols to a .txt file and reloading converts them silently back to
> floats, perserving precision.
> seems like the .txt file format does some behind-the-scenes magic.


hmm, no.
the behaviour you are seeing is exactly because [text] does NOT do any behind 
the scenes magic.

all the problems come from the fact that the default string-representation (and 
only the string-representation) of numbers is too coarse for double-precision.


mfg.hft.fsl
IOhannes


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] packed floats to select object changes the select value

[Alexandre Torres Porres]

Em dom., 20 de set. de 2020 às 09:40, Matt Davey 
escreveu:

> Is there any reason why it shouldn't change?
>
> It's undocumented and weird behaviour that surely nobody relies on.
>

actually it is as 'seb shader' referenced on github, see
http://msp.ucsd.edu/Pd_documentation/x2.htm#s3.3

Unless they arrange otherwise by defining a "list" method, objects respond
to the "list" message by distributing the arguments of the message to their
inlets, except for the first argument which is passed as a "float" or
"symbol" message to the object proper.

you can easily fix your patch by using unpack or something. But you may
have a request that we add a list method to select where it only considers
the 1st item of a list. If no one actually relies on this list behaviour
you may have a point.
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] problem with correct numbers in pd double precision

[hans w. koch]

yeah, this is consistent with my findings too…
it just mystifies me, why writing the contents of [text] containing symbols to 
a .txt file and reloading converts them silently back to floats, perserving 
precision.
seems like the .txt file format does some behind-the-scenes magic.

(adapted your patch to demonstrate, also Pd-double only)

hans



big-numbers2.pd
Description: Binary data



> Am 20.09.2020 um 12:40 schrieb Lucas Cordiviola :
> 
> Interesting I got into troubles storing big numbers into a [text] using the 
> -k flag but this can be solved using [list fromsymbol] / [list tosymbol].
> 
> See attached patch (needs Pd-double).
> 
> 
> --
> 
> Mensaje telepatico asistido por maquinas.
> 
> On 9/19/2020 3:38 PM, hans w. koch wrote:
>> just to report another weirdness:
>> if i
>> 1. write those big numbers  (e.g. 8278095582780955) with [text set] to a 
>> [text define ] with [makefilename %.0f] (i used this to avoid unnecessary 
>> decimal points)
>> 2. then write the textfile to disk as .txt
>> 3. read it in again
>> the symbols are automatically converted to exponential notation (8.2781e+15) 
>> inside the [text]/textfile, BUT retain their full precision!
>> 
>> but in order for this to work, they have to be written to the [text] as 
>> symbols with [makefilename %.0f] first.
>> 
>> weird, ain´t it?
>> 
>> hans
>> 
>> 
>> 
>>> Am 19.09.2020 um 10:49 schrieb hans w. koch :
>>> 
>>> arrghhh…sometimes live can be so easy :-)
>>> 
>>> cheers
>>> hans
>>> 
 Am 19.09.2020 um 10:45 schrieb Lucas Cordiviola :
 
 I think you can convert symbol back to float just using [f ].
 
 [123123123(
 |
 [makefilename %f]
 |
 [t a 0]
 | |
 [text set foo]
 
 
 
 [0(
 |
 [text get foo]
 |
 [f ]
 |
 [print]
 
 
 :)
 
 Mensaje telepatico asistido por maquinas.
 
 On 9/19/2020 4:16 AM, hans w. koch wrote:
> thanks lucas,
> 
> transitioning numbers over to symbolland could solve my problem, 
> interesting to know.
> 
> i need to store some of the big numbers in a textfile and there i get the 
> same problems with representation.
> if i recall them later, they´ve lost their precision.
> so i can make the transition back from symboldland with a bit of fudi 
> objects voodoo and be good :-)
> 
> what i use is this:
> [makefilename %f]
> |
> [list trim symbol]
> |
> [fudiformat -u]
> |
> [fudiparse]
> 
> and have my number back from symbol.
> 
> best
> hans
> 
> 
> 
>> Am 19.09.2020 um 05:32 schrieb Lucas Cordiviola :
>> 
>> If you want to print the numbers nicely to the console add [makefilename 
>> %f] :
>> 
>> [t b f]
>>  |
>>  [makefilename %f]
>>  |
>>  [print count]
>> 
>> 
>> Be aware of https://github.com/pure-data/pure-data/issues/812
>> 
>> :)
>> 
>> Mensaje telepatico asistido por maquinas.
>> 
>> On 9/18/2020 6:12 PM, hans w. koch wrote:
>>> hello,
>>> 
>>> its probably due to my lack of understanding the correct number 
>>> representations, but here it goes anyway:
>>> 
>>> i compiled pd 51-2 double precision for mac 10.14.6
>>> with this version i was hoping to do some maths on big numbers.
>>> but already an increment of 1 on some moderatly big number gives me 
>>> problems of representation.
>>> 
>>> i made a simple version of the problem as a patch.
>>> to verify you have a working version of pd double, it contains a simple 
>>> test.
>>> and then an iterative addition +1 starting from 99.
>>> i get this:
>>> count: 99
>>> count: 1e+06
>>> count: 1e+06
>>> count: 1e+06
>>> count: 1e+06
>>> count: 1e+06
>>> count: 1.0e+06
>>> count: 1.1e+06
>>> count: 1.1e+06
>>> count: 1.1e+06
>>> 
>>> the algorith terminates succesfully by a [select] after 10 iterations, 
>>> but the results don´t show what i expect.
>>> this to me indicates, that the internal numbers are correct, but they 
>>> don´t “surface” as such.
>>> 
>>> i would be grateful for any pointers and possible workarounds, as the 
>>> numbers i hope to be dealing with are potentially orders of magnitude 
>>> higher.
>>> 
>>> thanks hans
>>> 
>>> 
>>> ___
>>> Pd-list@lists.iem.at mailing list
>>> UNSUBSCRIBE and account-management -> 
>>> https://lists.puredata.info/listinfo/pd-list 
>>> 
> 

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] packed floats to select object changes the select value

[matthew brandi]

On 20/09/2020 12:13, Matt Davey wrote:
> [2 3(
> |
> [sel 2]
> 
> outputs the 2 from the right outlet!
> Sending a 3 afterwards outputs a bang from the left outlet.

Dear Matt

I don’t find this behaviour problematic, but if you want to guard against
accidentally "reprogramming" the select by sending a list, you can add a second 
—
repeated — argument to the select (the second inlet goes away and the second 
outlet
is redundant):

[2 3(
|
[sel 2 2]

… or you can place a float before the select:

[2 3(
|
[f]
|
[sel 2]

Right?

Best

m
-- 
matthew brandi



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] packed floats to select object changes the select value

[Matt Davey]

Is there any reason why it shouldn't change?

It's undocumented and weird behaviour that surely nobody relies on.

I cannot think of a single case in which anyone would want to send packed
floats to a sel object in order to set its value.
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] packed floats to select object changes the select value

[Christof Ressi]

due probably to pd objects' default behaviour of using a second float 
to set the cold inlet. 
that's correct. The first inlet of [select] expects a *single* float (or 
symbol). The help patch says: "compare floast and symbol".



Pretty sure this is unwanted behaviour


The behavior has been like this for ages and won't change. If you don't 
like it, use another object. You're probably looking for [relay] from 
zexy. You can easily make a vanilla version with [list split], [route] 
and [list prepend].


Christof

On 20.09.2020 13:13, Matt Davey wrote:

[2 3(
|
[sel 2]

outputs the 2 from the right outlet!  Sending a 3 afterwards outputs a 
bang from the left outlet.


Pretty sure this is unwanted behaviour, due probably to pd objects' 
default behaviour of using a second float to set the cold inlet.  In 
this case it is definitely unwanted, and can be the source of some 
very hard to track down bugs.




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] packed floats to select object changes the select value

[Matt Davey]

[2 3(
|
[sel 2]

outputs the 2 from the right outlet!  Sending a 3 afterwards outputs a bang
from the left outlet.

Pretty sure this is unwanted behaviour, due probably to pd objects' default
behaviour of using a second float to set the cold inlet.  In this case it
is definitely unwanted, and can be the source of some very hard to track
down bugs.
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] problem with correct numbers in pd double precision

[Lucas Cordiviola]

Interesting I got into troubles storing big numbers into a [text] using 
the -k flag but this can be solved using [list fromsymbol] / [list 
tosymbol].


See attached patch (needs Pd-double).


--

Mensaje telepatico asistido por maquinas.

On 9/19/2020 3:38 PM, hans w. koch wrote:

just to report another weirdness:
if i
1. write those big numbers  (e.g. 8278095582780955) with [text set] to a [text 
define ] with [makefilename %.0f] (i used this to avoid unnecessary decimal 
points)
2. then write the textfile to disk as .txt
3. read it in again
the symbols are automatically converted to exponential notation (8.2781e+15) 
inside the [text]/textfile, BUT retain their full precision!

but in order for this to work, they have to be written to the [text] as symbols 
with [makefilename %.0f] first.

weird, ain´t it?

hans




Am 19.09.2020 um 10:49 schrieb hans w. koch :

arrghhh…sometimes live can be so easy :-)

cheers
hans


Am 19.09.2020 um 10:45 schrieb Lucas Cordiviola :

I think you can convert symbol back to float just using [f ].

[123123123(
|
[makefilename %f]
|
[t a 0]
| |
[text set foo]



[0(
|
[text get foo]
|
[f ]
|
[print]


:)

Mensaje telepatico asistido por maquinas.

On 9/19/2020 4:16 AM, hans w. koch wrote:

thanks lucas,

transitioning numbers over to symbolland could solve my problem, interesting to 
know.

i need to store some of the big numbers in a textfile and there i get the same 
problems with representation.
if i recall them later, they´ve lost their precision.
so i can make the transition back from symboldland with a bit of fudi objects 
voodoo and be good :-)

what i use is this:
[makefilename %f]
|
[list trim symbol]
|
[fudiformat -u]
|
[fudiparse]

and have my number back from symbol.

best
hans




Am 19.09.2020 um 05:32 schrieb Lucas Cordiviola :

If you want to print the numbers nicely to the console add [makefilename %f] :

[t b f]
  |
  [makefilename %f]
  |
  [print count]


Be aware of https://github.com/pure-data/pure-data/issues/812

:)

Mensaje telepatico asistido por maquinas.

On 9/18/2020 6:12 PM, hans w. koch wrote:

hello,

its probably due to my lack of understanding the correct number 
representations, but here it goes anyway:

i compiled pd 51-2 double precision for mac 10.14.6
with this version i was hoping to do some maths on big numbers.
but already an increment of 1 on some moderatly big number gives me problems of 
representation.

i made a simple version of the problem as a patch.
to verify you have a working version of pd double, it contains a simple test.
and then an iterative addition +1 starting from 99.
i get this:
count: 99
count: 1e+06
count: 1e+06
count: 1e+06
count: 1e+06
count: 1e+06
count: 1.0e+06
count: 1.1e+06
count: 1.1e+06
count: 1.1e+06

the algorith terminates succesfully by a [select] after 10 iterations, but the 
results don´t show what i expect.
this to me indicates, that the internal numbers are correct, but they don´t 
“surface” as such.

i would be grateful for any pointers and possible workarounds, as the numbers i 
hope to be dealing with are potentially orders of magnitude higher.

thanks hans


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list 

#N canvas 213 65 898 584 12;
#X obj 330 289 text set bign;
#X obj 203 108 makefilename %.0f;
#X msg 360 263 0;
#X obj 496 414 text get bign;
#X msg 499 387 0;
#X obj 89 190 list fromsymbol;
#X obj 81 468 list tosymbol;
#X obj 86 288 text set bign;
#X obj 91 224 t l b;
#X msg 120 257 1;
#X obj 331 228 t a b;
#X obj 82 443 text get bign;
#X msg 82 418 1;
#X obj 83 490 print good;
#X obj 489 509 print bad;
#N canvas 0 50 985 489 other_tests_failed 0;
#X obj 78 325 array define bn 10;
#X obj 29 92 array set bn;
#X obj 211 148 array get bn;
#X obj 39 41 t l b;
#X msg 70 68 0;
#X floatatom 226 73 5 0 0 0 - - -;
#X obj 223 97 t f b;
#X msg 253 124 1;
#X msg 94 270 write bn.txt;
#X obj 218 224 print;
#X msg 94 298 read bn.txt;
#X obj 536 321 soundfiler;
#X msg 555 260 write -ascii -bytes 4 bnascii.txt bn;
#X msg 564 287 read bnascii.txt bn;
#X msg 40 14 1.23123e+008 4.56456e+008 7.8979e+008;
#X obj 210 178 makefilename %.0f;
#X text 523 161 this was tested with PR #855 "soundfile updates: refactor
\, bugfixes \, AIFC \, & CAF".;
#X connect 2 0 15 0;
#X connect 3 0 1 0;
#X connect 3 1 4 0;
#X connect 4 0 1 1;
#X connect 5 0 6 0;
#X connect 6 0 2 0;
#X connect 6 1 7 0;
#X connect 7 0 2 1;
#X connect 8 0 0 0;
#X connect 10 0 0 0;
#X connect 12 0 11 0;
#X connect 13 0 11 0;
#X connect 14 0 3 0;
#X connect 15 0 9 0;
#X restore 702 545 pd other_tests_failed;
#X obj 202 139 t b a a;
#X obj 204 83 pow 12;
#X msg 204 57 12;
#X obj 490 481 makefilename %.0f;
#X obj 623 98 text define -k bign;
#A set 8.9161e+012 \; 56 57 49 54 49 48 48 52 52 56 50 53 54 \;;
#X obj 352 505 print bad2;
#X obj 465 443 t a a

[PD] [OT] Re: Advice on distributing pd-based software for apple

[IOhannes m zmölnig]

this thread is getting increasingly off-topic.

however, ...

On 2020-09-20 04:53, Darren Kelly wrote:
> Then please focus on that instead of making sweeping remarks about 

...i think you are being unfair here.

joão attempted to focus on the task at hand, while others detoriated the
thread into "blame apple" accusations.


gfmdat
IOhannes



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list