<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi,<br>
<br>
I've been working on a rudimentary Greek lexicon, covering both the
New Testament and the Septuagint. In the process, I was faced with
this issue. After all the discussion and work in the Hebrew
lexicon, I reevaluated my approach. What I finally decided on was
using unaccented, lower case forms of the lemmas in the lexicon.
This then automatically sorts properly. In the relatively few cases
of duplication, I append a .1, .2, etc. This represents a small
percentage of the entries in the lexicon. So the keys of the
lexicon are related to the lemmas, lexically, but the lemmas retain
the form to be displayed in listing the lexicon.<br>
<br>
Hope this helps.<br>
<br>
Peace,<br>
<br>
David<br>
<br>
<div class="moz-cite-prefix">On 1/15/2016 9:36 AM, DM Smith wrote:<br>
</div>
<blockquote
cite="mid:CFC7B52E-B846-41CC-B60C-8BD5190B09C9@crosswire.org"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div class="">
<div>
<blockquote type="cite" class="">
<div class="">On Jan 15, 2016, at 8:01 AM, Jonathan Morgan
<<a moz-do-not-send="true"
href="mailto:jonmmorgan@gmail.com" class="">jonmmorgan@gmail.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" style="font-family: Helvetica; font-size:
12px; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal; orphans:
auto; text-align: start; text-indent: 0px;
text-transform: none; white-space: normal; widows: auto;
word-spacing: 0px; -webkit-text-stroke-width: 0px;"
class="">
<div class="">
<div class="">Hi DM,<br class="">
</div>
</div>
<div class="gmail_extra"><br class="">
<div class="gmail_quote">On Fri, Jan 15, 2016 at 1:40
AM, DM Smith<span class="Apple-converted-space"> </span><span
dir="ltr" class=""><<a moz-do-not-send="true"
href="mailto:dmsmith@crosswire.org"
target="_blank" class="">dmsmith@crosswire.org</a>></span><span
class="Apple-converted-space"> </span>wrote:<br
class="">
<blockquote class="gmail_quote" style="margin: 0px
0px 0px 0.8ex; border-left-width: 1px;
border-left-style: solid; border-left-color:
rgb(204, 204, 204); padding-left: 1ex;">
<div style="word-wrap: break-word;" class="">I’ve
been trawling through the code. Seems that there
is support for Strong’s Numbers that are not
padded. If a module contains Strong’s Numbers
that are not padded, it is to use
StrongsPadding=false. (Actually any value other
than “true” will be false. TRUE is false.) This
module does not have it.
<div class=""><br class="">
</div>
<div class="">Not having StrongsPadding in a
conf is the same as StrongsPadding=true.
There’s a note in the wiki that says that
we’ll probably reverse that in the future. I
doubt it. We still have LZSS as the default
compression though no module has used it for
years (other than experimental modules).<br
class="">
<div class=""><br class="">
</div>
<div class="">I’m not sure how a Bible with a
reference to G0001 will find G1 as it
doesn’t unpad the user’s input. But at least
the dictionary should work. BTW, there’s a
missing "if (strongsPadding)” in rawLD. It
is present in zLD. I think this is a bug.
Need to verify, report and submit a patch
for it. (BTW, I don’t have write permissions
either on the main repo, but I’m not
discouraged in contributing and submitting
patches.)</div>
</div>
</div>
</blockquote>
<div class=""><br class="">
Sorry if I'm missing something, but surely keys
without padding wouldn't appear in the correct
(numeric) order in the dictionary?<br class="">
<br class="">
Jon</div>
</div>
</div>
</div>
</div>
</blockquote>
<br class="">
</div>
</div>
<div>Jon,
<div class=""><br class="">
</div>
<div class="">Right. They will be in collation order, not
numerical order. It doesn’t work as a SWORD module for that
reason and was my primary motivation for moving it to the
Experimental repository. The tei2mod program needs to add
support for Strong’s numbers as imp2ld has. It doesn’t pad the
values as it puts them into the module.</div>
<div class=""><br class="">
</div>
<div class="">The ordering problem is a more general problem.
Our collation order is good for ASCII. It is not good for
Latin-1 as the byte value for accented letters is not adjacent
to unaccented counterparts.</div>
<div class=""><br class="">
</div>
<div class="">Each language, script combination has its own
collation order. Some languages use multiple glyphs for a
single letter. This was noted earlier this month on this
mailing list.</div>
<div class=""><br class="">
</div>
<div class="">In a past job, I had to implement a sort routine
that would account for numbers occurring anywhere in a string.
What I discovered in the process of doing this was that there
is a need for an internal representation that differs from an
external representation and routines that would normalize an
external representation to an internal representation.
Basically that routine would look at a string as an
alternating sequence of numbers and non-numbers. The routine
external2internal would create a string where numbers were
zero padded to 10 digits. (It also did other things like strip
noise words from the string, normalize dotted acronyms,
normalize casing, …).<br class="">
</div>
<div class=""><br class="">
</div>
<div class="">Also in an earlier posting this month, I mentioned
that ICU has collation routines that are language and script
sensitive. The collation values that these produce are good
for byte-order sorting, but are not intended for external use.</div>
<div class=""><br class="">
</div>
<div class="">What we need is a dictionary that stores the
case-insensitive keys and that the frontend can collate as it
sees fit. That collation order would be used to sort and show
the case-insensitive keys. Basically another layer of
indirection with a mapping from external presentation to the
internal storage of the module.</div>
<div class=""><br class="">
</div>
<div class="">We’ve talked about this before. I think Troy
suggested a mechanism.</div>
<div class=""><br class="">
</div>
<div class="">I’m going to survey the lexdict modules in all the
repos in the Master list (and a few others) to see where we
stand with those modules and the StrongsPadding flag. If any
key starts with a number and isn’t zero padded, it will have
difficulty if StrongsPadding=false is not in the conf. If a
module has some that are zero padded and others that are not,
this also is a problem.</div>
<div class=""><br class="">
</div>
<div class="">DM</div>
<div class=""><br class="">
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
sword-devel mailing list: <a class="moz-txt-link-abbreviated" href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a>
<a class="moz-txt-link-freetext" href="http://www.crosswire.org/mailman/listinfo/sword-devel">http://www.crosswire.org/mailman/listinfo/sword-devel</a>
Instructions to unsubscribe/change your settings at above page</pre>
</blockquote>
<br>
<table style="border-top: 1px solid #aaabb6; margin-top: 30px;">
<tr>
<td style="width: 105px; padding-top: 15px;">
<a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient" target="_blank"><img src="https://ipmcdn.avast.com/images/logo-avast-v1.png" style="width: 90px; height:33px;"/></a>
</td>
<td style="width: 470px; padding-top: 20px; color: #41424e; font-size: 13px; font-family: Arial, Helvetica, sans-serif; line-height: 18px;">This email has been sent from a virus-free computer protected by Avast. <br /><a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient" target="_blank" style="color: #4453ea;">www.avast.com</a>
</td>
</tr>
</table>
</body>
</html>