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

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

I question that. All experience I have (FMP6) tells me that scripting a
task runs it about 10 times faster that doing it through calculations.
I can even show you an example.
Ten times I say ...
Remi-Noel

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...

In article <438b3c70$0$9162$626a14ce (AT) news (DOT) free.fr>, rnmenegaux (AT) free (DOT) fr
says...
I've found that this is often based on poorly thought out calculations.
Filemaker doesn't, as far as I know, cache expression evaluations.

One of the big advantages to the Let function is the ability to manually
cache such evaluations. If you've got a complex expression ... e.g.
involving position, patterncount, substitute, replace, middle words, etc
to build some text, and then within that calculation you need to find
out its length 4 or 5 times in a case statement, your calc has to
evaluate that beast 6 or more times.

In a script, you'd just set field a global (or in 8 a variable) of the
whole mess, and maybe even its length in another, so they only get
evaluated once. (It makes it easier to read too).

7/8 provides tools to solve that, (and make calcs easier to read too) in
terms of the let statement, although I find its underused by most
developers.

On the other hand, poor use of the let statement combined with the
ability to write recursive custom functions gives those "smart"
programmers who come up with really neat complex recursive functions yet
who lack any real awareness of complexity theory all the rope they need
to *really* hang themselves.

Because it's one field, one calculation. And if he needs to create separate
records from those values, it's easier to split the repeating field during
import.

Bill


"42" <nospam (AT) nospam (DOT) com> wrote

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...

Ah. I see, you were thinking of splitting it up into different records
on an import. Yeah, that would make sense.

The OP, near as I can tell, just wanted to split text in one field into
separate fields.

-regards,
dave

In article <waadnR8pLa_R2xbenZ2dnUVZ_t6dnZ2d (AT) comcast (DOT) com>, wjm (AT) wjm (DOT) org
says...

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 ?
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.
Remi-Noel


"42" <nospam (AT) nospam (DOT) com> a écrit dans le message de news:
MPG.1df4e5d8a1b33cf1989de4 (AT) shaw....shawcable.net...

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.

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.

- 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.

- 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...
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.)

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.

4) I like to irk people who are dogmatically opposed to repeating field
usage of any kind

Bill

"42" <nospam (AT) nospam (DOT) com> wrote

Ah. I see, you were thinking of splitting it up into different records
on an import. Yeah, that would make sense.

The OP, near as I can tell, just wanted to split text in one field into
separate fields.

-regards,
dave

In article <waadnR8pLa_R2xbenZ2dnUVZ_t6dnZ2d (AT) comcast (DOT) com>, wjm (AT) wjm (DOT) org
says...

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

"Remi-Noel Menegaux" <rnmenegaux (AT) free (DOT) fr> wrote