On 8/12/07, Chris Hostetter <[EMAIL PROTECTED]> wrote:
> : I'm having the date boosting function as well. I'm using this function:
> : F = recip(rord(creationDate),1,1000,1000)^10. However, since I have around
> : 10,000 of documents added in one day, rord(createDate) returns very
> : different val
: I'm having the date boosting function as well. I'm using this function:
: F = recip(rord(creationDate),1,1000,1000)^10. However, since I have around
: 10,000 of documents added in one day, rord(createDate) returns very
: different values for the same createDate. For example, the last document
yo
We add around 10,000 docs during week days and 5,000 during weekends.
On 8/12/07, Pieter Berkel <[EMAIL PROTECTED]> wrote:
>
> Do you consistently add 10,000 documents to your index every day or does
> the
> number of new documents added per day vary?
>
>
> On 11/08/07, climbingrose <[EMAIL PROTEC
Do you consistently add 10,000 documents to your index every day or does the
number of new documents added per day vary?
On 11/08/07, climbingrose <[EMAIL PROTECTED]> wrote:
>
> I'm having the date boosting function as well. I'm using this function:
> F = recip(rord(creationDate),1,1000,1000)^10.
On 11/08/07, Chris Hostetter <[EMAIL PROTECTED]> wrote:
>
> i would agree with you there, this is where a more robust (ie:
> less efficient) DateField-ish class that supports configuration options
> to specify:
> 1) the output format
> 2) the input format(s)
> 3) the indexed format
> ...as Si
I'm having the date boosting function as well. I'm using this function:
F = recip(rord(creationDate),1,1000,1000)^10. However, since I have around
10,000 of documents added in one day, rord(createDate) returns very
different values for the same createDate. For example, the last document
added with
: Actually, just thinking about this a bit more, perhaps adding a function
: call such as parseDate() might add too much overhead to the actual query,
: perhaps it would be better to first convert the date to a timestamp at index
: time and store it in a field type slong? This might be more effic
Actually, just thinking about this a bit more, perhaps adding a function
call such as parseDate() might add too much overhead to the actual query,
perhaps it would be better to first convert the date to a timestamp at index
time and store it in a field type slong? This might be more efficient but
I've been using a simple variation of the boost function given in the
examples used to boost more recent documents:
recip(rord(creationDate),1,1000,1000)^1.3
While it seems to work pretty well, I've realised that this may not be quite
as effective as i had hoped given that the calculation is base
