2d index min/max limit

[Andi]

> db.tri.ensureIndex({ c: '2d', t: 1 }, { min: 0, max: Math.pow(2, 40) })
point not in range

In this case, all data in the collection is within this range.

[Gates]

I think the problem here is 2^40

That's a very large number (40 bits) and it's probably overflowing.
This thing works for Math.pow(2,30), but not 31.

Do you specifically need 2^40 for your calculations?

If so you'll want to file a feature request or bug fix:
http://jira.mongodb.org/

- Gates

[Andi]

How is the number encoded in the index? Is it a 64bit double?

[Gaetan Voyer-Perrault]

Doing this with 1.6.5:

db.tri.ensureIndex({ c: '2d', t: 1 }, { min: 0, max: Math.pow(2, 40) })

Causes an index to be created that looks like this:

{ "_id" : ObjectId("4d7a9e1e8914000000000ec4"), "ns" : "test.tri", "key" : { "c" : "2d", "t" : 1 }, "name" : "c__t_1", "min" : 0, "max" : 1099511627776 }

So it looks like the index can be created, but something else is throwing the error. Looking at the source code, there are several unit tests using min and max, but nothing using a number this big.

https://github.com/mongodb/mongo/tree/master/jstests

I've recorded the issue as a bug here:

http://jira.mongodb.org/browse/SERVER-2746

Is there a particular reason that you need such a large max number?

What are you trying to achieve with this index?

I'm wondering if there's a workaround for your problem.

 - Gates

--
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To post to this group, send email to mongod...@googlegroups.com.
To unsubscribe from this group, send email to mongodb-user...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mongodb-user?hl=en.

[Andi]

Now I have reduced the range to 2^30, this is the absolute minimum. I
use the index to put complex data into a form so that it can be
queried with 2 range conditions. The complexity implies this big
range.
Building the index is no problem, but now there is a bug when I query
the data: http://jira.mongodb.org/browse/SERVER-2748

On 11 Mrz., 23:30, Gaetan Voyer-Perrault <ga...@10gen.com> wrote:
> Doing this with 1.6.5:
> db.tri.ensureIndex({ c: '2d', t: 1 }, { min: 0, max: Math.pow(2, 40) })
>
> Causes an index to be created that looks like this:
> { "_id" : ObjectId("4d7a9e1e8914000000000ec4"), "ns" : "test.tri", "key" : {
> "c" : "2d", "t" : 1 }, "name" : "c__t_1", "min" : 0, "max" : 1099511627776 }
>
> So it looks like the index can be created, but something else is throwing
> the error. Looking at the source code, there are several unit tests using

> min and max, but nothing using a number this big.https://github.com/mongodb/mongo/tree/master/jstests

[Gaetan Voyer-Perrault]

I don't know of any other work-arounds at this point.

Thank you for reporting that additional bug.

[Andrew Armstrong]

A possible workaround may be to scale your data points (instead of
having to be 2^30 - maybe reduce the scale by 10%?) to find an
approximate result, and then store the exact co-ordinates for a final
comparison manually before returning the result set to the user?

[Greg Studer]

There are now changes in 1.9 to the way bounds are handled in 2d
indexing so that very large and small values can be used, which may
solve your large number issues (including more helpful error
messages). However, the precision of the index will still be limited
to 32 bits, so depending on your data, doing a pre-transform to a more
uniform space may still be the right option.

[Greg Studer]

There are now changes in 1.9 to the way bounds are handled in 2d
indexing so that very large and small values can be used, which may
solve your large number issues (including more helpful error
messages). However, the precision of the index will still be limited
to 32 bits, so depending on your data, doing a pre-transform to a more
uniform space may still be the right option.

On Mar 11, 7:14 pm, Andi <andreaskal...@gmx.de> wrote: