hello,
pd-vanilla question: trying to harness geodata from an xml file, i need to parse lines like this: gx:coord8.689756393432365 49.4138 109.18</gx:coord> with a combination of "list split“ and „list fromsymbol“ i end up with three message boxes, „8.689756393432365“, „49.4138“ and „109.18“. problem is, that the message box containing „8.689756393432365“ is a symbol and i can´t seem to find a way to reconvert it to a float, other then sending it thru a netsend/netreceive pair. (as per this tip from 2007: https://lists.puredata.info/pipermail/pd-list/2007-02/047499.html).
its working fine, but i was wondering, if this really is the only vanilla solution?
i might well be staring at the obvious and not seeing it... thanks in advance for any other pointers!
best hans
www.hans-w-koch.net
hello,
if you want the conversion to be in 0 logical time, you can write the symbol in a textfile, and read it back.
something like :
[clear, add $1, write /tmp/symbol2float, read /tmp/symbol2float, rewind, bang< | [textfile]
but since it need to write the data somewhere, it's still not an ideal solution.
cheers Cyrille
Le 21/04/2017 à 15:40, hans w. koch a écrit :
hello,
pd-vanilla question: trying to harness geodata from an xml file, i need to parse lines like this: gx:coord8.689756393432365 49.4138 109.18</gx:coord> with a combination of "list split“ and „list fromsymbol“ i end up with three message boxes, „8.689756393432365“, „49.4138“ and „109.18“. problem is, that the message box containing „8.689756393432365“ is a symbol and i can´t seem to find a way to reconvert it to a float, other then sending it thru a netsend/netreceive pair. (as per this tip from 2007: https://lists.puredata.info/pipermail/pd-list/2007-02/047499.html).
its working fine, but i was wondering, if this really is the only vanilla solution?
i might well be staring at the obvious and not seeing it... thanks in advance for any other pointers!
best hans
www.hans-w-koch.net
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
thanks cyrille,
but the symbol 8.689756393432365 throws an "$1: argument number out of range“ error. by putting a „list prepend“ before the message box it works.
best hans
Am 21.04.2017 um 15:58 schrieb cyrille henry ch@chnry.net:
hello,
if you want the conversion to be in 0 logical time, you can write the symbol in a textfile, and read it back.
something like : [clear, add $1, write /tmp/symbol2float, read /tmp/symbol2float, rewind, bang< | [textfile]
but since it need to write the data somewhere, it's still not an ideal solution.
cheers Cyrille
Le 21/04/2017 à 15:40, hans w. koch a écrit :
hello,
pd-vanilla question: trying to harness geodata from an xml file, i need to parse lines like this: gx:coord8.689756393432365 49.4138 109.18</gx:coord> with a combination of "list split“ and „list fromsymbol“ i end up with three message boxes, „8.689756393432365“, „49.4138“ and „109.18“. problem is, that the message box containing „8.689756393432365“ is a symbol and i can´t seem to find a way to reconvert it to a float, other then sending it thru a netsend/netreceive pair. (as per this tip from 2007: https://lists.puredata.info/pipermail/pd-list/2007-02/047499.html).
its working fine, but i was wondering, if this really is the only vanilla solution?
i might well be staring at the obvious and not seeing it... thanks in advance for any other pointers!
best hans
www.hans-w-koch.net
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
On 21/04/17 15:40, hans w. koch wrote:
its working fine, but i was wondering, if this really is the only vanilla solution?
This could be helpful: http://forum.pdpatchrepo.info/topic/10556/vanilla-list2symbol-abstraction-pd...
I contains l2s, s2l and s2f (symbol to float).
best wishes, ingo
thanks, ingo,
s2f does the trick. since the datafiles i am working with are rather large (some 1000s of lines), i´ll try to make some speedtests over the weekend with the different solutions mentioned here.
best hans
Am 21.04.2017 um 16:00 schrieb Ingo Stock mail@ingostock.de:
On 21/04/17 15:40, hans w. koch wrote:
its working fine, but i was wondering, if this really is the only vanilla solution?
This could be helpful: http://forum.pdpatchrepo.info/topic/10556/vanilla-list2symbol-abstraction-pd...
I contains l2s, s2l and s2f (symbol to float).
best wishes, ingo
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
This link could help... (lokk at the bottom of the page) https://www.mail-archive.com/pd-list@lists.iem.at/msg05406.html ++
Jack
Le 21/04/2017 à 15:40, hans w. koch a écrit :
hello,
pd-vanilla question: trying to harness geodata from an xml file, i need to parse lines like this: gx:coord8.689756393432365 49.4138 109.18</gx:coord> with a combination of "list split“ and „list fromsymbol“ i end up with three message boxes, „8.689756393432365“, „49.4138“ and „109.18“. problem is, that the message box containing „8.689756393432365“ is a symbol and i can´t seem to find a way to reconvert it to a float, other then sending it thru a netsend/netreceive pair. (as per this tip from 2007: https://lists.puredata.info/pipermail/pd-list/2007-02/047499.html).
its working fine, but i was wondering, if this really is the only vanilla solution?
i might well be staring at the obvious and not seeing it... thanks in advance for any other pointers!
best hans
www.hans-w-koch.net
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 2017년 04월 21일 15:40, hans w. koch wrote:
i need to parse lines like this: gx:coord8.689756393432365
next thing you might want to have is double precision in Pd. At least single precision is a major headache when dealing with gpx coordinates in Pd. Maybe some abstractions in there can be useful for you, albeit there are bugs.
thank you max,
now i remember you posted this a while ago on the list, right? i had earmarked it and then forgotten... i am aware of the double precision dilemma (also encountered it in mobmuplat). for the purpose of parsing these files from bicycle tours offline, i was hoping to get away ignoring it, but i guess you are right to point it out again :-)
best hans
Am 21.04.2017 um 17:15 schrieb Max abonnements@revolwear.com:
On 2017년 04월 21일 15:40, hans w. koch wrote:
i need to parse lines like this: gx:coord8.689756393432365
next thing you might want to have is double precision in Pd. At least single precision is a major headache when dealing with gpx coordinates in Pd. Maybe some abstractions in there can be useful for you, albeit there are bugs.
One of my "workarounds" was to just take the numbers after the decimal devider and restrict yourself to an area that doesn't cross longitude or latitudes. This sort of works, exept this major limitation. Just now doing a workshop with audio walks in Riga and figured out another limitation.
24.07723 translates to 77238 because a leading zero just gets truncated obviously. outch. It's all possible somehow, but it would be so much easier with double precision.
m.
On 2017년 04월 21일 18:29, hans w. koch wrote:
thank you max,
now i remember you posted this a while ago on the list, right? i had earmarked it and then forgotten... i am aware of the double precision dilemma (also encountered it in mobmuplat). for the purpose of parsing these files from bicycle tours offline, i was hoping to get away ignoring it, but i guess you are right to point it out again :-)
best hans
Am 21.04.2017 um 17:15 schrieb Max abonnements@revolwear.com:
On 2017년 04월 21일 15:40, hans w. koch wrote:
i need to parse lines like this: gx:coord8.689756393432365
next thing you might want to have is double precision in Pd. At least single precision is a major headache when dealing with gpx coordinates in Pd. Maybe some abstractions in there can be useful for you, albeit there are bugs.
oh well…thats the reality these days: we restrict our movements, because computers can´t process them otheriwse :-)
+1 for double precision!
are you riga based? seems i am coming to liepeia end of may (sound days). maybe an occasion to meet.
best hans
Am 21.04.2017 um 19:17 schrieb Max abonnements@revolwear.com:
One of my "workarounds" was to just take the numbers after the decimal devider and restrict yourself to an area that doesn't cross longitude or latitudes. This sort of works, exept this major limitation. Just now doing a workshop with audio walks in Riga and figured out another limitation.
24.07723 translates to 77238 because a leading zero just gets truncated obviously. outch. It's all possible somehow, but it would be so much easier with double precision.
m.
On 2017년 04월 21일 18:29, hans w. koch wrote:
thank you max,
now i remember you posted this a while ago on the list, right? i had earmarked it and then forgotten... i am aware of the double precision dilemma (also encountered it in mobmuplat). for the purpose of parsing these files from bicycle tours offline, i was hoping to get away ignoring it, but i guess you are right to point it out again :-)
best hans
Am 21.04.2017 um 17:15 schrieb Max abonnements@revolwear.com:
On 2017년 04월 21일 15:40, hans w. koch wrote:
i need to parse lines like this: gx:coord8.689756393432365
next thing you might want to have is double precision in Pd. At least single precision is a major headache when dealing with gpx coordinates in Pd. Maybe some abstractions in there can be useful for you, albeit there are bugs.
-
cyrille henry -
hans w. koch -
Ingo Stock -
Jack -
Max