 | |
Splitting a text string into fields
comp.databases.filemaker comp.databases.filemaker
 |
| | Thread Tools | Display Modes |
#11
 
| ||||||||
| ||||||||
|
Re: Splitting a text string into fields -
11-28-2005
, 06:49 PM
|
The original poster didn't really much say what he intended to do with the resulting fields, or why he wanted to enter the data this way. Without knowing those conditions, it's really impossible to say which is too simple or which is too overkill a solution. I still think the method I presented is more flexible generally. |
Quote:
|
1) To me, the p1, p2, p3, ... pN construct suggests a variable number of breakouts, as opposed to word 1 being the width, word 2 being the height, word 3 being the depth, or something like that where the position of a value has a unique meaning. What he seemed to want is an array within a record. |
fixxed length array in a record that he wanted to 'fix'.
Quote:
|
- Repeating fields are much more convenient to reference within calculations algorithmically, as an array [GetRepetition(p;N)], than a discrete field like pN. I guess you could use Evaluate("p" & N), but still. - Breaking it into a single repeating field is a lot more forward-looking because you don't have to add fields when you add values. |
fields" in the same sentance, *and* retain credibility. Nicely done!!
Quote:
|
- You can easily manipulate and analyze the contents of a repeating field (Min, Max, Average, Sum, Count, etc.) - The ability to automatically split the values into records is forward-looking and a non-trivial advantage, whether the OP mentioned it or not. Using discreet fields makes this more of a chore later on. 2) the pN = (MiddleWords(myInput,N,1) is soooo obvious and pedestrian... |
Quote:
|
Plus, you have the chore to repeat and update that field/function with every additional item. This solution takes just one field, one calc. (And, better to learn a nifty trick and a new function along the way.) |
Quote:
|
3) Technically the data doesn't even need to be broken out into another field since the Words-related functions can do all the manipulation on their own. |
export it, or view it on the screen, sure. But I'm not even sure why
your bothering to store it in a database if you are going to give up all
that.
Quote:
|
4) I like to irk people who are dogmatically opposed to repeating field usage of any kind |
[Denormalized data... not even satisfying first normal form... it
burns... it buuuurns....]
Quote:
|
Bill |
#12
| |||
| |||
|
|
Dave, I read your answer and re-read it, and again, but my english, while not so bad, does not makes me sure to understand fully the message you're carrying. Simply said : do you agree on my conclusions : in FMP6 performing a task with a script may run 10 times quicker than with calculations ? |
than with calculations, *particularly* in FMP6 and under.
Under FM7+, with proper use of let, I would expect that the *theoretical
advantage* that scripts have should be *dramatically reduced* in most
cases.
I don't have any specific FM7+ example where a script outruns a
calculation, but I wouldn't go so far as to say it doesn't exist. I do
know I've seen some really wonky performance stuff with FM6 to FM7
upgrades, but I really haven't nailed them down as to WHY.
(e.g. in FM6 I've seen an autoenter calc on new record that's lightning
fast, but in FM7 be slow as molasses, but putting it into a set field in
a 'new record script' is lightning fast... I'm still sorting out the
root cause for that...
I know ONE of them is the combination of an autoenter and a unique
requirement on field validation causes new records in large FM7 systems
to choke)
Quote:
|
You made a lot of clever in-sights on how and why but I'd prefer a clear cut statement at least on the result. If you don't, then it would mean for me that I am responsible of the poor performances in calculations with a bad design. |
Quote:
|
Remi-Noel |
#13
| |||
| |||
|
|
Seems a little over thought... Why not just p1 = (MiddleWords(myInput,1,1) p2 = (MiddleWords(myInput,2,1) p3 = (MiddleWords(myInput,3,1) I'm not sure I see the point of send it through a repitions construct. -regards, Dave In article <FeWdnZURFZqfpRbenZ2dnUVZ_tKdnZ2d (AT) comcast (DOT) com>, wjm (AT) wjm (DOT) org says... Yes, you can do this. Given the field myInput(text) myOutput(calculation, text result, 99 repetitions)= MiddleWords(Extend(myInput);Get(CalculationRepetit ionNumber);1) Will place each discreet value into a separate repetition. If you then need to have these repetitions further broken up into individual fields, you can simply use the GetRepetition function. Example: p1 (calculation, text result) = GetRepetition ( myOutput; 1) p2 (calculation, text result) = GetRepetition ( myOutput; 2) p3 (calculation, text result) = GetRepetition ( myOutput; 3) and so on. Bill "Elke Maartens" <take (AT) byte (DOT) fris> wrote in message news:291120050339410269%take (AT) byte (DOT) fris... Hey gurus, I have a challenge. Well , it's a challenge for me [!] but maybe not for you experts. Input is a text string, containing de facto delineators: such as spaces between words, or markers in a file path, etc. Here's an example. This string i1 3.5 7.5 7460 50 needs to be split into fields (p1, p2 ... etc) p1 = i1 p2 = 3.5 p3 = 7.5 p4 = 7460 p5 = 50 I have no problem writing an 'active' script to do the task, but really I'd like do the whole job with calculations. Partly it's aesthetics, but also because it's faster. My present approach is to split the string into a sequence of separated characters, then have a 'sheepdog script' run along the line and allocate them. That works fine, but it's slow, clunky, and a little unsatisfying! For example, when I recently made a major computer upgrade, I found the increased clockspeed was not reflected in the speed of the script, as (I guess) FMP is working off the disk, carting little bits of data around to do the job, rather than making good use of a faster CPU. Any ideas? Hints? I enjoy a challenge, but I have to admit I'm stuck, and I'd be really grateful for some help * even if it is only to put my mind at rest with a negative! TIA Elke |
simpler one works well enough, for the two tasks I have in mind. I've
also made a note of Bill's version, and can refer back to it if I find
myself needing a more complex solution in the future.
I've been using this application since FileMaker II, and did most of my
learning (with a printed manual) back in the days of FMP 3. This shows
how easy it is to miss new functions (like MiddleWords) and to live 'in
the past' in terms of solutions.
Thank you all for your suggestions. This has been a wonderful help, and
tonight I shall drink a toast to you all. What a shame I cannot buy you
dinner. You will have to treat yourselves!
Elke Maartens
PS. Elke is a girl's name, from the North Frisian Islands :-))
#14
| |||
| |||
|
|
Remi, I'm also suspicious that a script could do something faster that a calculation, but I'm not ready to challenge your calc-building skills. Perhaps you could provide a specific example where your script outperforms your calc and we could learn something by dissecting it? |
The situation was this : I had a client - FMS55 and 10 PCs - with a
complex result to make on each record with 15 different modes of
calculations. At first I computed thru calculations all the 15 solutions
on as many calculated fields, plus one field to choose the only one to
keep at the end depending on some criterias. The file had around 4000
records. But going from one record to another took each time something
like 5 to 10 seconds to show up. The client was not that happy.
So I did not rewrite but copied each of the 15 formulas in 15 global
fields to be run successively in a script. The time to perform that was
a blink of the eye, ie much less that one second per record.
The price to pay was that they had to click on a 'refresh' button rather
that getting the result automatically. To give you an idea : the printed
copy of that script (that I oversimplified above) was 6 pages long.
I got the same behaviour in another circumstance.
So I, pragmatically, decided that scripting a task is much more
efficient and quick in running than the calculation fields.
At that point things seemed rational, and that's why I posted my remark.
Now, you asked me to make an example to 'dissect'.
So I copied that file and eliminated most of the fields, scripts etc.
that were not needed for the purpose of the example. Then I made it run
both ways once with the calculated fields and another time with the
script. And know what, the result was about the same. Everything was
quick : a subsecond response time per record. I tried with 30 records
first, then with all 4000 records : the same.
So the less I can say is that I am confused.
I can send that example to you if you wish, but it's less critical now,
isn't it?
I am saying all that just to be honest with you all ...
Remi-Noel
#15
| |||
| |||
|
|
"Bill Marriott" <wjm (AT) wjm (DOT) org> a écrit ... Remi, I'm also suspicious that a script could do something faster that a calculation, but I'm not ready to challenge your calc-building skills. Perhaps you could provide a specific example where your script outperforms your calc and we could learn something by dissecting it? Bill and Dave, The situation was this : I had a client - FMS55 and 10 PCs - with a complex result to make on each record with 15 different modes of calculations. At first I computed thru calculations all the 15 solutions on as many calculated fields, plus one field to choose the only one to keep at the end depending on some criterias. The file had around 4000 records. But going from one record to another took each time something like 5 to 10 seconds to show up. The client was not that happy. So I did not rewrite but copied each of the 15 formulas in 15 global fields to be run successively in a script. The time to perform that was a blink of the eye, ie much less that one second per record. The price to pay was that they had to click on a 'refresh' button rather that getting the result automatically. To give you an idea : the printed copy of that script (that I oversimplified above) was 6 pages long. I got the same behaviour in another circumstance. So I, pragmatically, decided that scripting a task is much more efficient and quick in running than the calculation fields. At that point things seemed rational, and that's why I posted my remark. Now, you asked me to make an example to 'dissect'. So I copied that file and eliminated most of the fields, scripts etc. that were not needed for the purpose of the example. Then I made it run both ways once with the calculated fields and another time with the script. And know what, the result was about the same. Everything was quick : a subsecond response time per record. I tried with 30 records first, then with all 4000 records : the same. So the less I can say is that I am confused. I can send that example to you if you wish, but it's less critical now, isn't it? I am saying all that just to be honest with you all ... Remi-Noel |
now?
That can add an extra wrinkle to the mix.
-regards,
dave
#16
| |||
| |||
|
|
"Bill Marriott" <wjm (AT) wjm (DOT) org> a écrit ... Remi, I'm also suspicious that a script could do something faster that a calculation, but I'm not ready to challenge your calc-building skills. Perhaps you could provide a specific example where your script outperforms your calc and we could learn something by dissecting it? Bill and Dave, The situation was this : I had a client - FMS55 and 10 PCs - with a complex result to make on each record with 15 different modes of calculations. At first I computed thru calculations all the 15 solutions on as many calculated fields, plus one field to choose the only one to keep at the end depending on some criterias. The file had around 4000 records. But going from one record to another took each time something like 5 to 10 seconds to show up. The client was not that happy. So I did not rewrite but copied each of the 15 formulas in 15 global fields to be run successively in a script. The time to perform that was a blink of the eye, ie much less that one second per record. The price to pay was that they had to click on a 'refresh' button rather that getting the result automatically. To give you an idea : the printed copy of that script (that I oversimplified above) was 6 pages long. I got the same behaviour in another circumstance. So I, pragmatically, decided that scripting a task is much more efficient and quick in running than the calculation fields. At that point things seemed rational, and that's why I posted my remark. Now, you asked me to make an example to 'dissect'. So I copied that file and eliminated most of the fields, scripts etc. that were not needed for the purpose of the example. Then I made it run both ways once with the calculated fields and another time with the script. And know what, the result was about the same. Everything was quick : a subsecond response time per record. I tried with 30 records first, then with all 4000 records : the same. So the less I can say is that I am confused. I can send that example to you if you wish, but it's less critical now, isn't it? I am saying all that just to be honest with you all ... Remi-Noel |
now?
That can add an extra wrinkle to the mix.
-regards,
dave
#17
| |||
| |||
|
|
I just tried it home on my own single PC. You makes me think that the client' network may be part of it. Next time I go there (next week) I'll try my 'example' on the server. Remi-Noel |
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.