dighl / spreadsheet

Various functions for interaction between LingPy and STARLING
GNU General Public License v2.0
0 stars 0 forks source link

Starling negative numbers other than -1 are not converted properly #3

Closed Alexei-Kassian closed 10 years ago

Alexei-Kassian commented 10 years ago

Here is 'lez_indep_develop.xlsx', converted into 'lez_indep_develop.qlc': https://yadi.sk/d/djzv-9SibmcF7

Please note: EARTH Koshan Aghul rug -5

This is a loanword which should be excluded from the analysis. Despite the fact that the most commonly used Starling negative number is "-1", actually any negative number points to loans or lacunae.

LinguList commented 10 years ago

As far as I see, the analysis does it's job here:

472 Ixrek_Rutul earth   22  earth   neqʼʷ {некьв}    некьв  neqʼʷ 117 ?
473 Luchek_Rutul    earth   22  earth   naqʼʷ     naqʼʷ     naqʼʷ 117 ?
474 Koshan_Aghul    earth   22  earth   rug     rug     rug -594    ?
475 Keren_Aghul earth   22  earth   neqʼʷ     neqʼʷ     neqʼʷ 117 ?
476 Gequn_Aghul earth   22  earth   rug     rug     rug -595    ?
477 Fite_Aghul  earth   22  earth   rug     rug     rug -596    ?

The algorithm checks for less equal zero, so it should cover cases of -5 and the like and in our case, it assigns -595 (see above).

BTW: It would be nicer than using the -1 to use just the same negative ID in STARLING and GLD if a word is borrowed from a given cognate set. In this case, where the borrowing apparently was from one language with COGID == 117, coding as -117 would be more informative (of course, it would be -3 in this case, based on line 29 in the XLSX file with meaning-specific COGIDs, but in LingPy they could be automatically converted to -117 etc.).

Alexei-Kassian commented 10 years ago

Yes, everything is ok, it was my inattention. Sorry.