By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,131 Members | 1,977 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,131 IT Pros & Developers. It's quick & easy.

Divide by zero.

P: n/a
Dear all,

Assume I have two big arrays A and B. And I want to element-wise divide
A by B. When an element of B is zero, the results are also zero.

Such as A = { 2, 4, 0, 6}
B = { 1, 0, 0, 2}
-----------------------------------------
R = { 2, 0, 0, 3}

Any fast way to avoid the slow 'if' operation.

Thanks,

Shuisheng

Sep 25 '06 #1
Share this Question
Share on Google+
4 Replies


P: n/a
shuisheng wrote:
Assume I have two big arrays A and B. And I want to element-wise
divide A by B. When an element of B is zero, the results are also
zero.

Such as A = { 2, 4, 0, 6}
B = { 1, 0, 0, 2}
-----------------------------------------
R = { 2, 0, 0, 3}

Any fast way to avoid the slow 'if' operation.
You like to avoid things, don't you? :-)

How slow is it? If you take two arrays such that B doesn't have
any zeros in it, how much does 'if' slow you down? Is it really
so significant? AFAIUI, you cannot avoid some kind of checking
against 0 to prevent division by 0, right? You could try playing
tricks with arithmetic, but it is most likely just as expensive
as comparing B[i] with 0.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Sep 25 '06 #2

P: n/a
shuisheng posted:
Dear all,

Assume I have two big arrays A and B. And I want to element-wise divide
A by B. When an element of B is zero, the results are also zero.

Such as A = { 2, 4, 0, 6}
B = { 1, 0, 0, 2}
-----------------------------------------
R = { 2, 0, 0, 3}

Any fast way to avoid the slow 'if' operation.

The fastest code I can think of at the moment is the following (but
ofcourse, it tests a conditional):

#include <cstddef>
#include <cassert>

void Divide(int *pA, int const *pB, std::size_t const len)
{
assert(pA); assert(pB); assert(len);

int register temp;

int const *const poverA = pA + len;

do (temp = *pB++) ? (*pA++ /= temp) : (*pA++ = 0);
while(poverA!=pA);
}

Or maybe if you're working with a machine which has a single instruction
which takes a pointer plus an offset:

void Divide(int *const pA, int const *const pB, std::size_t const len)
{
assert(pA); assert(pB); assert(len);

int register temp;

std::size_t register i = 0;

do (temp = pB[i]) ? (pA[i] /= temp) : (pA[i] = 0);
while(++i!= len);
}

--

Frederick Gotham
Sep 25 '06 #3

P: n/a

Victor Bazarov 写道:
How slow is it? If you take two arrays such that B doesn't have
any zeros in it, how much does 'if' slow you down? Is it really
so significant? AFAIUI, you cannot avoid some kind of checking
against 0 to prevent division by 0, right? You could try playing
tricks with arithmetic, but it is most likely just as expensive
as comparing B[i] with 0.
The difference is very small: sevral percents and some times even the
same. Thanks!!!

Shuisheng

Sep 25 '06 #4

P: n/a
shuisheng wrote:
Victor Bazarov ??:
>How slow is it? If you take two arrays such that B doesn't have
any zeros in it, how much does 'if' slow you down? Is it really
so significant? AFAIUI, you cannot avoid some kind of checking
against 0 to prevent division by 0, right? You could try playing
tricks with arithmetic, but it is most likely just as expensive
as comparing B[i] with 0.

The difference is very small: sevral percents and some times even the
same. Thanks!!!
Hey, don't mention it!

OK, how much of your application does division of the two arrays take?
If it's about 10 percent total (from start to finish), then if you
shave off another 10 percent of that by removing (magically) the 'if',
what is the final improvement for the application? 1 percent at best?
Is it worth the time you spend trying to find the magic to remove the
pesky 'if'?

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Sep 25 '06 #5

This discussion thread is closed

Replies have been disabled for this discussion.