Phonological search with features

[kchall]

When doing a phonological search based on features, PCT currently returns all the individual segments that have the given feature specifications, but no total summary count of the type / token frequency of the given features.

[mmcauliffe]

So I was thinking about this, and I have a few questions. So the way it works right now is that frame on the far left is used for specifying segments, so the features (as you add more) specify smaller sets of segments. So if the summary gave a featural count, then it'd just be one line. So then, the benefit for showing it for the selected features would only be for making multiple searches, correct? So it's okay in that case to have a single line per search done in the summary?

[mmcauliffe]

So this should be implemented, as I understand it, on the improve-search branch. Can you check it out and make sure this is what you're envisioning?

[kchall]

Hmm, I don't actually see anything different about the search results when I'm trying it out.

But, here's an example of what I had in mind:

-Example corpus
-Search for [-back] segments, in the environment [ʃ_]
-The summary results currently show two lines; one for the one word containing [e] in this environment and one for the three words containing [i] in this environment.
-Individual results currently show four lines, one for each of the four words.

There's no result that tells me how many total words there are that contain [-back] segments in this environment. I think what I would expect is that the summary results would show a single line that has the feature(s), environment, type, and token frequency listed (where the type frequency would be 4 in this case, summing the totals for each included segment), and then the individual results would show, as they currently do, all individual words with the segments that happen to fit the featural description. It would still be useful in that result box to list the features that were being matched, though, in the case of multiple searches -- which leads me to another issue:

I'm not totally sure what you originally meant by the benefit being there only for multiple searches. But in trying out multiple searches, I discovered a potential flaw! Namely:

-I first did the search described above, for [-back] segments after [ʃ].
-I re-opened the dialogue box and did a new search for [+high] segments after [ʃ], adding the results to the old dialogue box.

The results window now tells me that there are SIX words that fit my search query that contain [i] -- presumably, because there are three [i]s after [ʃ], so there are three [-back] segments in this environment and three [+high] segments. And indeed, the individual results list the same words (e.g., ) twice. (Here's where it would be helfpul for PCT to list the features it thought were relevant for that results, i.e., listing one of them as [i] being [-back] and the other as [i] being [+high].)

More generally, though, I think this kind of automatic doubling could be very confusing and potentially problematic. Would it be possible just for PCT to throw a warning message when such a second search is done, something like "Warning! This new search overlaps with the results of a previous search, and the results will show you the combined totals for both searches, which may result in over-counting."

[kchall]

@jsmackie

[kchall]

Some related issues from AO:

"When doing a phonological search, if you have the results and then click "reopen function dialog" and then try to do another phonological search using the "start new results table" option, nothing happens. You have to either add to the previous results table or close the phonological search and re-open it and start again. That's kind of frustrating if, for instance, you want to search for the same set of segments in the same environments but on different tiers."

"Related to that, it would be great if the results of the search function could indicate which tier the results are on. (This might also help with the previous problem, because if adding to the previous results table created a separate row for the same segment/environment pair when it's a different tier, instead of adding to the previous total for that pair, then it wouldn't be a problem.)"