Re: [Vtd-xml-users] Random Access Proposal (take 2)

[Jimmy Z. <cra...@co...>]

Rodrigo, I just checked in a quick update into CVS

Regarding some of prior comments, my questions are

1. When would a user call getNavigator() any way? I kinda had
a tough time coming up the scenario...

2. Regarding equals(), I think that the current bookMark implementation
should be fine in that the only time two bookMark instances are equal
is when they contains node position of the same VTDNav instance, and
the node indices are equal...

3.  I am still not sure about hashCode, what is the purpose of the spread?
For the current implementation, there will never be colision for the 
bookmarks
corresponding to the same document (the node index is ideal)...

Let me know your thoughts..
Regards,
jimmy


----- Original Message ----- 
From: "Rodrigo Cunha" <rn...@gm...>
To: "Jimmy Zhang" <cra...@co...>
Cc: "Mark Swanson" <ma...@Sc...>; 
<vtd...@li...>
Sent: Thursday, March 15, 2007 8:46 AM
Subject: Re: [Vtd-xml-users] Random Access Proposal (take 2)


> Jimmy, the API itself seems quite OK to me.
>
> I had made the decision not to keep a pointer to VN inside the context but 
> for extra safety this is both highly recomended and adds little extra fat, 
> so let's keep it your way. Ah... since you keep a pointer do VTDNav you 
> should add a method "getNavigator". This will spare some parameter passing 
> to functions that might use a Bookmark. It's functionally irrelevant but 
> convenient and might even add some efficiency.
>
> Now the inner workings:
>
> The implementation of both equals and hashcode could be different. Note 
> that in typical usage inside data structures my complex methods 
> assymptotically get as fast as yours, since they end up comparing 
> pre-calculated hashCodes, considering there are probably no collisions.
>
> Also, for maximum efficiency hashCode should be a spread function. Using 
> index numbers does not typically spread the hashCode amonsgst the 
> available 2^32 values, still this is a minor observation, don't bother 
> with that :-) And we don't have collisions, so it's quite ok.
>
> If Mark also agrees I think this new class is ready for prime time.
>
> Jimmy Zhang wrote:
>> hmm...interesting... "plup" sounds like a tennis racket hitting the 
>> ground...
>> it may work :-)
>>
>> Please take a look the file below and let me know what you think of it 
>> ...
>>
>> http://vtd-xml.cvs.sourceforge.net/*checkout*/vtd-xml/ximple-dev/com/ximpleware/BookMark.java
>>
>>
>> ----- Original Message ----- From: "Rodrigo Cunha" <rn...@gm...>
>> To: "Jimmy Zhang" <cra...@co...>
>> Cc: "Mark Swanson" <ma...@Sc...>; 
>> <vtd...@li...>
>> Sent: Wednesday, March 14, 2007 4:19 AM
>> Subject: Re: [Vtd-xml-users] Random Access Proposal (take 2)
>>
>>
>>> Yes, that would be a nice add :-)
>>>
>>> Wouldn't solve the exception handling or true random access issues 
>>> tought, but would be a nice addon.
>>>
>>> I propose "plup()" hehe
>>>
>>> Jimmy Zhang wrote:
>>>> Rodrigo, How about add a method (tentatively called set()) that 
>>>> basically
>>>> does pop() and push() in one shot , so your
>>>> example
>>>>
>>>> push();
>>>> // do something
>>>> pop();
>>>> push();
>>>> // do something
>>>> pop();
>>>> push();
>>>> // do something
>>>> pop();
>>>> push();
>>>> // do something
>>>> pop();
>>>>
>>>> becomes
>>>>
>>>> push();
>>>> // do something
>>>> set();
>>>> // do something
>>>> set();
>>>> // do something
>>>> set();
>>>> // do something
>>>> pop();
>>>>
>>>>
>>>> ----- Original Message ----- From: "Rodrigo Cunha" <rn...@gm...>
>>>> To: "Mark Swanson" <ma...@Sc...>; "Jimmy Zhang" 
>>>> <cra...@co...>
>>>> Cc: <vtd...@li...>
>>>> Sent: Tuesday, March 06, 2007 9:24 AM
>>>> Subject: Re: [Vtd-xml-users] Random Access Proposal (take 2)
>>>>
>>>>
>>>>> Hum, thanks for the hint also Mark. I normally use java.util 
>>>>> collections, but i'll give fastutils a look, since they might be 
>>>>> better for some of my problems.
>>>>>
>>>>> Jimmy, a context can be imported/exported as an array of integers, 
>>>>> this being a bit raw perhaps... and leaving the programmer with the 
>>>>> job of storing that array. I just created SimpleContext as a way of 
>>>>> abstracting that implementation detail, but since you like 
>>>>> performance, perhaps you could leave that raw. I still prefer the 
>>>>> abstracted version... besides, the internal representation might 
>>>>> change and the abstracted version would still work.
>>>>>
>>>>> So, yes, go ahead with my API even if you decide to change it later.
>>>>>
>>>>> Just as a little silly footnote I found my API is also useful in cases 
>>>>> where you have:
>>>>>
>>>>> push();
>>>>> // do something
>>>>> pop();
>>>>> push();
>>>>> // do something
>>>>> pop();
>>>>> push();
>>>>> // do something
>>>>> pop();
>>>>> push();
>>>>> // do something
>>>>> pop();
>>>>>
>>>>> Can be abreviated to:
>>>>>
>>>>> setCtxFromNav(ctx);
>>>>> // do something
>>>>> setNavFromCtx(ctx);
>>>>> // do something
>>>>> setNavFromCtx(ctx);
>>>>> // do something
>>>>> setNavFromCtx(ctx);
>>>>> // do something
>>>>> setNavFromCtx(ctx);
>>>>>
>>>>> This is both faster and more readable.
>>>>>
>>>>> It's also useful for things like:
>>>>>
>>>>> xpto = getComplexToFindTransmissionPath(VTDNav n, String s); // might 
>>>>> even use caching!
>>>>> push();
>>>>> nav.setNavFromCtx(xpto);
>>>>> // Do something
>>>>> pop();
>>>>>
>>>>> and also for exception handling:
>>>>>
>>>>> {
>>>>> setCtxFromNav(xpto);
>>>>> // do something complex and error-prone,
>>>>> // so I won't use the stack, but a few locally declared contexts 
>>>>> instead
>>>>> // oops! crash! go to handler!
>>>>> finally {
>>>>>    setNavFromCtx(xpto)
>>>>>    // we are now clean
>>>>> }
>>>>>
>>>>> So, it made using VTD much more enjoyable to me, even in rather 
>>>>> trivial situations.
>>>>>
>>>>> Mark Swanson wrote:
>>>>>> Jimmy Zhang wrote:
>>>>>>>
>>>>>>>> Just a FYI: I have cases where the key is an Integer, and cases 
>>>>>>>> where
>>>>>>>> it's a string.
>>>>>>>
>>>>>>> By Integer is it a java class? or just a primitive data type? Maybe 
>>>>>>> I can
>>>>>>> modify Rodrigo's class and put it into CVS so you guys can use 
>>>>>>> immediately...
>>>>>>> however, I can't guarantee that it will be included in the next 
>>>>>>> release...
>>>>>>> Would that work?
>>>>>>
>>>>>> Oh, I always use native ints and fastutil wherever possible.
>>>>>>
>>>>>> Just a thought: I use autojar on my code to build a tiny fastutil jar 
>>>>>> that just has the code I need. You could do the same thing to get 
>>>>>> excellent native collections instead of writing your own. I see you 
>>>>>> already wrote your own, but in case you need more.. Fastutil uses the 
>>>>>> LGPL.
>>>>>>
>>>>>> Cheers.
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>
>