[jsword-devel] Bookset
Martin Denham
mjdenham at gmail.com
Thu Jan 30 02:20:48 MST 2014
I see now, so 'map verse 0 together with verse 1 when found as part of a
range' is the way to go.
Martin
On 29 January 2014 23:20, Chris Burrell <chris at burrell.me.uk> wrote:
> 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
>>
>>
> _______________________________________________
> 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/20140130/f79982ca/attachment-0001.html>
More information about the jsword-devel
mailing list