A student just discovered this strange behavior. Basically, if you get something that generates a symbolic atom that has numeric data in it, you can then create a mystery type by feeding that thru [list trim]. Don't know exactly where the problem is, but something fishy is going on. My guess is that [list trim] should output a float.
See attached patch:
.hc
------------------------------------------------------------------------
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
A student just discovered this strange behavior. Basically, if you get something that generates a symbolic atom that has numeric data in it, you can then create a mystery type by feeding that thru [list trim]. Don't know exactly where the problem is, but something fishy is going on.
What "list trim" does on a "symbol X" is generate a meta message consisting only of the selector "X". But here this selector is numeric. Numeric selectors are illegal, because selectors have to be a symbol. It could be considered a bug in the patch trying to generate such illegal meta-messages. Removing the [list trim] will fix the patch as will adding a [list] after [list trim].
My guess is that [list trim] should output a float.
To me it is a bug in the patch rather than in [list trim]. In my understanding [list trim] is designed to remove the "list"-selector and through that the other two standard Pd selectors, "float" and "symbol" as well, but it was not designed to add them or to convert from "symbol ..." to "float ...". For that, [list] itself should be used.
Ciao
On Oct 28, 2006, at 3:57 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
A student just discovered this strange behavior. Basically, if you get something that generates a symbolic atom that has numeric data in it, you can then create a mystery type by feeding that thru [list trim]. Don't know exactly where the problem is, but something fishy is going on.
What "list trim" does on a "symbol X" is generate a meta message consisting only of the selector "X". But here this selector is numeric. Numeric selectors are illegal, because selectors have to be a symbol. It could be considered a bug in the patch trying to generate such illegal meta-messages. Removing the [list trim] will fix the patch as will adding a [list] after [list trim].
My guess is that [list trim] should output a float.
To me it is a bug in the patch rather than in [list trim]. In my understanding [list trim] is designed to remove the "list"-selector and through that the other two standard Pd selectors, "float" and "symbol" as well, but it was not designed to add them or to convert from "symbol ..." to "float ...". For that, [list] itself should be used.
Yes, this is a strange thing to do, but I am just illustrating a point. This problem came to my attention because of a real world problem where OSC from Flash is being received from Pd fine, but its generating this format of data, and it is therefore useless (without [atoi], which works correctly here, IMHO).
If this is a totally useless and illegal value, then nothing should ever generate it. By definition, anything that can be interrupted as a number, should be a float. The Pd manual 2.1.2 says "Anything that is not a valid number is considered a symbol" ("symbol" here meaning symbolic atom, not symbol message). That means that the converse should be true too: "anything that is a valid number should be considered a float".
Therefore any atom containing "1234" should always be a float.
.hc
------------------------------------------------------------------------
Access to computers should be unlimited and total. - the hacker ethic
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
If this is a totally useless and illegal value, then nothing should ever generate it. By definition, anything that can be interrupted as a number, should be a float. The Pd manual 2.1.2 says "Anything that is not a valid number is considered a symbol" ("symbol" here meaning symbolic atom, not symbol message). That means that the converse should be true too: "anything that is a valid number should be considered a float".
The problem is: [makefilename %d] generates a *symbol* whose content data is a numeric value. This means, the "1234" in your student's example patch actually is *not* a float, but a symbol atom! So converting this back to a known type after trimming will generate a symbol, not a float. See attached patch which has a small change to do a double conversion: one to the Land of Oz and then back into Pd land.
Ciao
Just checking it's not a problem with [makefilename], it's not. I'd expect an X from trimming any raw X, in other words [list trim] should do nothing to any data that doesn't have "list" at the start. Is that what you would expect?
On Fri, 27 Oct 2006 18:51:37 -0400 Hans-Christoph Steiner hans@eds.org wrote:
A student just discovered this strange behavior. Basically, if you get something that generates a symbolic atom that has numeric data in it, you can then create a mystery type by feeding that thru [list trim]. Don't know exactly where the problem is, but something fishy is going on. My guess is that [list trim] should output a float.
See attached patch:
That might be one solution when using [list trim], but this example actually shows a problem with the type system. Things are supposed to be strictly typed, atoms are either floats, symbols, or pointers. This is an example of an atom that is none of the above. That should not happen, its a bug somewhere.
I updated the example patch with a couple of more relevant examples:
[select 1234] and [route 1234] don't know what to do with this thing either.
.hc
On Oct 28, 2006, at 8:57 AM, padawan12 wrote:
Just checking it's not a problem with [makefilename], it's not. I'd expect an X from trimming any raw X, in other words [list trim] should do nothing to any data that doesn't have "list" at the start. Is that what you would expect?
On Fri, 27 Oct 2006 18:51:37 -0400 Hans-Christoph Steiner hans@eds.org wrote:
A student just discovered this strange behavior. Basically, if you get something that generates a symbolic atom that has numeric data in it, you can then create a mystery type by feeding that thru [list trim]. Don't know exactly where the problem is, but something fishy is going on. My guess is that [list trim] should output a float.
See attached patch:
<mystery_type_after_conversion-more.pd>
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------
Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism. - retired U.S. Army general, William Odom
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
That might be one solution when using [list trim], but this example actually shows a problem with the type system. Things are supposed to be strictly typed, atoms are either floats, symbols, or pointers. This is an example of an atom that is none of the above. That should not happen, its a bug somewhere.
I updated the example patch with a couple of more relevant examples:
The mystery type "symbol atom with numeric content" cannot be dealt with in Pd like this yet, because you cannot really input this mystery type in Pd: Every numeric value in an object box will be converted to a float atom, you have to generate a symbol-atom with numeric content through other means like makefilename.
That's why [select 1234] fails to detect a "1234"-symbol without selector. [select 1234] will generate a [select] object in "float mode". [select something] will generate a [select] in "symbol mode".
The float-[select] only has methods for float- and symbol-messages, but no methods for meta-messages like "set a b c", "set" or the "1234"-mystery-symbol. (It also has no methods for bang-message and "list a b c"-messages will generate an error message, but at least works.)
Similar things happen with [route 1234]: This route waits for a "float 1234" but in your example it gets a symbol-atom "1234" and correctly passes it along to the miss-outlet.
See attached example for this illustrated.
Ciao
On Oct 29, 2006, at 7:38 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
That might be one solution when using [list trim], but this example actually shows a problem with the type system. Things are supposed to be strictly typed, atoms are either floats, symbols, or pointers. This is an example of an atom that is none of the above. That should not happen, its a bug somewhere.
I updated the example patch with a couple of more relevant examples:
The mystery type "symbol atom with numeric content" cannot be dealt with in Pd like this yet, because you cannot really input this mystery type in Pd: Every numeric value in an object box will be converted to a float atom, you have to generate a symbol-atom with numeric content through other means like makefilename.
That's why [select 1234] fails to detect a "1234"-symbol without selector. [select 1234] will generate a [select] object in "float mode". [select something] will generate a [select] in "symbol mode".
The float-[select] only has methods for float- and symbol-messages, but no methods for meta-messages like "set a b c", "set" or the "1234"-mystery-symbol. (It also has no methods for bang-message and "list a b c"-messages will generate an error message, but at least works.)
Similar things happen with [route 1234]: This route waits for a "float 1234" but in your example it gets a symbol-atom "1234" and correctly passes it along to the miss-outlet.
See attached example for this illustrated.
That outlines the situation well. So my point is now that this needs to be fixed either way. The definition of atoms should be consistent. I think its good the way its defined in the manual:
"Atoms are either numbers or symbols like "+". Anything that is not a valid number is considered a symbol."
Therefore "1234" should always be a numeric atom. I think that the type system should prevent this from happening, but maybe its also possible to fix the objects that are creating this mystery type. So far its [makefilename] and [dumpOSC].
But perhaps it would me nice to be able to use a numeric atom in a symbol message, I seem to recall that being useful sometimes. But that should probably be tested out in examples.
.hc
------------------------------------------------------------------------
Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
That outlines the situation well. So my point is now that this needs to be fixed either way. The definition of atoms should be consistent. I think its good the way its defined in the manual:
"Atoms are either numbers or symbols like "+". Anything that is not a valid number is considered a symbol."
Therefore "1234" should always be a numeric atom.
To be pedantic: You cannot conclude this from the manual, because one could extend the quote as: "Anything that is not a valid number is considered a symbol ... and something that is a valid number can be (made into) a symbol as well in certain rare circumnstances. But then it's not a usual number ("float") anymore and you need to be careful."
I think that the type system should prevent this from happening, but maybe its also possible to fix the objects that are creating this mystery type. So far its [makefilename] and [dumpOSC].
But perhaps it would me nice to be able to use a numeric atom in a symbol message, I seem to recall that being useful sometimes. But that should probably be tested out in examples.
I somehow remember that numeric symbols have their use with the text-rendering objects of Gem (phone numbers that start with 0 come to mind). In day-to-day use purely numeric symbols aren't needed and normally they aren't generated as well. I'd consider generating numeric symbols "advanced Pd usage. ;) And *if* someone generates them, one should be aware of the consequences for example in [select] and [route].
Anyway what is needed in the long term is a proper string type.
Ciao
On Sun, 29 Oct 2006, Hans-Christoph Steiner wrote:
Therefore "1234" should always be a numeric atom. I think that the type system should prevent this from happening, but maybe its also possible to fix the objects that are creating this mystery type. So far its [makefilename] and [dumpOSC]. But perhaps it would me nice to be able to use a numeric atom in a symbol message, I seem to recall that being useful sometimes. But that should probably be tested out in examples.
IMHO instead fix [print], messagebox, the .pd file format saver, and other things that turn symbols to literals, so that they always turn symbols into symbol literals, so that when they are parsed again, they would be symbols again.
However, with the current syntax and file format, this is not possible. Someone has to make a decision to change the syntax so that it is possible to write a symbol made of all digits (for example, using "").
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
-
Frank Barknecht -
Hans-Christoph Steiner -
Mathieu Bouchard -
padawan12