[jsword-devel] Bookset
Martin Denham
mjdenham at gmail.com
Wed Jan 29 13:59:35 MST 2014
I think you have hit on the issue: And Bible maps a single verse and allows
the context to determine the passage displayed, whereas the JSword v11n
mapping code assumes a Passage range is mapped.
I can imagine places where mapping a Passage would be better in And Bible
and may use it in the future e.g. the Verse > Compare Translation screen,
but I think that mapping the current verse works well for generally moving
around in Bibles and keeping them in sync.
There may be a simple solution to this. The external interface to the v11n
mapping has 2 public methods:
public Passage map(final Passage key, final Versification target)
public Key mapVerse(Verse v, Versification targetVersification)
So we can derive the intention of the calling code from the method that is
called - Verse or Passage.
Then if mapVerse() is called then it is clear that verse 0 should be
mapped, but if map() is called then verse 0 should not be mapped.
So the check in the code for zerosUnmapped would become zerosUnmapped &&
!mapVerseFunctionCalled.
Martin
On 29 January 2014 20:30, Chris Burrell <chris at burrell.me.uk> wrote:
> OK - I think I see our issue, and it's in the difference of approach. We
> are using the versification system in different ways. You're using a single
> verse map to work out where something is, but we're mapping a whole range.
> A verse '0' in the mapping files means pre-verse 1, and there was some
> confusion on my part when I developed it in May. I had assumed that verse 0
> in a chapter was actually the pre-verse content.
>
> So consider the following mapping in the Leningrad.properties.
>
> Ps.3.1-9=Ps.3.0-8
>
> The zero-unmapped is specified because there is no pre-verse content. That
> is, in my May-understanding of the issue, there wasn't a verse 0.
>
> The reason you are experiencing the issue is that you're converting a
> single verse. If you were to convert the whole chapter, then you'd end up
> with the correct range.
>
> In this case, allowing "verse 0" means that if we would be indicating that
> we have a pre-verse content in the Leningrad versification, which can be
> mapped to the KJV versification. In terms of the original implementation,
> it is true that Leningrad does not have pre-verse content. So it makes
> sense (to me at least) that we are getting a zero passage back.
>
> However, because verse 0 doesn't indicate a pre-verse content. I think we
> need to do something different. I don't think we can simply return the same
> verse in the different versification, as in the case of verse ranges like:
>
> Job.40.25-41.26=Job.41.1-34
>
> this would not work. Job 40.25-end has 8 verses. So the range
> Job.40.25-Job.41.26 has 34 verses. (i.e. verse 0 is left unmapped)
>
> There is specific code to ensure that these mappings are skipped, such
> that the range mentioned above works:
>
> if (isKJVMany) {
> //we detect if the keys are 1-apart from each other. If so,
> then we skip verse 0 on both sides.
> int diff = Math.abs(leftHand.getKey().getCardinality() -
> kjvVerses.getKey().getCardinality());
>
> if(diff > 1) {
> reportCardinalityError(leftHand, kjvVerses);
> }
> skipVerse0 = diff == 1;
> }
>
>
> So, I'm not sure what the solution is, but I've hopefully given all of us
> some information to think about it.
>
> One solution, is that instead of 'skipping' the verse 0 during range
> iterations, we could map it to the next verse in the range. That would be
> fairly reflective of how things really should be. We'd have to test this
> carefully in terms of the OSIS iterator.
>
> Chris
>
>
>
> Chris
>
>
>
> On 26 January 2014 00:15, Martin Denham <mjdenham at gmail.com> wrote:
>
>> This seems wrong "the purpose of the flag is to return an empty key if
>> you specifically ask for Verse 0".
>>
>> If a user is currently in Ex 20:0 in GerNeUe and switches to KJV you
>> would expect to go to KJV 20:0 but he is left at EmptyKey??
>> For comparison, if a user is currently in Ex 20:0 in ESV and switches to
>> KJV he does actually go to KJV 20:0 (Not EmptyKey - because it is the same
>> versification and the mapping returns v0 if it is the same v11n).
>>
>> The fact that RangedPassage throws an exception and Rocket does not may
>> be just a matter of the specification of Passage not being tight enough -
>> what to do with an empty passage.
>>
>> For AB verse 0 needs to be mapped.
>>
>> Martin
>>
>>
>>
>>
>>
>>
>> On 25 January 2014 23:34, Chris Burrell <chris at burrell.me.uk> wrote:
>>
>>> Thanks Martin. I'd be in favour of removing the lookup by name (but not
>>> essential for your release).
>>>
>>> Now that the build is stable, it would be a good time to label it (with
>>> the 3 extra pull requests) and you could take your cut? BTW, I label the
>>> JSword build in my repo when I release STEP.
>>>
>>> In terms of the zero unmapped option, it sounds like a bug in the
>>> Passage type if it works with some Passages and not others. Would you agree
>>> DM/Martin? They should either all fail or none of them, but not some and
>>> some not. Basically, the purpose of the flag is to return an empty key if
>>> you specifically ask for Verse 0, or if it happens to be asked for as part
>>> of a range map-request. For most of the time, you don't want that to map to
>>> any particular verse. We introduced it for some reason (can't quite
>>> remember why) but was to do with being able to map some sections to
>>> pre-verse content, as in the Psalms, whilst leaving all other verses (in
>>> other books for example) as is.
>>>
>>> Chris
>>>
>>>
>>>
>>> On 25 January 2014 23:23, Martin Denham <mjdenham at gmail.com> wrote:
>>>
>>>> And Bible tends to get lists of books and then store the relevant Book
>>>> object. I can't find anywhere that it asks for a book by name but it does
>>>> use initials sometimes.
>>>>
>>>> I recall there was a problem a few months ago in which KJVA had the
>>>> same name as KJV but different initials and use of the name as the id,
>>>> instead of the initials, caused problems - a fix had to be implemented
>>>> then. There were some similar cases of same name/different initials in the
>>>> IBT repo.
>>>>
>>>> AB should be fine/faster if JSword matches by initials first rather
>>>> than name - if that is what you are intending.
>>>>
>>>> I am hoping to settle on a stable build of JSword soon to prepare for
>>>> an AB release. When do you think would be a good time. It would be good
>>>> to get it labelled too. The only outstanding issue is with 'zerosUnmapped'
>>>> but I could just remove that line from the properties files for AB if a fix
>>>> is not easy. Currently I just catch the exception and force the verse to
>>>> the required v11n.
>>>>
>>>> Martin
>>>>
>>>> Martin
>>>>
>>>>
>>>>
>>>> On 25 January 2014 21:41, Chris Burrell <chris at burrell.me.uk> wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> I'm looking to refactor Books.installed().getBook(name) because it
>>>>> takes too long when you need to look up books multiple times (and don't
>>>>> have an easy way of caching the JSword lookup). It's particular slow when
>>>>> you have 200+ resources (our server will have). This will also be more
>>>>> prevalent in Android where method calls are quite expensive.
>>>>>
>>>>> In STEP we always have the initials of the module (the user selects by
>>>>> name/initials/STEP name in the browser, where it always gets translated to
>>>>> initials well before it hits JSword). Do any other frontends use the
>>>>> getBook(name) by name?
>>>>>
>>>>> I want to at least provide way of getting the book directly from its
>>>>> initials. As part of this, we can several things:
>>>>>
>>>>> In Books:
>>>>> - refactor the getBook() method to not search first against the name,
>>>>> then against name insensitive and then against the initials in the BMD, and
>>>>> then against the initials directly
>>>>> - If the above is not possible then at least provide a
>>>>> getBookByInitials (which would just look up the initials against their
>>>>> lower case value.
>>>>>
>>>>> In BookSet:
>>>>> - I can't work out why we're sorting the inserts in add(). They cause
>>>>> unecessary copies of the ArrayList contents in the creation of it.
>>>>> - I can't work out why it also implements Set. Especially, since
>>>>> contains would be a good candidate for using
>>>>>
>>>>>
>>>>> So there are two options really:
>>>>> - change BookSet to be based on a Map. getBooksByInitials would use
>>>>> the map directly. getBook would iterate through the contents (or key the
>>>>> contents in a separate map for faster access)
>>>>> - Add a map to BookSet to cache the lookups
>>>>>
>>>>> My preference would be to replace the BookSet implementation
>>>>> altogether. But the easy option would be to have a Map lookup. Do we use
>>>>> any of the Set<> methods? Would it make sense to replace BookSet with a
>>>>> LinkedHashMap?
>>>>>
>>>>>
>>>>> Chris
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> jsword-devel mailing list
>>>>> jsword-devel at crosswire.org
>>>>> http://www.crosswire.org/mailman/listinfo/jsword-devel
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> jsword-devel mailing list
>>>> jsword-devel at crosswire.org
>>>> http://www.crosswire.org/mailman/listinfo/jsword-devel
>>>>
>>>>
>>>
>>> _______________________________________________
>>> jsword-devel mailing list
>>> jsword-devel at crosswire.org
>>> http://www.crosswire.org/mailman/listinfo/jsword-devel
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/jsword-devel/attachments/20140129/83e46940/attachment-0001.html>
More information about the jsword-devel
mailing list