BUG: OpenText Search Result Counted Incorrectly
Run following Logos Morphology search in Bible Search:
<lemma = lbs/el/εἰμί> ANDEQUAL <lbs-morph+el ~ VPAI3S??>
OpenText: 1794 in 815 verses
NA27: 897 in 815 verses
Yet both give the same results for:
<lbs-morph+el ~ VPAI3S??> ==> 2271 / 1757
<lemma = lbs/el/εἰμί> ==> 2462 / 2098
<lemma = lbs/el/εἰμί> AND <lbs-morph+el ~ VPAI3S??> ==> 2469 / 966
Dave
===
Windows 11 & Android 13
Comments
-
Will this be fixed?
Dave
===Windows 11 & Android 13
0 -
Will this be fixed?
It's on my list to look into.
0 -
<lemma = lbs/el/εἰμί> ANDEQUAL <lbs-morph+el ~ VPAI3S??>
OpenText: 1794 in 815 verses
NA27: 897 in 815 verses
What is essentially happening here is that each visible hit is counted as a separate result. (OpenText is an interlinear resource, so it counts a second result for each morph hit; 1794 = 897 × 2.) I will file a bug on this issue.
0 -
(OpenText is an interlinear resource, so it counts a second result for each morph hit;
The only Int's to do this are NA27/UBS4 & O'text.
LGNTI + ESV/NASB95 + NKJV/AV1873 do not double-up.
But here's something else:
In NKJV & AV1873 the (Logos) morphology used for the lemma εἰμί is VP-I3S ie. <lemma = lbs/el/εἰμί> ANDEQUALS <lbs-morph+el ~ VP-I3S??>.
Also related to εἰμί; if NKJV & AV1873 are based on the TR/Byz version (and Matt 11:10 indicates this) why do they use MSS ἐστι instead of MSS ἐστιν when ἐστι is not used in any Greek TR nor Byz 2005? I'll report these as typos.
Dave
===Windows 11 & Android 13
0 -
LGNTI do not double-up
May have spoken too soon for LGNTI:-
legitimate NOTEQUAL <ln ~73> counts as 1 hit
legitimate ANDEQUAL <ln ~73> counts as 2 hits!
Dave
===Windows 11 & Android 13
0
