Calculating Possible Journeys

[Ninja]

I have a repeating number field (20 reps) which contains location names allong a route. E.g: A,B,C,D & E in the first 5 repetitions and nothing in the rest. I need to create a calculation based on each being a possible starting position, but only the following ones being possible destinations. ie: the calc field should contain:

A-B

A-C

A-D

A-E

B-C

B-D

B-E

C-D

C-E

D-E

It should also not include any of the blank repetitions producing lines such as "A-" or "B-". And it may contain a full 20 locations (E.g: A-T)

I tried something allong the lines of:

GetRepetion(<Field>,1) & "-" & GetRepetion(<Field>,2) & "<paragraph Symbol" &

GetRepetion(<Field>,1) & "-" & GetRepetion(<Field>,3) & "<paragraph Symbol" & ...

Etc. But as you can imagine it is quite lengthy and includes all repetitions even empty ones.

Anyone got any clever ideas?

[Søren Dyhr]

I have a repeating number field (20 reps) which contains data A,B,C,D & E in the first 5 repetitions.

Unless you're very good, shouldn't data be stored in repeaters - There might be some sence in storing ID's of records but human readable stuff NO. You'd better explain why you have lost your heart to them???

A philospher have once written:

"True wisdom knows

it must comprise

some nonsense

as a compromise,

lest fools shouls fail

to find it wise."

You might ask why it's wise? Because only overly religious people hessitate to ask to the nonsence ...call it a socratian test to recognize the position where the questioner actually is mentally - If you wish!

--sd

[comment]

Is it ALWAYS 5 repetitions, or is that just an example?

[Ninja]

Thats just an example. it could be up to the full 20 reps, this is why i am wondering if anyone has a clever way of doing it so i dont have to write a calculation for every one of the possible journeys in a 20 location record!

As for Dhyr, A,B,C,D & E are just examples, the actual data would be text strings representing location names, each location being stored in a separate locations file with an associated serial number for each one.

And as for all the socratian crap, all very well, but i don't think he ever used FileMaker, atleast not version 6!

[comment]

IMHO, a clever way would start by moving the locations into a more predictable form.

[comment]

Here is an idea of a possible approach. It requires that there be no empty repetitions BETWEEN destinations.

combrep.zip

[-Queue-]

Here's another fun little experiment. It has the same requirement, plus an additional one: you have to either click in the field or create a refresh script for it. But I think it's useful for theoretical study, at least.

combrepv2.zip

[comment]

it's useful for theoretical study

To me it is. I never thought of "draining" a repeating field through a value list. That is useful.

Just thinking out loud for a moment: what is the purpose here?

Suppose the locations are bus stops, describing a route. The result is a multi-line key.

On the other side we have a traveller specifying a departure point and a destination. The traveller wants to see all the bus routes that go from the departure point to the destination.

If so, there's no need to eliminate empty or half-empty lines. In fact, a line like

"Tulsa - "

might well serve the passenger that says "Get me the hell out of Tulsa, I don't care where to!".

Not to mention a real classic:

" - Rome"

[Søren Dyhr]

Just thinking out loud for a moment: what is the purpose here?

Thats why I couldn't resist throwing in the quotation with "nonsence" which btw not is Socrates, but a chap called Piet Hein - I actually asked right away but, didn't recieve an answer!

Is the reason for the repeaters - the old template ANDSearch by Jon Rosen published in ISO ezine way back in previous century??

--sd

[comment]

Hi Soren,

Actually, it may be quite reasonable to use a repeating field to build a route.

At least in terms of UI it seems the most elegant solution.

