In my code, I often use a formula that returns me an index into a 2D array:
cells[cellToMarkX + cellToMarkY * xSize]
// ...
if (cells[j + i * xSize] == 0)
//...
else if (cells[j + i * xSize] >= 5)
//..
cells[cellToMarkX + cellToMarkY * xSize] += 4;
I'm not sure if I should instead create some function like
getCell(int x, int y)
or should is this unnecessary and I should prefer to use a macro?
Particularly in the example you give, you might want to consider precomputing as well, as in:
int myindex = j + i * xSize;
if (cells[myindex] == 0)
....
else if (cells[myindex] >= 5)
but to answer your question more directly, a function call is not out of place here, particularly if you declare it with the inline attribute. In many cases, a good optimizing compiler will generate the same code regardless of whether you use a macro or a function, but that is of course implementation-dependent.
Personally, I'd prefer a function.
Related
int Fun(int m, int n)
{
if(n==0)
{
return n + 2;
}
return Fun(n-1, m-1) + Fun(m-1,n-1) + 1;
}
I'm completely lost as to what the 1st case would visually look like for this function. I don't understand why the function has two parameters and why we only return 1 parameter at the end with our base case. What would be the process to work this out? Any input you want to use to explain to me is fine I was trying (3,3). Although, now that I'm thinking about it how would this function look like if one of the inputs was smaller than the other like (3,2) or (2,3)?
Note that return n + 2; simplifies to return 2;.
The function takes two arguments (parameters) and returns a single value. That's like the operation of adding two numbers that you were taught in your first year at school.
Whether or not Fun(n - 1, m - 1) is called before Fun(m - 1, n - 1) is not specified by the C++ standard. So I can't tell you what the first recursive call will look like. This gives compilers more freedom in making optimisation choices. Of course the order in which the functions are called has no effect on the eventual result.
The best way of analysing what happens in your particular case is to use a line by line debugger.
There is nothing special about recursive functions - they work exactly like non-recursive functions.
Fun(3,3) does this:
if(3==0)
{
return 3 + 2;
}
return Fun(2, 2) + Fun(2, 2) + 1;
It needs the value of Fun(2,2), which does this:
if(2==0)
{
return 2 + 2;
}
return Fun(1, 1) + Fun(1, 1) + 1;
And that needs Fun(1,1), which does
if(1==0)
{
return 1 + 2;
}
return Fun(0, 0) + Fun(0, 0) + 1;
and Fun(0,0) does
if(0==0)
{
return 0 + 2;
}
return Fun(-1, -1) + Fun(-1, -1) + 1;
which returns 2 since the condition is true.
So, Fun(1, 1) will do
return 2 + 2 + 1;
which is 5, and Fun(2,2) will do
return 5 + 5 + 1;
which is 11, and Fun(3,3) will do
return 11 + 11 + 1;
which is 23.
I'm sure you can work through other examples on your own.
I'm using a C++ compiler but writing code in C (if that helps)
There's a series of numbers
(-1^(a-1)/2a-1)B^(2a-1)
A and X are user defined... A must be positive, but X can be anything (+,-)...
to decode this sequence... I need use exponents/powers, but was given some restrictions... I can't make another function, use recursion, or pow() (among other advanced math functions that come with cmath or math.h).
There were plenty of similar questions, but many answers have used functions and recursion which aren't directly relevant to this question.
This is the code that works perfectly with pow(), I spent a lot of time trying to modify it to replace pow() with my own code, but nothing seems to be working... mainly getting wrong results. X and J are user inputted variables
for (int i = 1; i < j; i++)
sum += (pow(-1, i - 1)) / (5 * i - 1) * (pow(x, 5 * i - 1));
}
You can use macros to get away with no function calls restriction as macros will generate inline code which is technically not a function call
however in case of more complex operations macro can not have return value so you need to use some local variable for the result (in case of more than single expression) like:
int ret;
#define my_pow_notemp(a,b) (b==0)?1:(b==1)?a:(b==2)?a*a:(b==3)?a*a*a:0
#define my_pow(a,b)\
{\
ret=1;\
if (int(b& 1)) ret*=a;\
if (int(b& 2)) ret*=a*a;\
if (int(b& 4)) ret*=a*a*a*a;\
if (int(b& 8)) ret*=a*a*a*a*a*a*a*a;\
if (int(b&16)) ret*=a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a;\
if (int(b&32)) ret*=a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a;\
}
void main()
{
int a=2,b=3,c;
c=my_pow_notemp(a,b); // c = a^b
my_pow(a,b); c = ret; // c = a^b
}
as you can see you can use my_pow_notemp directly but the code is hardcoded so only up to a^3 if you want more you have to add it to code. The my_pow is accepting exponents up to a^63 and its also an example on how to return value in case of more complex code inside macro. Here are some (normal) ways on how to compute powers in case you need non integer or negative exponents (but to convert it to unrolled code will be insanely hard without loops/recursion):
Power by squaring for negative exponents
In case you want to get away with recursion and function calls you can use templates instead of macros but that is limited to C++.
template<class T> T my_pow(T a,T b)
{
if (b==0) return 1;
if (b==1) return a;
return a*my_pow(a,b-1);
}
void main()
{
int a=2,b=3,c;
c=my_pow(a,b);
}
As you can see templates have return value so no problem even with more complex code (more than single expression).
To avoid loops you can use LUT tables
int my_pow[4][4]=
{
{1,0,0,0}, // 0^
{1,1,1,1}, // 1^
{1,2,4,8}, // 2^
{1,3,9,27}, // 3^
};
void main()
{
int a=2,b=3,c;
c=my_pow[a][b];
}
If you have access to FPU or advanced math assembly you can use that as asm instruction is not a function call. FPU usually have log,exp,pow functions natively. This however limits the code to specific instruction set !!!
Here some examples:
How to: pow(real, real) in x86
So when I consider your limitation I think the best way is:
#define my_pow(a,b) (b==0)?1:(b==1)?a:(b==2)?a*a:(b==3)?a*a*a:0
void main()
{
int a=2,b=3,c;
c=my_pow(a,b); // c = a^b
}
Which will work on int exponents b up to 3 (if you want more just add (b==4)?a*a*a*a: ... :0) and both int and float bases a. If you need much bigger exponent use the complicated version with local temp variable for returning result.
[Edit1] ultimative single expression macro with power by squaring up to a^15
#define my_pow(a,b) (1* (int(b&1))?a:1* (int(b&2))?a*a:1* (int(b&4))?a*a*a*a:1* (int(b&8))?a*a*a*a*a*a*a*a:1)
void main()
{
int a=2,b=3,c;
c=my_pow(a,b); // c = a^b
}
In case you want more than a^15 just add sub term (int(b&16))?a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a:1 and so on for each bit of exponent.
It is a series. Replace pow() based on the previous iteration. #Bathsheba
Code does not need to call pow(). It can form pow(x, 5 * i - 1) and pow(-1, i - 1), since both have an int exponent based on the iterator i, from the prior loop iteration.
Example:
Let f(x, i) = pow(x, 5 * i - 1)
Then f(x, 1) = x*x*x*x
and f(x, i > 1) = f(x, i-1) * x*x*x*x*x
double power_n1 = 1.0;
double power_x5 = x*x*x*x;
for (int i = 1; i < j + 1; i++)
// sum += (pow(-1, i - 1)) / (5 * i - 1) * (pow(x, 5 * i - 1));
sum += power_n1 / (5 * i - 1) * power_x5;
power_n1 = -power_n1;
power_x5 *= x*x*x*x*x;
}
Edit: I’m a beginner to C++, and I’d like to understand more about how to optimize my code.
I have created a Fraction object in C++ as well as overloaded +, - operations etc. When I came to the unary operators, however, I realized I didn't know how to reduce the fraction in the most efficient manner. So I have a function gcd that finds the greatest divisor:
int gcd (int n, int m) {
int newN = n < 0 ? -n : n;
int newM = m < 0 ? -m : m;
if (newM <= newN && newN % newM == 0) { return newM; }
else if (newN < newM) { return gcd(newM, newN); }
else { return gcd(newM, newN%newM); }
}
and then I have an overloaded operator, for example, incrementation:
Fraction& Fraction::operator++() {
num = num + denom;
//reduce fraction
int divisor = gcd(denom,num);
num = num/divisor;
denom = denom/divisor;
if (num < 0 && denom < 0) {num *= (-1);}
if (denom < 0) {denom *= (-1);}
return *this;
}
For efficiency, I would like to put the reduce fraction part of the code in a separate single helper function so the final function would look like this:
Fraction& Fraction::operator++() {
num = num + denom;
//reduce fraction
reduce(num, denom);
return *this;
}
That way I don't have to copy and paste whatever is in //reduce fraction everytime I overload a unary operator for example. However, I'm not sure how the reduce(Fraction num, Fraction& denom) function should look like. At most I can implement it like this:
void reduce(int& num, int& denom) {
int divisor = gcd(denom,num);
num = num/divisor;
denom = denom/divisor;
if (num < 0 && denom < 0) {num *= (-1);}
if (denom < 0) {denom *= (-1);}
}
I'm sure the code above will run into issues during compilation, so I was wondering if I could be suggested any pointers as to efficiently create the reduce fraction function. This is maybe being a bit nitpicky since my original code runs fine, but since I am new to C++, I'd like to learn more about how I can make my code more efficient. Thanks a lot! Let me know if more information is needed.
Edit: The above code does not work. Compiles correctly, but does not reduce fraction properly. So 1/2 + 1/4 results in 6/8, not 3/4.
Well on a high level your gcd function is too complicated and the last part of reduce is a bit wrong. If only denom is negative you invert it.
Nicely shows why it's always a good idea to put code into proper functions because they can also be separately tested. So I'd suggest writing some unit tests for your reduce and gcd functions.
Start with a simple solution like
static int gcd(int a, int b)
{
return b == 0 ? a : gcd(b, a % b);
}
and adapt if needed for negative numbers considering % semantics. Thinking about it the function should already be fine like that and you just need to call std::abs(gcd(n,d)) in reduce.
In general you should ask yourself if you really want to pay the renormalization cost at every single operation or if you let the user decide when to call reduce.
For lower-level optimizations here are some hints:
Always test/measure, e.g. by looking at what the compiler actually produces with godbolt.org.
The recursion in gcd is not a problem from a performance point of view in this case as it's tail recursive and the compiler will turn it into a loop for you.
The out parameters in reduce are bad for optimizations cause the compiler has to prove they don't point to the same object. Returning a std::pair and using C++11 std::tie or C++17 structured bindings at the callsite if possible is way more elegant.
I have the following define macros:
#define NHID 5
#define NENT 10
#define NOUT 4
#define NWEIS (NENT + 1) * NHID + (NHID + 1) * NOUT
So everytime that the compiler finds a "NWEIS", it will replace "NEWIS" for "(NENT + 1) * NHID + (NHID + 1) * NOUT". But that is not what I want. I want it replace "NWEIS" by the actual value = 79, without having to declare extra variables in the memory. Is there a decent way to do this?
Macro replacement is mostly1 an iterative process.
What you will get, following macro substitution is an expression with the constants. And any decent compiler will be able to fold those constants (evaluate them at compile time) to give you the single value of 79.
For example, consider the program:
#define NHID 5
#define NENT 10
#define NOUT 4
#define NWEIS (NENT + 1) * NHID + (NHID + 1) * NOUT
int main (void) { return NWEIS; }
here's the pre-processor output from gcc -E:
int main (void) { return (10 + 1) * 5 + (5 + 1) * 4; }
and here's the relevant assembler code line it generates with gcc -S (the return value is placed into the eax register):
movl $79, %eax
Having said that, there are precious few reasons to use macros any more since you have constant "variables", inline suggestions to the compiler, enumerated types and so forth, all things that macros used to be very useful for.
I still find myself reaching for macros for quick'n'dirty code of course, but that's mostly because I'm an old codger, forged in the early C days before we even had prototypes :-)
It may be worthwhile rethinking your use of them as well, since you can replace it with something like:
const int nhid = 5;
const int nent = 10;
const int nout = 4;
const int nweis = (nent + 1) * nhid + (nhid + 1) * nout;
A smart compiler should still be able to optimise the calculations away at compile time and you'll most likely find that the variables are available in the debugger for you, something that often doesn't happen with macros.
1 Full details can be found in the C++11 standard, section 16.3 Macro replacement.
Suffice to say there are certain uses of # and ## within a macro that prevent further replacement of that token (the former replaces the token with a character string literal and the latter combines multiple tokens into a different token).
Since you're not using those, it's irrelevant here.
The macros you are using do not cost you extra memory. You have already acheived what you want.
Let's look at what a reasonable compiler will do.
Suppose you have this code.
#define NHID 5
#define NENT 10
#define NOUT 4
#define NWEIS (NENT + 1) * NHID + (NHID + 1) * NOUT
int f()
{
return NWEIS;
}
A reasonable compiler will obviously expand it into:
int f()
{
return (NENT + 1) * NHID + (NHID + 1) * NOUT;
}
The next step will than be:
int f()
{
return (10 + 1) * 5 + (5 + 1) * 4;
}
As this arithmetic expression consist of hard-coded numbers (constant expression) only, the compiler can treat the whole thing as a constant too.
int f()
{
return 79;
}
Note that this function is so small, a reasonable compiler will try its best to in-line the function.
However, it is much more preferable to do this:
constexpr int NHID = 5;
constexpr int NENT = 10;
constexpr int NOUT = 4;
constexpr int NWEIS = (NENT + 1) * NHID + (NHID + 1) * NOUT;
Just use
const int NHID = 5;
const int NENT 10;
const int NOUT 4;
const int NWEIS = (NENT + 1) * NHID + (NHID + 1) * NOUT;
A good optimizer will substitute these values at compile-time and not place any variables in memory, unless you do something such as take their address. Then you have the type safety and scoping of C++ without the macro evilness.
(Upper case names are by convention reserved for macros, so you may want to rename them slightly)
I have a function that looks like this:
int div_round_up(int x, int y) {
/**
* This function only works for positive divisor and non-negative dividend!!
*/
assert(y > 0 && x >= 0);
if (x == 0)
return 0;
return (x - 1) / y + 1;
}
It won't work with y <= 0 or x < 0. That's ok with me, I can even dynamically check for right values, but I would like to check statically, when someone feeds it wrong values. If I defined x and y as unsigned, they would get silently converted from negative values to huge positive values which would produce erroneous result, so I don't want that. I would like to make compilation fail when someone attempts to feed it negative values like in div_round_up(variable, -7). What should I do?
To verify a number at compile time (which is what static_assert does), it has to be known at compile time. To see why this is needed, consider that something like div_round_up(read_integer_from_file(), read_keyboard_character()). The obvious drawback of doing that is that you have to know the numbers at compile time.
The easiest way is to make them template parameters, which allows you to leave the implementation of the function (almost) the same:
template<int x, int y>
int div_round_up() {
static_assert(y > 0 && x >= 0, "This function only works for positive divisor and non-negative dividend");
if (x == 0)
return 0;
return (x - 1) / y + 1;
}
It can be called as div_round_up<3, 4>() and will fail the compilation when the static_assert fires.
If you're using gcc or clang you can include a macro
#define div_round_up(a, b) (__builtin_constant_p(b) ? drus(a, b) : drud(a, b))
and two different function where drus includes a static assertion for b while drud does not.
Yeap you can do it with some magic(one nonamed russian code guru told me this trick)
#define check2(x) typedef char checkVal[(x)?1:-1];
int main() {
check2(3<4);
check2(5<4);
return 0;
}
but also in this case there is one limit. Compiler should know result of this value. In any another case it`s imossible(IMHO).