can just bang a message box after setting it to flush the output, too.

like [set $1$2, bang (

On 2020-10-01 08:44, jayrope wrote:

Thank you Hans and Matt,

Hans, nice workaround, I'll surely stick to this. Thank you.

i don't think this is a workaround. it's rather the ideal solution, as it stays within the domain of numbers, and doesn't require re-parsing the string (which is a costly operation).

Matt, regarding banging the message: this unfortunately leads to the following object, for instance a float, reporting float: no method for '12' (i. e. no method for '<value>').

use a symbol, not a selector (and make sure you are using Pd>=0.48)

matt's [set $1$2, bang( construct is really only useful if you want to send the data to a messagebox (but why would you want to do that?)

this should just work™:

[3.1 415( | [pack 0 0] | [symbol $1$2( | [float] | |3.1415\

but again, this is much more expensive than the solution proposed by hans.

gfmadrs IOhannes

but be aware of the risks of invoking makefilname all too often. it may clutter the symboltable, as per this recent discussion (started by me and confirmed by johannes): https://lists.puredata.info/pipermail/pd-list/2020-09/128158.html

best hans

Am 01.10.2020 um 08:46 schrieb oliver oliver@klingt.org:

jayrope wrote:

...

Hello list, I want to combine integer values from two sources into ONE new value, preferably a number, just like Source 1 sends 1, source 2 sends 1, result = 11 Src 3 sends 3, src 2 sends 8, result = 38

hi, here's my approach using [makefilename]

best

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

IOhannes m zmoelnig wrote:

On 2020-10-01 09:22, hans w. koch wrote:

...

but be aware of the risks of invoking makefilname all too often.

note that if you use dollsyms (as in [$1$2() you are filling up the symbol table just as well.

i was just about to ask, if the attached modified patch would avoid that problem, but you replied already.

could you please clarify the used term "invoke" a bit ? i guess the number of [makefilename] objects isn't the problem, but how much/often its conversion mechanism is used, right ?

does that mean that everytime a number->symbol conversion happens (regardless how it is done) the symboltable is filled and will eventually slow down or crash PD ?

so, as a live example: writing number values to GUI labels dynamically is a potentially dangerous thing ? what's the threshold there ?

or is there any way to clear the symboltable ?

sorry for my noob questions ... just a little concerned right now as i use this feature quite often ...

thanks for any insight !

best

oliver

On 2020-10-01 10:10, Matt Davey wrote:

if you bang the 7 17 message, and then bang the message box that gets set, pd outputs to console:

float: no method for '717'

But if you then save the patch, reload, and bang that same message box, it outputs correctly.

Is that a bug? Surely if behaviour is different between a live patch and a saved patch, that constitutes buggy behaviour?

no. not really.

• Pd has a strong distinction between numbers and symbols.
• however, Pd displays symbols and numbers the same. (there's no

*visual* clue that a text is a number or a symbol apart from it's content). this is why you think that your "7"+"17" is a number in the first place.

• when Pd parses a string into an atombuffer (this is what happens when

you load a patch), it will try to determine whether a given string is a number of not. if it looks like a number, it will become a number. if it doesn't, it will become a symbol. this is why 717 becomes a number after loading.

so what you are seeing is a side-effect of how Pd works - which in turn makes Pd able to get anything accomplished in a way that makes it usable as a live system for playing on stage. there are languages that don't make a distinction between numbers and strings (like PHP). there's probably a reason why people don't use PHP for realtime signal processing; and the automatic type coercion (treating strings as numbers and vice versa, depending on the context), is a source of much headache and bugs.

of course, one could tweak the fileformat a little bit, so that it will indicate that "717" is really a symbol, and when you load the patch, it will still look like a number, but still be a symbol (so you get the "no method for '717'" again).

the problem with this is, that it will probably break a lot of patches.

...

matt's [set $1$2, bang( construct is really only useful if you want

to send the data to a messagebox (but why would you want to do that?)

I often use [set $1, bang ( for things like setting a message box with the output of openpanel, and then also triggering the message. Had no idea that it didn't work for floats.

it works fine. why would it not?

what you are doing with [set $1, bang( is:

• store the current value for later use
• show the current value
• use the current value right now

i'm also using this quite often. however, my "why would you want to do that" was meant to say: this doesn't do anything useful in the context of the question.

also note that "$1" and "$1$2" are two very different things.

fgmadrs IOhannes

your computer memory will define the time when it will crash Pd (it will crash, when all the strings in the symboltable eat up all the memory available)

I think eating up all available memory is not a likely scenario on modern computers with a 64-bit address space and virtual memory.

The actual problem is that Pd's symbol table is implemented as a hash table with seperate chaining (https://en.wikipedia.org/wiki/Hash_table#Separate_chaining). This means that symbols which have the same hash value (= hash collision) are connected as a linked list. If you look up a such a symbol, you have to walk the linked list and do a string comparison for each element until you find a match.

The more symbols you add, the more hash collisions you get and the more symbols end up in the same bucket. In practice, this means that for a large number of elements, insertion and lookup becomes more and more expensive because the linked lists for each bucket grow larger and larger. While the hash lookup takes constant time "O(1)", the linked list traversal takes linear time "O(N)" (and is not very cache friendly).

Good hash table implementations mitigate this problems by a technique called "rehashing" where the hash table array is resized if the "load factor" (number of elements / number of buckets) exceed a certain threshold (= "load factor"). Then every item is hashed again and inserted back into the new hash table.

Unfortunately, Pd doesn't do any rehashing and it is certainly possible to significantly slow down Pd by flooding the symbol table. A common load factor threshold is 0.75, but if you create 10 000 unique symbols in Pd, the load factor would be ~10! Not very good...

In fact, I've already been thinking about improving the symbol table.

Christof

On 01.10.2020 10:28, IOhannes m zmoelnig wrote:

On 2020-10-01 09:54, oliver wrote:

...

IOhannes m zmoelnig wrote:

...

On 2020-10-01 09:22, hans w. koch wrote:

...

but be aware of the risks of invoking makefilname all too often.

note that if you use dollsyms (as in [$1$2() you are filling up the symbol table just as well.

i was just about to ask, if the attached modified patch would avoid that problem, but you replied already.

could you please clarify the used term "invoke" a bit ? i guess the number of [makefilename] objects isn't the problem, but how much/often its conversion mechanism is used, right ?

yes (the latter).

...

does that mean that everytime a number->symbol conversion happens (regardless how it is done) the symboltable is filled and will

no. everytime a *new* symbol is created. the point of symbols (vs ordinary strings) is, that a single literal only needs to be stored once. so if you first create a string "rubadub" (however you do this), a new entry for the symbol 'rubadub' is created. now, if you concatenate the symbols 'rubad' and 'ub', the result is "rubadub", which already happens to be in the symbol table (and thus no new entry needs to be generated). for Pd these strings are *identical*. this is cool as we can really easily compare the two strings. if they occupy the same entry in the symbol table (which basically means, that Pd gets the same pointer for when turning the literal into a symbol), then the two strings are the same. so rather than having to compare each character of the string "sjfdjdasjfsfjrueincru057894_curtrfenr3ewf8354j3wp57jp3" with each character of "sjfdjdasjfsfjrueincru057894_curtrfenr3ewfB354j3wp57jp3" , Pd only needs to compare two pointers - and this can be done in a single step on your CPU.

the problem with generating symbol programmatically (e.g. by sending numbers to [makefilename %d]) is, that it is so super easy to generate lots and lots of (different) symbols.

...

eventually slow down or crash PD ?

so, as a live example: writing number values to GUI labels dynamically is a potentially dangerous thing ? what's the threshold there ?

your computer memory will define the time when it will crash Pd (it will crash, when all the strings in the symboltable eat up all the memory available)

as for the slow-down, why not simply create a patch that tests this for you?

create labels with [makefilename label%08d] with the input ranging from 0...2000000 (or so; you'll notice when it gets slow). measure the time it takes to generate the symbols (well, measure the time it takes to generate 10000 symbols or)

...

or is there any way to clear the symboltable ?

i think i covered this in another ("the" other) post quite recently.

gfsdm IOhannes

---

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