And if indeed we are buliding a key here, then it can simply stay in repeating mode, so no harm is done (and Queue doesn't need to worry about his final step not refreshing).

[-Queue-]

Ninja specified that "it should also not include any of the blank repetitions producing lines such as "A-" or "B-". I used that as part of my criteria for the solution. It could be changed to include those options, and only leave out the "A-A" ones. There are quite a few possibilities here.

Comment, you should check out the repetition master DJ's textual math samples here, which were the inspiration for my idea. In fact, you should read every post of his that seems interesting, as I'm certain Ugo would agree.

[comment]

Ninja specified that "it should also not include any of the blank repetitions

So he did. And both proposed solutions followed this specification. Still, I am asking why not? IMHO one can advise much more efficiently when one sees the big picture. So often it turns out that the real solution lies elsewhere.

you should read every post of [Djukic Goran]

That's something already on my to-do list - but thanks anyway!

[Søren Dyhr]

Hi Queue

Your linking to DJ's thread starts:

perform some math operations(without scripts)

Now you're using Windows and might be a stranger to these priciples:

http://developer.apple.com/documentation...00353/TPXREF107

...a sort of consistency that admitted are imposible to maintain for windows, but I guess that even Windows users feels the same kind of relief when returning from KDE's or Gnome's freewheeling of what the user can expect to be happening behind the scenes. But isn't there a tiny bit of vanity in the desire to get some SERIOUS stuff done without the users interaction???

I would guess that no user have ever suffered weight loss or amnesia by being too eagerly pressing buttons. Scripting isn't that bad given the processing speeds availiable today - as long as the developer takes care of trimming off useless fat from the scripts. The same thing could be said about trig on exit plugins, why shouldn't the user have any chance to hessitate and decide the pace for him/her self???

--sd

[Søren Dyhr]

So often it turns out that the real solution lies elsewhere.

Hear, hear!!!

--sd

[comment]

That's a good point you raise here. I am sure this would not be the ONLY rule, but I beieve that you are entitled to make the user press a button when the user is creating something. This must be evaluated from the user's point of view.

So, for example, I will almost always have Add/Cancel buttons on a New Record layout.

OTOH, when a user has changed some data, it is not reasonable to ask "now please press a button to regenerate a key for this record". The user cares not about keys and such. From his POV, he has changed some of HIS data. Now it's up to the application to deal with it.

[Søren Dyhr]

The user cares not about keys and such.

Neither does he/she care if it's repeaters that makes the keys it could also be done by 3 fields and a selfjoin:

Delete All Records [ No dialog ] 

New Record/Request 

Set Field [ perm::Field1; 0 ] 

Set Field [ perm::Field2; 0 ] 

Loop 

         Set Field [ perm::Field1; perm::Field1 + 1 ] 

         Set Field [ perm::Field2; "" ] 

         Loop 

                    Set Field [ perm::Field2; Count ( SJoin::Field1 ) + perm::Field1+1 ] 

                    Duplicate Record/Request 

                    Exit Loop If [ perm::Field2 = perm::NumberOfOptions ] 

         End Loop 

         Exit Loop If [ perm::Field1 = perm::NumberOfOptions-1 ] 

End Loop 

...and suddently is the number of destinations not limited to the confines of the repeaters def.

--sd

[comment]

I don't follow you (that's a first, huh?).

I believe we have a record per route. A route has stops (departure point + n destinations, in a given order). There is another file with all the stops for all the routes.

Before getting to the keys - where and how would you have the user input the stops for a particular route?

[Ugo DI LUCA]

Hi,

Neither would I be concerned to use repeaters here, even unstored, as the compilation might be made in a special interface and stored in some distant records by a simple lookup to another indexed rep.

That's where I'd use a button actually.

If this solution was made with FM7, the additional number of fields required in JayTee's template would be probably reduced to 4, by involving Let ( ), Get(CalculationRepetitionNumber) and Evaluate ( ).

As long as the developper clearly knows the max number of repetitions ever involved, it should stay a valid dynamic alternative

We still don't know what exact use Ninja is expecting from such a structure though...

By the way JT, nice work. Was nice playing with 5 again he !

[comment]

If this solution was made with FM7, the additional number of fields required in JayTee's template would be probably reduced to 4

Hm. I did it in FMP4 with only 2 fields (and could have done it with just one).

So what's the advantage of admittedly greater sophistication?

[Søren Dyhr]

