hi,
i'm using
[symbol2list -] | | [symbol( | | | [list2symbol]
on something like 00-ab-87-02. the result becomes 0ab872. so, i'm losing the leading zero's.
in other words the symbol '00' is handled like a number, probably any symbol that looks like a number is immediately treated like that. which, in the case above is unexpected (at least for me).
would it then be necessary, working with texts, always to check if one's not accidentally losing zero's?
rolf
As long as its a float, it'll be converted to the simplest form. So 0 is the simplest form of 00. The same would happen with 0.0000. So if you need 00 in a symbol, you'll need generate it by some other method first, like sending the list [0 0( to [list2symbol].
If you are using this for MAC addresses or other similar numbers, they usually consider 0 and 00 the same thing.
.hc
On Wednesday, November 02, 2011 6:06 PM, "rolf meesters" rolfmeesters@gmail.com wrote:
hi,
i'm using
[symbol2list -] | | [symbol( | | | [list2symbol]
on something like 00-ab-87-02. the result becomes 0ab872. so, i'm losing the leading zero's.
in other words the symbol '00' is handled like a number, probably any symbol that looks like a number is immediately treated like that. which, in the case above is unexpected (at least for me).
would it then be necessary, working with texts, always to check if one's not accidentally losing zero's?
rolf
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Wed, Nov 2, 2011 at 7:28 PM, Hans-Christoph Steiner hans@at.or.atwrote:
As long as its a float, it'll be converted to the simplest form. So 0 is the simplest form of 00. The same would happen with 0.0000. So if you need 00 in a symbol, you'll need generate it by some other method first, like sending the list [0 0( to [list2symbol].
understand i well then, that parsing an unknown text the character '0' runs the risk of disappearing when it's in a 'wrong' position. and in Pd i will never know when this has happened.
If you are using this for MAC addresses or other similar numbers, they usually consider 0 and 00 the same thing.
in WindowsXP register all the characters are needed in one string.
rolf
On Wednesday, November 02, 2011 6:06 PM, "rolf meesters"
rolfmeesters@gmail.com wrote:
hi,
i'm using
[symbol2list -] | | [symbol( | | | [list2symbol]
on something like 00-ab-87-02. the result becomes 0ab872. so, i'm losing the leading zero's.
in other words the symbol '00' is handled like a number, probably any symbol that looks like a number is immediately treated like that. which, in the case above is unexpected (at least for me).
would it then be necessary, working with texts, always to check if one's not accidentally losing zero's?
rolf
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-11-02 18:06, rolf meesters wrote:
hi,
i'm using
[symbol2list -] | | [symbol( | | | [list2symbol]
on something like 00-ab-87-02. the result becomes 0ab872. so, i'm losing the leading zero's.
in other words the symbol '00' is handled like a number, probably any symbol that looks like a number is immediately treated like that. which, in the case above is unexpected (at least for me).
the idea is, that [symbol2list] breaks a symbol into a list of _atoms_, which are then evaluated the same way as ordinary lists (though i'm not sure whether it is implemented that way...)
e.g. is you create a message [list 00 ab 87 02( the 1st and last element of the list will evaluate to numbers (and thus "lose" their leading zeros). does this come unexpected to you?
however, it might be worth considering a "symbol only" mode of the object, that will never try to convert a token into a number but always keep it a symbol.
would it then be necessary, working with texts, always to check if one's not accidentally losing zero's?
btw, you are not "losing" any zeros. whether your pay cheque says "100,-€" or "000000000000100,-€" does not make any difference, when it comes to buying your marmite. those numbers are exactly the same.
if you need "00-ab" to split into two 2-character strings "00" and "ab" and want to use [symbol2list], you could simply convert all the numbers you got to 2-char strings by using [makefilename %02d]
mfgasdr IOhannes
----- Original Message -----
From: IOhannes m zmoelnig zmoelnig@iem.at To: pd-list@iem.at Cc: Sent: Thursday, November 3, 2011 4:20 AM Subject: Re: [PD] symbol2list leading zero
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-11-02 18:06, rolf meesters wrote:
hi,
i'm using
[symbol2list -] | | [symbol( | | | [list2symbol]
on something like 00-ab-87-02. the result becomes 0ab872. so, i'm losing the leading zero's.
in other words the symbol '00' is handled like a number, probably any symbol that looks like a number is immediately treated like that. which, in the case above is unexpected (at least for me).
the idea is, that [symbol2list] breaks a symbol into a list of _atoms_, which are then evaluated the same way as ordinary lists (though i'm not sure whether it is implemented that way...)
e.g. is you create a message [list 00 ab 87 02( the 1st and last element of the list will evaluate to numbers (and thus "lose" their leading zeros). does this come unexpected to you?
however, it might be worth considering a "symbol only" mode of the object, that will never try to convert a token into a number but always keep it a symbol.
That would be useful.
-Jonathan
would it then be necessary, working with texts, always to check if
one's
not accidentally losing zero's?
btw, you are not "losing" any zeros. whether your pay cheque says "100,-€" or "000000000000100,-€" does not make any difference, when it comes to buying your marmite. those numbers are exactly the same.
if you need "00-ab" to split into two 2-character strings "00" and "ab" and want to use [symbol2list], you could simply convert all the numbers you got to 2-char strings by using [makefilename %02d]
mfgasdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6yTuUACgkQkX2Xpv6ydvT0+gCg497mHIcEDjGpsxVMpf9RvSLe O8QAn3a0g1mcH/CC054qXyQrNdhYYgB8 =bjB6 -----END PGP SIGNATURE-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Le 2011-11-03 à 09:20:00, IOhannes m zmoelnig a écrit :
On 2011-11-02 18:06, rolf meesters wrote:
would it then be necessary, working with texts, always to check if one's not accidentally losing zero's?
btw, you are not "losing" any zeros. whether your pay cheque says "100,-€" or "000000000000100,-€" does not make any difference, when it comes to buying your marmite. those numbers are exactly the same.
And this is exactly not what Rolf is talking about.
Surely you know the difference between string comparisons and number comparisons...
If someone just wants to split lists instead of converting to floats and getting weird answers on pd-list, there's [gf/s2l], which does not do anything else than splitting (as it is like with any string-splitter outside of pd/max).
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
----- Original Message -----
From: Mathieu Bouchard matju@artengine.ca To: IOhannes m zmoelnig zmoelnig@iem.at Cc: pd-list@iem.at Sent: Thursday, November 3, 2011 10:51 AM Subject: Re: [PD] symbol2list leading zero
Le 2011-11-03 à 09:20:00, IOhannes m zmoelnig a écrit :
On 2011-11-02 18:06, rolf meesters wrote:
would it then be necessary, working with texts, always to check if
one's
not accidentally losing zero's?
btw, you are not "losing" any zeros. whether your pay cheque says "100,-€" or
"000000000000100,-€" does not
make any difference, when it comes to buying your marmite. those numbers are exactly the same.
And this is exactly not what Rolf is talking about.
Surely you know the difference between string comparisons and number comparisons...
If someone just wants to split lists instead of converting to floats and getting weird answers on pd-list, there's [gf/s2l], which does not do anything else than splitting (as it is like with any string-splitter outside of pd/max).
Once split, is there a way to convert symbol-atom "19.95" to a float?
-Jonathan
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Thu, 2011-11-03 at 08:33 -0700, Jonathan Wilkes wrote:
From: Mathieu Bouchard matju@artengine.ca
If someone just wants to split lists instead of converting to floats and getting weird answers on pd-list, there's [gf/s2l], which does not do anything else than splitting (as it is like with any string-splitter outside of pd/max).
Once split, is there a way to convert symbol-atom "19.95" to a float?
Two work-arounds come to my mind:
Send the symbol to [textfile] save it as a file, read the file again and output the result.
Send it through a [netsend] / [netreceive] pair.
The former involves writing to disk, but the latter is even worse in that messes up depth-first order.
Roman
----- Original Message -----
From: Roman Haefeli reduzent@gmail.com To: pd-list@iem.at Cc: Sent: Thursday, November 3, 2011 4:36 PM Subject: Re: [PD] symbol2list leading zero
On Thu, 2011-11-03 at 08:33 -0700, Jonathan Wilkes wrote:
From: Mathieu Bouchard matju@artengine.ca
If someone just wants to split lists instead of converting to floats
and getting
weird answers on pd-list, there's [gf/s2l], which does not do
anything else
than splitting (as it is like with any string-splitter outside of
pd/max).
Once split, is there a way to convert symbol-atom "19.95" to a
float?
Two work-arounds come to my mind:
- Send the symbol to [textfile] save it as a file, read the file again
and output the result.
- Send it through a [netsend] / [netreceive] pair.
The former involves writing to disk, but the latter is even worse in that messes up depth-first order.
I've written Pd Vanilla hacks that do it without writing to disk and posted them on the list. But I'm talking about GF solutions.
-Jonathan
Roman
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Thu, 2011-11-03 at 13:43 -0700, Jonathan Wilkes wrote:
----- Original Message -----
From: Roman Haefeli reduzent@gmail.com To: pd-list@iem.at Cc: Sent: Thursday, November 3, 2011 4:36 PM Subject: Re: [PD] symbol2list leading zero
On Thu, 2011-11-03 at 08:33 -0700, Jonathan Wilkes wrote:
From: Mathieu Bouchard matju@artengine.ca
If someone just wants to split lists instead of converting to floats
and getting
weird answers on pd-list, there's [gf/s2l], which does not do
anything else
than splitting (as it is like with any string-splitter outside of
pd/max).
Once split, is there a way to convert symbol-atom "19.95" to a
float?
Two work-arounds come to my mind:
Send the symbol to [textfile] save it as a file, read the file again and output the result.
Send it through a [netsend] / [netreceive] pair.
The former involves writing to disk, but the latter is even worse in that messes up depth-first order.
I've written Pd Vanilla hacks that do it without writing to disk
Aha.
and posted them on the list.
Any pointers?
Roman
----- Original Message -----
From: Roman Haefeli reduzent@gmail.com To: "pd-list@iem.at" pd-list@iem.at Cc: Sent: Thursday, November 3, 2011 4:47 PM Subject: Re: [PD] symbol2list leading zero
On Thu, 2011-11-03 at 13:43 -0700, Jonathan Wilkes wrote:
----- Original Message -----
From: Roman Haefeli reduzent@gmail.com To: pd-list@iem.at Cc: Sent: Thursday, November 3, 2011 4:36 PM Subject: Re: [PD] symbol2list leading zero
On Thu, 2011-11-03 at 08:33 -0700, Jonathan Wilkes wrote:
> From: Mathieu Bouchard matju@artengine.ca
> If someone just wants to split lists instead of converting
to floats
and getting
> weird answers on pd-list, there's [gf/s2l], which does
not do
anything else
> than splitting (as it is like with any string-splitter
outside of
pd/max).
Once split, is there a way to convert symbol-atom
"19.95" to a
float?
Two work-arounds come to my mind:
- Send the symbol to [textfile] save it as a file, read the file
again
and output the result.
- Send it through a [netsend] / [netreceive] pair.
The former involves writing to disk, but the latter is even worse in that messes up depth-first order.
I've written Pd Vanilla hacks that do it without writing to disk
Aha.
and posted them on the list.
Any pointers?
Yes-- use an external. :)
Mine is specific to breaking fractions into two floats: http://article.gmane.org/gmane.comp.multimedia.puredata.general/78523/match=...
-Jonathan
Roman
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Le 2011-11-03 à 13:43:00, Jonathan Wilkes a écrit :
I've written Pd Vanilla hacks that do it without writing to disk and posted them on the list. But I'm talking about GF solutions.
I don't remember a GF external for doing this, but if you want one, you can add the following external to a GF source file (before the \startall) and recompile :
\class Strtof { \constructor () {} \decl 0 symbol (const char *s) { char *e; float f=strtof(s,&e); if (e==s+strlen(s)) out0; else out1; } }; \end class {install("strtof",1,2);}
Or I could make it part of GridFlow.
It outputs the float on the left if the symbol was fully parsed, or bang on the right otherwise.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
On Thu, 2011-11-03 at 10:51 -0400, Mathieu Bouchard wrote:
Le 2011-11-03 à 09:20:00, IOhannes m zmoelnig a écrit :
On 2011-11-02 18:06, rolf meesters wrote:
would it then be necessary, working with texts, always to check if one's not accidentally losing zero's?
btw, you are not "losing" any zeros. whether your pay cheque says "100,-€" or "000000000000100,-€" does not make any difference, when it comes to buying your marmite. those numbers are exactly the same.
And this is exactly not what Rolf is talking about.
Surely you know the difference between string comparisons and number comparisons...
If someone just wants to split lists instead of converting to floats and getting weird answers on pd-list, there's [gf/s2l], which does not do anything else than splitting (as it is like with any string-splitter outside of pd/max).
Yeah, and currently there is no way really to tell Pd whether something should be of the type symbol or float, so the fact that it assumes anything that looks like a number to be float makes sense (you can still force numbers to be symbols as few already suggested). And it does not make so much sense to compare Pd/Max to anything outside of Pd/Max. [symbol2list] behaves pretty sensible in its context, as pretty much anything in Pd converts 00023.1 or 23.100000 to 23.1. Calling the previous answers 'weird' is inappropriate, IMHO.
(BTW, I'm not saying I favor Pd's limited type casting capabilities)
Roman
On Thu, 2011-11-03 at 17:54 -0400, Mathieu Bouchard wrote:
Le 2011-11-03 à 21:09:00, Roman Haefeli a écrit :
And it does not make so much sense to compare Pd/Max to anything outside of Pd/Max.
Why ?
You said "(as it is like with any string-splitter outside of pd/max)". I should have said it more precisely: It doesn't make sense to compare Pd/Max with anything outside of Pd/Max regarding string-splitting, because 'just' splitting symbols (without the implicit conversion to float for number-like symbols) is not very practical in the Pd/World.
Roman
Le 2011-11-04 à 08:56:00, Roman Haefeli a écrit :
You said "(as it is like with any string-splitter outside of pd/max)". I should have said it more precisely: It doesn't make sense to compare Pd/Max with anything outside of Pd/Max regarding string-splitting, because 'just' splitting symbols (without the implicit conversion to float for number-like symbols) is not very practical in the Pd/World.
How do you know that it isn't practical to have numeric symbols when splitting ?
If I read /etc/passwd (list of users on Linux&OSX) and I split at colons and commas to get phone numbers, do you think I want Pd's help at rounding a phone number from 383.3801 to 383.38 when converting (aller-retour) from symbol to float to symbol, because it had too many significant digits for Pd's taste ?
So, just call me at 383.38 because it's more practical than dialling 383.3801 ! ;)
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
On Fri, Nov 4, 2011 at 15:38, Mathieu Bouchard matju@artengine.ca wrote:
Le 2011-11-04 à 08:56:00, Roman Haefeli a écrit :
You said "(as it is like with any string-splitter outside of pd/max)". I
should have said it more precisely: It doesn't make sense to compare Pd/Max with anything outside of Pd/Max regarding string-splitting, because 'just' splitting symbols (without the implicit conversion to float for number-like symbols) is not very practical in the Pd/World.
How do you know that it isn't practical to have numeric symbols when splitting ?
If I read /etc/passwd (list of users on Linux&OSX) and I split at colons and commas to get phone numbers, do you think I want Pd's help at rounding a phone number from 383.3801 to 383.38 when converting (aller-retour) from symbol to float to symbol, because it had too many significant digits for Pd's taste ?
So, just call me at 383.38 because it's more practical than dialling 383.3801 ! ;)
Ultimately, who would dare to call James Bond "Agent 7"?
András
-
András Murányi -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Jonathan Wilkes -
Mathieu Bouchard -
rolf meesters -
Roman Haefeli