[jsword-devel] Bookset
Chris Burrell
chris at burrell.me.uk
Wed Jan 29 16:20:40 MST 2014
At the moment we ignore verse 0 when mapping ranges defined in properties
files. As result you may have verse 0 of job 41 in leningrad mapped to
verse 0 of job 41 in kjv. That would be incorrect. Since verse 0 should
map roughly to verse 8 in kjv
Chris
On 29 Jan 2014 21:45, "Martin Denham" <mjdenham at gmail.com> wrote:
> If the verse 0 is actually unmapped then the current logic would map it to
> verse 0 in the desired v11n.
>
> If mapping a verse then the current logic is:
> If verse is mapped then use mapping
> If verse is not mapped then use current verse (as now) e.g.
> KJV:Gen.1.1->Ger:Gen.1.1
> All this is as now, but the logic continues to work even if the verse to
> be mapped is verse 0. The only logic that needs to change is the deletion
> of Verse 0.
>
> If verse 0 is to be mapped but there is no mapping then it would seem more
> correct to return verse 0 in the desired v11n rather than verses 0 & 1.
> Although if you want to return verse 0 & 1 then AB would cope but it seems
> wrong.
>
> Martin
>
>
> On 29 January 2014 21:32, Chris Burrell <chris at burrell.me.uk> wrote:
>
>> Hi
>>
>> That's correct, but what happens if the verse 0 is actually unmapped?
>> i.e. a mapping has not been specified in the file, or it was ignored as
>> part of mapping a range? At the time of the map() / unmap() method, it's
>> too late to distinguish between the two cases.
>>
>> In the first instance, we should assume same ref, but in the second it
>> may be in the middle of another range. So the fix suggested before may work
>> (i.e. map verse 0 together with verse 1 when found as part of a range.).
>>
>> Chris
>>
>>
>>
>> On 29 January 2014 20:59, Martin Denham <mjdenham at gmail.com> wrote:
>>
>>> 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
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> 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/00ed7a0d/attachment-0001.html>
More information about the jsword-devel
mailing list