I believe we have a record per route. A route has stops (departure point + n destinations, in a given order). There is another file with all the stops for all the routes.

But isn't departure points destinations as well?? My list of combinations plucks the value item N via field1 or field2 from a valuelist, which is measured for the number of pilcrows.... So if 25 destination/departure points exists in the list, a portal is filled with all the combinations of these 25 leaving out the dupes as well as reversed order dupes (301 that is) - to let the user pick one via a button in the portal.

Destinations/depaturepoints could also live in a table/base of it's own also containing a figure for the distance between the two points. If the locations field1 and field point's at instead got transfered via a lookup could a new valuelist be build to be shown as a new valuelist of pairs...

Well I don't know - If just we had some hints for the deploiment?:

--sd

[comment]

I think this time you missed my point:

The user defining a route has to enter the stops:

(a) in a given order;

(: from a list of all possible stops.

(as the poster explained, "each location being stored in a separate locations file with an associated serial number for each one".)

Presumably, the user should also be capable of easily changing the route.

Of course, you could make scripts and tricks to build the route's list of stops in any form you like; but IMHO this simply begs for a repeating field.

If it turns out that the data is used for purposes other than building a key, I will cross over to your camp.

[-Queue-]

Hm. I did it in FMP4 with only 2 fields (and could have done it with just one).

Very true. I think Ugo was referring to the possibility of a more dynamic solution than can be obtained with previous versions. Your calculation, after all, is basically hard-coded and would require attentive user-revision if more locations were desired, whereas mine only necessitates additional repetitions and sequential numbers added to the global index field. If done in 7, you would not need the global, index, modtime, or trigger fields, and Let and Evaluate could be used in place of others. Extending the solution would merely require defining a different number of repetitions.

At least, that's what I *think* he meant.

[comment]

Your calculation, after all, is basically hard-coded and would require attentive user-revision if more locations were desired

I agree.

If done in 7, you would not need the global, index, modtime, or trigger fields, and Let and Evaluate could be used in place of others

IMHO, if done in v.7, one could leave the "old-style" thought-patterns behind and go along the lines of:

LocationsR & " - " & GetRepetition ( LocationsR ; Get ( CalculationRepetitionNumber ) + 1 )

Add a couple of conditions, and it's done: single field AND self-adjusting to any # of repetitions.

[-Queue-]

I think it would be a little more involved, since that would only produce one combination for each repetition. But a single, dynamic calculation would be sweet.

[comment]

Come to think of it, yes - it is a bit more complex. But let me toss up an idea:

Suppose the results field has, by design, more repetitions that the data field. And it does produce only one combination per repetition. It would be:

GetRepetition ( dataR ; x ) & " - " & GetRepetition ( dataR ; y )

The trick would be to come up with the right formulae for incrementing x and y as functions of Count (dataR) and Get ( CalculationRepetitionNumber ).

(y would probably need to be a function of x as well.)

[-Queue-]

Ooh, I like this idea. I'm on it when I get home.

[Ugo DI LUCA]

Comment,

Actually, with 7, I'd involve relationship myself. If for display purpose the user wants to involve a repeating field, it would still be possible parsing each key's combo, without any script anyway, playing with the key structure on the Stops Table.

I was just arguing about the codes and possible workarounds, given 7 enhancements for repeating fields.

But then we still don't know what the purpose is.

Tours.zip

[comment]

Here's the KISS version of DJ's text "multiplication" math.

TextMultiply.fp7.zip

[Ugo DI LUCA]

Congrats. Nice job.

[comment]

Thanks.

I have added another one - this will pair-up all the values in a single repeating field, excluding identical pairs.

TextMultiply.fp7.zip

[LaRetta]

In post #11 of this thread, Queue mentions somone named DJ (Djukic Goran) and provides a link. The link appears to be broken. Does anyone know where this link points?

[Lee Smith]

http://fmforums.com/forum/topic/14921-math-with-text/

[LaRetta]

Thank you, Lee! :laugh2:

[Lee Smith]

If you have problems with the file let me know