I never used Lotus 123, so I was not familiar with the particulars of its
NSUM function; . . .

If I do nothing else than convince people who've never used 123 to
exercise just a little bit or reticence about responding to 123-to-
Excel posts, I'll have done something positive.

I hope this is not some kind of life-goal for you because, if it is, I'm
afraid I'm going to be disappointing you if a similar situation should come
up in the future. First, let me agree, to some extent, with the underlying
sentiment in your comment though. When I posted this back to the OP...

"If you want something more "friendly" looking that the other solutions
posted so far, you can create a User Defined Function to duplicate the
functionality of the NSUM function..."

I will admit that it overstated what I was providing. Rather than saying the
code duplicated the functionality of the NSUM function and stopping, I
should have continued the above quote with something like "... as you have
portrayed it to us in your supplied example." I believe part of the reason
the VBA side of Excel exists is to allow a user to create (or have created
for them) a method of providing an easy-to-use interface to Excel for some
given task that is expected to be repeated. If the OP is not all that
familiar with SUMPRODUCTs, then he might experience some problems in trying
to reuse the formulas provided to him for other similar situations... the
VBA function I provided would allow him a more familiar (read as, more
easily reusable) interface to use for other similiar situations he might
have reason to make use it for. Did my function implement **all** of Lotus
123's NSUM function? No, of course not, but I don't believe it was necessary
for it to do so (whether I was aware of all the parts of Lotus 123's
function or not)... all it had to do is implement the functionality the OP
said he was looking for. Providing a full replacement function might be a
nice exercise (and for some others out there, even a desireable one),
however, for the question that was asked, I believe doing so would be
overkill and might, because of the extra code and different manner of
construction, possibly slow down the execution further over that of the code
I provided while offering no extra usable functionality to the OP.

--
Rick (MVP - Excel)


. . . does the Lotus 123 NSUM function actually wrap the areas as your
code does? By that I mean, for this formula...

=NSUM(1,3,B5:C15)

the cells that will be added are B6, B9, B12, C7, C10, C13... notice the
Column B cells are offset, row-wise, from the Column A cells. Of course
this
will happen whenever the loop through the rows does not finish on the
column's last processed row. Not having any personal experience with the
actual NSUM function, this looks, at first blush, to be somewhat useless
to
me... my gut feeling tells me it would be more practical to have the same
row processed in each column

Simple enough to test. In 123R8 I enter the following values in C3..D7

1 600000
20 7000000
300 80000000
4000 900000000
50000 0.5

The 123 formula @NSUM(1,3,C3..D7) returns 80050020, or, in order,
C4+C7+D5. I enter the same values in C3:D7 in Excel, and using my nsum
udf, the formula =nsum(1,3,C3:D7) also returns 80050020. This follows
123's default iteration order through C3:D7, namely, C3, C4, C5, C6,
C7, D3, D4, D5, D6, D7, so offsetting 1 and including every 3rd item
means including C4, C7, D5.

Whether this is useful or not is up to the user, but if the goal is
presumably giving the OP a udf that doesn't FUBAR any nontrivial
formula porting from 123 to Excel, then you have to live with the 123
specs whether or not they make sense to you. If you don't know the 123
specs and/or can't figure out how to find them using a web search, why
respond with a udf that (LIKELY!) wouldn't be robust?