Closed kchall closed 2 years ago
PCT doesn't seem to pay attention to the 'tier' specification in the dialogue box at all.
PCT doesn't list the tier and the string type in the results window -- just one of them (which one? I think it's string type, but it doesn't seem to correspond to what it actually calculates).
If a word isn't in the corpus, PCT apparently treats the input .txt file as either transcription or spelling, depending on the string type specification, and then does the calculation based on that tier.
If a word is in the corpus, PCT apparently treats the input .txt file only as spelling -- it will calculate the same results regardless of whether the word's spelling and transcription actually align.
Still needs to be done
^ as you've noted above! :) A couple of additional comments:
For all words that are in your file, ND will be calculated based on the words that do exist in the corpus. Note that words in the .txt file will not be added to the corpus, nor does PCT include any of the words in the .txt file itself when calculating the neighbourhood densities of each word.”
One other note: Although all ‘a’-like symbols in the .txt file I used were IPA [ɑ], the results window presents some as [a] and some as [ɑ] in the ‘Word’ column. Is this because if there is a matching word in the corpus, it displays the word’s spelling, and if not, it displays the transcription from the text file? Seems like in this case, it would be clearer to just display all the original elements from the .txt file…
Notes to myself:
Notes to our future selves:
The reason that the string similarity and neighbourhood density algorithms are different when it comes to being able to use the spelling tier (SS can; ND can't at the moment) is as follows (thanks @stannam for the explanation!):
"We decided to remove [the spelling tier] from ND because the current algorithm does not give us correct results for 'spelling' neighbours. For example, a word spelled 'za' cannot be a spelling neighbour of 'ta' within the example corpus. When calculating ND, PCT does not compare all possible pairs in the corpus, but instead takes a shortcut. However, this does not work for the spelling tier. The issue is separate from string similarity as PCT does compare every pair for string similarity.
When ND is calculated for all words (PCT provides this option), the number of computations can exponentially increase by the number of words in the corpus. If following a naive approach, the computer needs to compare every pair of words in the corpus. However, most pairs are already expected not to be neighbours. For example, if we were to hand-calculate ND for [ta], we won't consider words like [gaga] or [enuta]. Therefore, instead of considering all cases, PCT generates a list of candidates, and loop over this list to check if a candidate exists in the corpus. For [ta], PCT refers to the inventory chart and generates candidates by changing/adding/deleting one segment in [ta]. The candidates would includes [t], [a], [da], [sa], ... but never [gaga] or [enuta].
However, this logic does not apply to spellings, because PCT doesn't have the inventory of all letters, and strangely, it referred to the phoneme inventory in previous versions (see the example of 'tusa' above)."
What should happen:
Some issues that are currently happening: