Using HLOOKUP in calculations

Let's see if I can describe my issue.


I'm doing something in an ugly, sloppy way, and I'm sure there's a better way (probably using HLOOKUP) but I'm not sure what it is.


I have a lookup table with prices. I have a main table with a list of quantities. My calculation field looks like (Quantity1 x Price1 + Quantity2 x Price2 + Quantity3 x Price3…)


The headers for each table are identical…Item1, Item2, etc.


The problem, if course, is that if I move columns around or add or delete columns in the main table, everything breaks and I have to go in and fix my long and ugly calculation field by hand.


What's the "right" way to do this?

MacBook Air 13", macOS 10.14

Posted on Oct 27, 2019 8:03 AM

Reply
Question marked as Top-ranking reply

Posted on Oct 27, 2019 2:30 PM

SGIII wrote:

It almost never pays to have a big long formula like that.

Yes, I know; that's why I'm here looking for a better way. I knew there had to be one, but I didn't know what it was.


In this case, is there a reason you are not using SUMPRODUCT?

Yes: I didn't know it existed. Thanks! That looks like precisely what I needed.

13 replies
Question marked as Top-ranking reply

Oct 27, 2019 2:30 PM in response to SGIII

SGIII wrote:

It almost never pays to have a big long formula like that.

Yes, I know; that's why I'm here looking for a better way. I knew there had to be one, but I didn't know what it was.


In this case, is there a reason you are not using SUMPRODUCT?

Yes: I didn't know it existed. Thanks! That looks like precisely what I needed.

Oct 27, 2019 9:27 AM in response to Bismarck2387

In my example above, argument 1 of my index function (range) is my entire lookup table. Argument 2 (Row Index) is my Match formula. Argument 3 (column index) is “2” because the value I want (price) is in the second column of my range. Argument 4 is “1” because I only selected one range. For the match formula, argument 1 is a cell reference to “Apples”. This is the word I am searching for. Argument 2 is the column in which it will find the word “Apples” in my lookup Table. This is a 1 dimensional array. Either a single column or a single row. Argument 3 is “find exact value” because it is searching for text.


Using Match on its own in this example would produce a result of 2, because Apples is in the second cell of the column in which it is searching. So my index formula will give me the value in the second row, and second column (because I used 2 as my column reference) of my range (entire lookup table) which is $2.00.


In this example, I only used Match as the row reference, and used a constant (“2”) as my column reference, because I knew the price I am trying to look up is in the second column of my range. But if I was adding columns to my lookup table and it may not stay the second column, I could use Match twice, as both my row index and column index. If I used it as my column index, I would search for the word price in row 1 to identify the column number in which it would find price.


Link to example: https://www.icloud.com/numbers/0-3uZlurvj0kXx3wSZadv6LmA#Blank_24

Oct 27, 2019 1:18 PM in response to Zarquon42

Hi Zarquon,


It would be useful to know how you are using these tables. I think they will want to be reorganized for clarity and ease of use. Numbers has many more rows available than columns and so the program makes it easier to do things when data is organized more like Bismarck's Price list table. It will be easier to read and more compact also.


It looks like you are trying to track sales of different scouts. Where is this data originating? Is it being entered by you or is it being brought over from another table? I would suggest a single table devoted to input, a lookup table for your prices and a report table. This will break up the tasks you are asking of Numbers and so simplify your formulas. It should also be easier to interpret your data.


quinn

Oct 27, 2019 8:58 AM in response to Bismarck2387

Here is a generic example:



This formula contains 3 functions. They are:



Match will return the position of a value in an array. For example, if you have a column of 10 cells, numbered from 10 to 19, and you use Match to look up 12, it will return a result of 3, as 12 is in the third cell. Use match as your row reference if looking up something in a column list, and as a column reference if looking up something in a row list. The other reference will be the row or column in which the value you are trying to look up will be.


Oct 27, 2019 9:23 AM in response to Bismarck2387

Hi Bismarck,


I am also a big fan of INDEX/MATCH for lookups. We can do everything any of the LOOKUP variants do and with more flexibility.


I suggest that IFERROR is worth avoiding whenever possible. It can mask issues and there is usually another way to accomplish what is needed.


One way to test a cell for content is with LEN, which will count the characters in a cell. We could construct our formula like this:

IF(LEN(source-string)>0,INDEX/MATCH,"")

This would prevent an error flag only if there was an empty cell. Otherwise we can see what is going on.


quinn

Oct 27, 2019 1:30 PM in response to Zarquon42

It almost never pays to have a big long formula like that.


In this case, is there a reason you are not using SUMPRODUCT? You can do something like this:



The trick is to have the ranges the same size in both tables.


The formula in F2 of my example, filled down, is:


=SUMPRODUCT(B2:E2,Prices::$B$2:$E$2)


If you change the order (or number of columns) in the main table, you can simply change the order (and number of columns) in the Prices table to match.


Substitute ; for , in the formula if your regions uses , as a decimal separator.


SG

Oct 27, 2019 2:28 PM in response to t quinn

t quinn wrote:

Hi Zarquon,

It would be useful to know how you are using these tables. I think they will want to be reorganized for clarity and ease of use. Numbers has many more rows available than columns and so the program makes it easier to do things when data is organized more like Bismarck's Price list table. It will be easier to read and more compact also.

It looks like you are trying to track sales of different scouts. Where is this data originating? Is it being entered by you or is it being brought over from another table? I would suggest a single table devoted to input, a lookup table for your prices and a report table. This will break up the tasks you are asking of Numbers and so simplify your formulas. It should also be easier to interpret your data.


A report table is a good idea. I am not at all expert in spreadsheets; I know just enough to get myself into trouble :)


The reason the main table is organized as it is is that the number of Scouts is indefinite. So while the number of columns is fixed, the number of rows is variable, which to me is consistent with how spreadsheets should be laid out. And then I've got the lookup table in the same orientation so that I can just copy and paste the list of popcorn from one table to another (it changes every year).


I input the numbers by hand. They're organized in the same order as on the order forms, so I just input them as they appear on the sheets.

This thread has been closed by the system or the community team. You may vote for any posts you find helpful, or search the Community for additional answers.

Using HLOOKUP in calculations

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.