<div dir="ltr">Strong's numbers are padded by 0, which is why they currently sort properly.<br><br>Such a sort order sounds a good idea (though perhaps not for the developers ;). <br>Modules produced in such a way wouldn't be compatible with Sword <= 1.5.11, though.<br>
<br>I still suspect that sorting isn't quite as easy as specifying a simple sort order such as you suggested. <br>Once diacritics enter into it (especially non-composed diacritics), things could get a little more difficult.<br>
Perhaps allowing the delimiter separated variables to be longer than 1 character long might help.<br><br>This still won't catch everything, but it would be a good thing to have - I think I've seen english dictionaries which put "St. Something" entries at the start of S...<br>
<br>As for the example 'tis, you can't catch everything. This is when you want to do a search on the keys of the dictionary.<br><br clear="all">God Bless,<br>Ben<br>-------------------------------------------------------------------------------------------<br>
The Lord is not slow to fulfill his promise as some count slowness,<br>but is patient toward you, not wishing that any should perish,<br>but that all should reach repentance.<br>2 Peter 3:9 (ESV)<br>
<br><br><div class="gmail_quote">2008/9/18 Greg Hellings <span dir="ltr"><<a href="mailto:greg.hellings@gmail.com">greg.hellings@gmail.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Wed, Sep 17, 2008 at 10:38 PM, Daniel Owens <<a href="mailto:dhowens@pmbx.net">dhowens@pmbx.net</a>> wrote:<br>
><br>
><br>
> Greg Hellings wrote:<br>
><br>
> On Wed, Sep 17, 2008 at 9:56 PM, Daniel Owens <<a href="mailto:dhowens@pmbx.net">dhowens@pmbx.net</a>> wrote:<br>
><br>
><br>
> Ben,<br>
><br>
> Thanks for the explanation. It seems to me that setting up dictionaries to<br>
> use key retrieval from an uncompressed file with one key per line (ordered<br>
> as the module creator orders it) makes the most sense to me. If that helps<br>
> increase efficiency and preserves the order of dictionary entries, then that<br>
> is what we want.<br>
><br>
><br>
> Would it also be possible to put a space-delimited (or anything else<br>
> delimited) list of the order that characters ought to be arranged in<br>
> for a given dictionary? Then the module creator could put them in<br>
> whatever is desired in the import file, and the ordering can be based<br>
> off of the configuration file. Sorting would be as simple as<br>
> replacing the characters in each entry with an integer and sorting the<br>
> resulting vectors. In the absence of a sort-field, then the module<br>
> import file's order could default (or the current behavior, whichever<br>
> is deemed better)?<br>
><br>
><br>
> --Greg<br>
><br>
><br>
><br>
> What if one of the TEI elements were an integer (much like Strong's)? The<br>
> dictionary could be sorted by that integer but entries would not display the<br>
> integer but rather the actual word entry.<br>
<br>
</div>I would suppose, in that case, the sorting could be left in the<br>
default mode of sorting based on the document's type. Alternatively<br>
two config entries could be devised.<br>
Sorting=None|Default|Config<br>
SortOrder=a b c d e...<br>
<br>
The Sorting=None would be sorting left in the order of the import<br>
file, Default would be the current (and default) behavior and Config<br>
would indicate to follow the sorting order listed in SortOrder, which<br>
could be completely arbitrary, based on the module creator's<br>
preferences. For a language or a listing which used numerals, like<br>
Strongs, they would not be perturbed by either the original scheme or<br>
this expanded suggestion. Since the characters of the Strongs entries<br>
are distinct from integers, and the mapping would take characters into<br>
integers for the sorting process, then back into their original<br>
characters, no violence would be done to the Strongs numbers<br>
themselves. If there was a mixture of letters and numbers, it still<br>
wouldn't be a problem, and the module creator could include the<br>
integers wherever they wanted in the SortOrder listing.<br>
<font color="#888888"><br>
--Greg<br>
</font><div><div></div><div class="Wj3C7c"><br>
><br>
> Daniel<br>
><br>
> I will agree that the sorted order is not as important in BPBible because of<br>
> the lookup feature, but that breaks down when you need to browse further<br>
> within a range of entries. Furthermore, the example of "'tis" suggests that,<br>
> even in English, code pointing disturbs the natural order of the dictionary,<br>
> making it harder to browse for the right entry. Unless you type in the<br>
> apostrophe, you won't find "'tis" because it will not be near "t" but be at<br>
> the top of the dictionary, which is very far away. In BibleDesktop, which<br>
> doesn't yet have the lookup feature yet, you have to browse for any<br>
> dictionary entry (except Strongs, where the key is a number and therefore in<br>
> printed order!), so the ordering really does matter. Also, frankly, a<br>
> dictionary out of alphabetical order just looks silly. In Vietnamese it's<br>
> chaotic when dictionaries are ordered by code point. Who ever heard of a<br>
> dictionary where "d" comes after "z"? That's what happens in Vietnamese.<br>
><br>
> Daniel<br>
><br>
> Ben Morgan wrote:<br>
><br>
> Hi Daniel,<br>
><br>
> Code points are not the only way to sort it.<br>
> However, there does need to be a comparison function defined, which will<br>
> compare two words and give which is bigger.<br>
> This needs to be used consistently, from module creation to frontend. There<br>
> could be a library of defined comparators provided by SWORD - but you would<br>
> need one for each sort order you wanted (which approaches one per language).<br>
><br>
> Personally, I don't find that sorted order is particularly important in<br>
> dictionaries - I would type in a word, and then hope that if it is a<br>
> different form of the word it would be relatively close. Some frontends may<br>
> not give the ability to type in words, though.<br>
><br>
> But I haven't used dictionaries in other languages, so it may be different<br>
> for them - especially once diacritics are involved.<br>
><br>
> The reasons why dictionaries are different from bibles are:<br>
> 1) Bibles have a known structure, which is hardcoded in the key type (this<br>
> is going to be able to change soon, for alternate versification, though -<br>
> probably leading to less efficient modules)<br>
> 2) Dictionaries can be much, much larger - Websters is a 14Mb download<br>
> compressed, as compared to the WEB's ~1.5Mb<br>
><br>
> That's not to say the dictionaries can't be done more efficiently than they<br>
> are currently. Looking at the code, they could be quicker for the (common?)<br>
> case of incrementing a module. Currently they do a binary search for every<br>
> increment.<br>
> Further, they could probably be optimized for key retrieval - which is the<br>
> really important thing here. (For example by storing the keys separately,<br>
> uncompressed, 1 key per line)<br>
><br>
> God Bless,<br>
> Ben<br>
> -------------------------------------------------------------------------------------------<br>
> The Lord is not slow to fulfill his promise as some count slowness,<br>
> but is patient toward you, not wishing that any should perish,<br>
> but that all should reach repentance.<br>
> 2 Peter 3:9 (ESV)<br>
><br>
><br>
> On Thu, Sep 18, 2008 at 11:21 AM, Daniel Owens <<a href="mailto:dhowens@pmbx.net">dhowens@pmbx.net</a>> wrote:<br>
><br>
><br>
><br>
> Is code point order the ONLY way to sort dictionary entries? Surely there<br>
> is a solution which would retain the printed or intended order of dictionary<br>
> entries without giving up lots of efficiency. If not, I think users would<br>
> find a correctly ordered but slower dictionary to one which is fast but<br>
> jumbled up.<br>
><br>
> At the very least, even if dictionaries aren't sorted by the printed order,<br>
> they should AT LEAST be in alphabetical order. To me that is a<br>
> non-negotiable for a dictionary--people depend on dictionaries being in the<br>
> right order, and code point order disturbs that for some languages. Here are<br>
> a couple of ideas:<br>
> - Could a configuration file of some sort be created to define a<br>
> sorted order for a given language that would actually be in alphabetical<br>
> order?<br>
> - Could a dictionary index be created to handle large dictionaries<br>
> which allows for the retention of the correct order of entries (whether that<br>
> is the printed order or alphabetical order)?<br>
> - Bibles are not ordered by code point, and we are able to search them<br>
> fairly quickly. Do dictionaries need to be compiled in a fashion similar to<br>
> Bibles?<br>
><br>
> As it stands, dictionaries are NOT displayed in alphabetical order (at<br>
> least not Vietnamese, and apparently Farsi), which at best looks silly to<br>
> the user and at worst means you have to manually hunt around to find the<br>
> right entry, making a Genbook more efficient for the user in the end. But<br>
> then you lose the dictionary lookup feature.<br>
><br>
> Daniel<br>
><br>
> Ben Morgan wrote:<br>
><br>
> The issue with ordering as I understand it is that if it is in (some form<br>
> of) sorted order, you can use binary search to find entries.<br>
> If you want order retained, it is best to use a genbook - but it won't be as<br>
> efficient, and may not have as good UI support.<br>
> With huge english dictionaries (like Webster's, for instance) this becomes<br>
> very important.<br>
><br>
> >From BPBible's perspective, dictionary handling is done as follows:<br>
> 1. Read the index of the dictionary and divide by 4 or 6 to get the length<br>
> (depending on the driver)<br>
> 2. Set the virtual list length to the dictionary length<br>
> 3. When any item is displayed in the virtual list, it retrieves it from the<br>
> module.<br>
> 4. When the user starts typing in the text box above, it does a binary<br>
> search to find which item to display.<br>
><br>
> 4 is already quite slow enough on big dictionaries - by having it unsorted,<br>
> it would make it quite a lot slower, I imagine.<br>
> All the keys from the module would have to be read in, which takes a while.<br>
><br>
> God Bless,<br>
> Ben<br>
> ------------------------------------------------------------------------------------------<br>
> -<br>
> The Lord is not slow to fulfill his promise as some count slowness,<br>
> but is patient toward you, not wishing that any should perish,<br>
> but that all should reach repentance.<br>
> 2 Peter 3:9 (ESV)<br>
><br>
><br>
> On Thu, Sep 18, 2008 at 12:43 AM, Daniel Owens <<a href="mailto:dhowens@pmbx.net">dhowens@pmbx.net</a>><br>
> <<a href="mailto:dhowens@pmbx.net">dhowens@pmbx.net</a>> wrote:<br>
><br>
><br>
><br>
> mention that byte ordering does some strange things to Vietnamese<br>
> dictionaries. The Vietnamese script is a Latin script, but because it uses<br>
> some odd characters code point ordering results in illogical and<br>
> non-alphabetical entry ordering. For example, the "d" with a line through it<br>
> (ð) gets relegated to near the end of the dictionary instead of after the<br>
> regular "d" or anything with an apostrophe at the beginning of a word or<br>
> phrase gets moved to the top of the list regardless of the first letter<br>
> (such as 'tis). I am supportive of the IIRC general opinion. Let the module<br>
> creator worry about the ordering. Otherwise you get some very strange<br>
> dictionary behavior.<br>
><br>
><br>
><br>
> ------------------------------<br>
><br>
> _______________________________________________<br>
> sword-devel mailing list:<br>
> sword-devel@crosswire.orghttp://<a href="http://www.crosswire.org/mailman/listinfo/sword-devel" target="_blank">www.crosswire.org/mailman/listinfo/sword-devel</a><br>
> Instructions to unsubscribe/change your settings at above page<br>
><br>
><br>
> --<br>
> PMBX license 1502<br>
><br>
><br>
> _______________________________________________<br>
> sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a><br>
> <a href="http://www.crosswire.org/mailman/listinfo/sword-devel" target="_blank">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>
> Instructions to unsubscribe/change your settings at above page<br>
><br>
><br>
><br>
> ________________________________<br>
> _______________________________________________<br>
> sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a><br>
> <a href="http://www.crosswire.org/mailman/listinfo/sword-devel" target="_blank">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>
> Instructions to unsubscribe/change your settings at above page<br>
><br>
> --<br>
> PMBX license 1502<br>
><br>
> _______________________________________________<br>
> sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a><br>
> <a href="http://www.crosswire.org/mailman/listinfo/sword-devel" target="_blank">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>
> Instructions to unsubscribe/change your settings at above page<br>
><br>
><br>
><br>
> _______________________________________________<br>
> sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a><br>
> <a href="http://www.crosswire.org/mailman/listinfo/sword-devel" target="_blank">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>
> Instructions to unsubscribe/change your settings at above page<br>
><br>
><br>
><br>
> --<br>
> PMBX license 1502<br>
><br>
> _______________________________________________<br>
> sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a><br>
> <a href="http://www.crosswire.org/mailman/listinfo/sword-devel" target="_blank">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>
> Instructions to unsubscribe/change your settings at above page<br>
><br>
_______________________________________________<br>
sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a><br>
<a href="http://www.crosswire.org/mailman/listinfo/sword-devel" target="_blank">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>
Instructions to unsubscribe/change your settings at above page<br>
</div></div></blockquote></div><br></div>