After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 534229 - vlookup doesn't work on large range
vlookup doesn't work on large range
Status: RESOLVED INVALID
Product: Gnumeric
Classification: Applications
Component: General
1.9.x
Other All
: Normal normal
: ---
Assigned To: Morten Welinder
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2008-05-21 17:57 UTC by A
Modified: 2008-05-22 20:22 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
this is where I noticed this (553.43 KB, application/x-gnumeric)
2008-05-21 18:02 UTC, A
Details

Description A 2008-05-21 17:57:31 UTC
I will attach a file that demonstrates this interesting behaviour

I am using the function Vlookup:

I noticed that this works
=vlookup(B25,data!N18:P15967,2,TRUE)*4/$B$9

but this doesn't work:
=vlookup(B25,data!N18:P15968,2,TRUE)*4/$B$9

it also doesn't work on ranges beyond the 15968 number
Comment 1 A 2008-05-21 18:02:00 UTC
Created attachment 111287 [details]
this is where I noticed this

look at B27 or B28 on "output" sheet
Comment 2 Andreas J. Guelzow 2008-05-21 18:18:48 UTC
I do not see this under Linux on AMD64.
Comment 3 Andreas J. Guelzow 2008-05-21 18:30:15 UTC
hmm, I was a touch too fast:

I don't see it under Linux on AMD64 with Gnumeric 1.8 but
I do see a problem under Linux on AMD64 with Gnumeric 1.9.1.

At least the answers a different under the two versions of Gnumeric and I suspect that 1.9.1's 0 is not the correct answer for B28.
Comment 4 Morten Welinder 2008-05-21 19:29:29 UTC
Chances are pretty good that this is my fault.
Comment 5 Morten Welinder 2008-05-21 19:43:19 UTC
The formula is invalid: the range is not sorted.

"If @approximate is true, then the values must be sorted in order
of ascending value [...]"

That said, there are problems with the code.
Comment 6 Morten Welinder 2008-05-22 20:22:02 UTC
Problems with the code fixed.  The problems did not affect this case.

The particular usage is invalid, so results are not to be relied on.
The range absolutely must be sorted for this to make sense.
We get 0, XL gets #NA.