Clairvoyance truncated both ways

[Søren Dyhr]

I wish to have a "contain sequence" of letters in a type ahead key, unfortunately isn't the end truncated ...enough. Further shouldn't it be a custom function yet, eventhough the partner here are just about to become Alliance Member.

Does anyone have such an algorithm handy???

--sd

[RalphL]

Have you looked at John Mark Osborne's "TypeAhead"?

[Søren Dyhr]

Yes both the new one as well as the old one - But they truncates on right hand side only - well there might be a solution by using the old with left( but here Right('ing the new versions utilizing a field with trailing zzzzz. But I hoped someone out there with the brains like Edohsin or Horak (Comment) had something finetuned fresh from the forge ...doing exactly this.

--sd

[comment]

My dear Soren,

1. Putting Edoshin and myself in the same class is a sacrilege - I have a very long way to go before I can even think of comparing myself to the master;

2. I would of course like to help you in any way I can, but I don't understand what is it that you're after - a bit more detail and an example, perhaps?

[Søren Dyhr]

What I look for is a kind of Fibonacci (this sequence isn't) sequence to pluck stings out of a persons full name, to make a multiline key - lets say the binary number represent which of the letters to pluck, where 1's are the chosens:

3 = 000011

6 = 000110

7 = 000111

12 = 001100

14 = 001110

15 = 011110

24 = 011000

28 = 011100

30 = 111100

...etc, instead of Left(, Middle( and Right( 'ing untill I drop ...when knowing such matters can be put on a "generator" formula to stuff right into a repeater with Get ( CalculationRepetitionNumber ) taking care of business.

I was the same thing when we skipped the mathematical explanation of getting rid of "

[Ender]

Not sure if this is what you're looking for, but building an exploded key with the text forward and reversed, then using that for the match field should give you clairvoyance in both directions.

If the search criteria is "son", matches would show for "Sonny" and "Anderson".

Attached is an FM7 sample that uses custom functions to do this.

AnyMatch.fp7.zip

[LaRetta]

Wow. Thank you, Mike! And thank you, JT!

JT gave me this solution a year ago right before 7 came out. I had wanted to review this issue (using 7 and Custom Functions).

If I enter vros, it produces the Halvorson record - matching anywhere within the text string. This was my ultimate goal with this key using Custom Function and vs. 7 - match in the middle of a word. And I wonder if this can incorporate into Ray's Clairvoyance (using SecureFM)! If so, I'll be one happy camper.

LaRetta

[Søren Dyhr]

Not sure if this is what you're looking for, but building an exploded key with the text forward and reversed, then using that for the match field should give you clairvoyance in both directions.

It is exacty what I'm after - but couldn't you paste the calc'def since we're in the application state of becomming FSA member ...and developement have until now gone more in the direction of serving via IWP, so buying a 7Dev just be fore getting one via the membership is...

--sd

[LaRetta]

I may need to explain ... JT gave me a solution for vs. 6. But I want a Custom Function of it (or just be sure to take full advantage of the enhancements in 7).

I am posting his solution (incorporated into my demo) for those that are interested. Even in vs. 6, it's extremely powerful.

Why do I want to match in the middle of a word? Because staff doesn't always have the exact spelling. I want them to enter what they know FOR SURE, and see all results, ie, is it "Catheryn" or "Katherine"? I want them to type "ather" and see both in a portal key match. There are many more such examples. I was originally using copy/paste and performing a find to isolate the IDs in a multiline.

I hope you don't mind my posting it, JT.

QueuePatternKey.zip

[Ender]

Soren, I used the following custom functions:

Reverse() from http://www.briandunning.com/filemaker-custom-functions/detail.php?fn_id=177

ExplodedKey() from http://clevelandconsulting.com/support/viewtopic.php?t=49

ExplodedString() from http://www.briandunning.com/filemaker-custom-functions/detail.php?fn_id=47

These all use recursion, but you could figure out a non-recursive algorithm like what LaRetta has posted, if you can't install the custom functions.

[comment]

I am sorry, but I still don't get it. I am talking about the purpose, not the technique.

It would be easy to reverse the clairvoyance's direction. The question, IMHO, is where is the boundary between maximum convenience and too many false positives.

For example, Ender's file will NOT match "ore" with "Soren" (but it WILL match it with "Nero"). JT's file, OTOH, will match down to a single letter, then sort by relevance. But relevance has to be an unstored calc, so again there are pros and cons.

Could we first define the desired product, then see how to get it?

--- EDIT ---

Why don't you write out the expected key for "Soren Dyhr", for example?

[Ender]

Good catch comment. I have changed my algorithm to build a multi-key with each permutation of the string on the match side. The Reverse() function is no longer used.

My new algorithm uses a new custom function ExplodedPermutations(), and has the ExplodedString() function call this new function instead of ExplodedKey().

ExplodedPermutations(text) =

//ExplodedPermutations(text)

//by Mike Hackett

//for making a multi-key with all groupings of consecutive letters

Let(

right = Right(text;Length(text)-1);

ExplodedKey(text) &

AnyMatch2.fp7.zip

[Søren Dyhr]

Well I saw the same flaw as Comment - and would now say that JT's idea comes a little closer... however doesn't it exploit the new repeating features as well as the Evaluate( function. Which might compact the code slightly ...but it does still bother me that the way we developers that roams here belongs to the later cathegory of (at least me!):

If you find that you're spending almost all your time on theory, start turning some attention to practical things; it will improve your theories. If you find that you're spending almost all your time on practice, start turning some attention to theoretical things; it will improve your practice.

...quoted from: http://artenumerica.com/inspiration/knuth.en.html

Having a stong feeling that something is staring right in the face ...but due to my ignorance...

--sd

[comment]

And the answer to my question?

[Søren Dyhr]

And the answer to my question?

Searches like this one:

*ren*

Giving a portal full of strings havin the sequence "ren" somewhere in it. The solution I am maintaining has such a filtering, but I would like to approach the matter or algorithm as clever as posible - not utterly satisfied with as it is at present - a list as long as an arm containing middelwords( to your heart desires ...if it just appeared to be much simpler to write via a Fibonacci'ish sequence or such.

--sd

[comment]

Hm, I am not sure how Fibonacci fits in here. Could we for a moment forget everything we know about Filemaker and computing in general, and look at it purely from the user's point of view?

What is your expectation as a user? Surely it is NOT to have "a portal full of strings havin the sequence "ren" somewhere in it". I could take it that you expect to type 3 letters and find anything that contains this sequence. Is that correct?

[Søren Dyhr]

I could take it that you expect to type 3 letters and find anything that contains this sequence. Is that correct?

Yes, your point in shorter sequences becomming silly is taken - lets start with at least 3 letters, not a tough request upon the user to come up with. How would you approach this matter??

I might even get away with demanding "always 3" in the sequence... letting <space> be allowed as well.

--sd

[comment]

"always 3" in the sequence... letting <space> be allowed as well

That's actually making it much easier:

Case (

Length ( Middle ( Extend ( theText ) ; Get ( CalculationRepetitionNumber ) ; 3 ) ) = 3 ;

Middle ( Extend ( theText ) ; Get ( CalculationRepetitionNumber ) ; 3 )

)

My difficulty is that I have never used clairvoyance, had no need for it, and therefore I really don't know what would be considered good.

[Søren Dyhr]

My difficulty is that I have never used clairvoyance, had no need for it

Neither have I - I'm hired to trim an already working solution, I would have used dynamic valuelists ...if I were to deside a user interface principle.

Toying a little with your idea made me think of ordinary Type Aheads... why not stack one of each lenght - it seems to work thanks for helping me rethinking!

--sd

[comment]

Meanwhile I've been playing with the idea of wildcards, something like:

*or*n

S*ore*

So*en

*or*n

Perhaps, with a clever enough pattern, this could do partial matches AND catch typos. But it seems to be more of a semantic problem, rather than algorithmic.

[Ender]

why not stack one of each lenght

Sounds kind of like a multi-key.

Meanwhile I've been playing with the idea of wildcards, something like:

*or*n

S*ore*

So*en

*or*n

Perhaps, with a clever enough pattern, this could do partial matches AND catch typos.

I think this would require very large multi-keys. If there are n letters in the string, and m wildcards allowed, you have on the order of n^2 * m lines. The key could be trimmed by skipping the lines that are 3 characters or less, but it could still be a pretty big key.

[-Queue-]

I hope you don't mind my posting it, JT.

Not at all. Now I have my own copy. The original is on my old comp somewhere and I would be lucky if that thing even booted properly.

[Søren Dyhr]

Sounds kind of like a multi-key.

Well it's a bit of both, performing pretty well except for abbreviations of surnames, a thing JT's does pretty well...

Case (

Length ( Middle ( Extend ( theText ) ; Get ( CalculationRepetitionNumber ) ; 1 ) ) = 1 ;

Middle ( Extend ( theText ) ; Get ( CalculationRepetitionNumber ) ; 1 )

) &

[comment]

If there are n letters in the string, and m wildcards allowed, you have on the order of n^2 * m lines.

I don't know how you figure that. Let's see: 3 letters in the string, and 1 wildcard allowed, you say 9 lines. I see only 3 (4 with the full string):

*bc

a*c

ab*

abc

But that is beside the point - my point, at least. It never occured to me to cover all possible variations. I said perhaps a clever pattern could be devised. This was "inspired" by Soren's reference to the Substitute() pattern of decimating characters runs.

Maybe the required pattern will require a mile-long key, or will not be practical for another reason - but until we know WHAT it is that we would like to produce, I see no reason to worry about HOW to produce it.

[Ender]

True, we've all made some assumptions and guesses about what might be the most useful, but we haven't come to a consensus or understood what Soren really wants.

In my algorithm, the assumptions I made are:

1. Searches for partial words are allowed, like "ore" matching "Soren Dyhr".

2. Searches for multiple partial words are not allowed; "ren Dy" will not match "Soren Dyhr". This is to improve efficiency because this type of search seemed unlikely.

3. Searches of three or fewer letters are allowed, though I think cutting out one and two letter lines is a good idea.

comment, I think your idea of using wildcards is useful, I'm just not sure how to implement it efficiently. I figured the cost of adding wildcards based on needing a wildcard in each position in the multi-key, something like:

abcd

*bcd

*bc

*b

a*cd

a*c

a*

a

ab*d

ab*

ab

abc*

bcd

*cd

*c

b*d

b*

b

bc*

cd

*d

d

I guess I made an assumption that the wildcard match would be in addition to the clairvoyance. Perhaps this is not what you had in mind.

Soren, your repeating calc is very clever, but I don't think its very efficient for long strings. For a twenty-character string (after adding to your calc,) you'd have some 400 lines. This is what I was trying to avoid by doing separate multi-keys for each word (see assumption 2 above.) Was my assumption wrong?

Anyway, I do find this interesting, so I hope we can think this through a bit longer.

[comment]

I guess I made an assumption that the wildcard match would be in addition to the clairvoyance. Perhaps this is not what you had in mind.

No - but at least I got an explanation of your math.

I think your idea of using wildcards is useful, I'm just not sure how to implement it efficiently.

Me neither - I am just playing with the idea. And it's not about implementation, although I see I am having a hard time getting this point across. Let's take your algorithm, for example: you've stated what it needs to do (what you call 'assumptions', but in fact those are 'specifications'), then set out to implement exactly that.

Now, that's fine, but I think Soren meant to question the specifications. And he sort of carried me away with this. For example, Laretta mentioned "Catheryn" or "Katherine". And I could add "the" or "teh". Or what's that guy's name, "Syren" or something.

OTOH, if one gets too carried away, one will eventually match everything, so that's useless. That's what I meant when I said the question is where is the boundary between maximum convenience and too many false positives. And there can't be a one-size-fits-all solution either.

[Søren Dyhr]

True, we've all made some assumptions and guesses about what might be the most useful, but we haven't come to a consensus or understood what Soren really wants.

What I want is to understand the reasoning behind an implentation of clairvoyance in a solution I'm asked to debug, and if I in this process stumbels over a more elegant solution ...or learn from others why they hessitate in using such beasts, is pretty much already achieved - especially when Michael (comment) writes:

but I think Soren meant to question the specifications. And he sort of carried me away with this.

...and he continues:

where is the boundary between maximum convenience and too many false positives. And there can't be a one-size-fits-all solution either.

Indeed, this is exactly the measure needed here - Where the solution I'm debugging assuming a behaviour from the users which doesn't have to be particular true. One thing I've noticed is that the developer apparently not were aware of techniques for singleing out freestored (not booked) in choise of resources ...and have introduced this goofy measure to prevent too long loopings with the task to create new join records in a many2many. His problem was apparently that the lazy booker just took all resources and batch booked them hoping to have enough not conflicting ...at the end of the loopings - to satisfy the customer in a hurry.

Beyond that do I actually think that Clairvoyance is a slight departure from good mac interface design - not that I can point at a certain spot that violates HUI rules issued by Apple ...but more the feeling that eagerness to get as many tasks accomplished in every idle moment are more Windows/Linux.

What I'll do if the Clairvoyance are going to stay in the solution at the same time as the making a portal of freestored in the timespan the resouces are needed, would be something along the line of the stacking in the repeater ...with an investigation of the likely number of char's needed for the keying ...the number of resource ID's will perhaps only be 200 at all.

--sd

[comment]

why they hessitate in using such beasts

Because it is not really "type ahead". It's "type-click outside the field-ahead". I don't know if it violates Apple's I/F rules, but it does violate mine. I try to stay away from such devices, because I find that users don't understand it and, even worse, perceive it as poor implementation of the real thing.

[Søren Dyhr]

Indeed and this is more like the real thing:

http://www.nightwing.com.au/FileMaker/Clairvoyance/

...unfortunately is it in this case a IWP solution, so it won't work here!!

--sd