subset

[mary8shtr]

Hi.I write this program.but i should write it, too recursive.and Could you help me in this case.

#include <iostream>
using namespace std;
int pow(int a,int b)
{
int p=1;
for(int i=0;i<b;i++)
p=p*a;
return p;
}
int main()

{
int testcase=0;

int n;

long long *a;

a=new long long[200];

cin>>testcase;

int i=0;

int d,b,c;

while(i<testcase)
{
cin>>n;

for(int j=0,k=1;j<n;j++,k++)
{
a[j]=k;
}


for(int p=0;p<=pow(2,n)-1;p++)
{
cout<<'{';

d=p;
for(int m=0;m<n;m++)
{

c=pow(2,n-1);

b=c&d;

if(b!=0)

cout<<a[m]<<' ';

d=d<<1;
}

cout<<'}';

cout<<endl;
}

cout<<endl;

i++;
}
return 0;
}

 

[Stefan Ram]

Hi.I write this program.but i should write it, too recursive.and Could you help me in this case.

#include <iostream>
#include <ostream>
#include <vector>
template< typename T >struct counter
{ ::std::vector< T >& sequence; int top;
counter( ::std::vector< T >&& sequence ):
sequence( sequence ), top( sequence.size() ){ count( 0 ); }
void count( int const pos )
{ if( pos == top )
{ for( int pos = 0; pos < top; ++pos )
::std::cout <<( sequence[ pos ]?( char )( '`' +( top - pos ) ): ' ' );
::std::cout << '\n'; }
else
{ sequence.at( pos )= 0; count( pos + 1 );
sequence.at( pos )= 1; count( pos + 1 ); }}};
int main(){ counter< int > c( ::std::vector< int >( 3 )); }

 

[Barry Schwarz]

It would make your code a lot easier to read if

You indented consistently.
You doubled space between lines only to separate sections of your
functions.
You used the space bar more frequently.

Why does the definition of testcase contain initialization?

Why is a defined as a pointer and not as an array?

In the 'm' for loop, why do you re-evaluate c each iteration when its
value never changes?

What is the output supposed to represent?

If you google for recursion in C, you should get several hits that
show how to convert an iterative solution to a recursive one. If you
don't find an example for pow, look at the one for factorial.

Hi.I write this program.but i should write it, too recursive.and Could you help me in this case.

#include <iostream>
using namespace std;
int pow(int a,int b)
{
int p=1;
for(int i=0;i<b;i++)
p=p*a;
return p;
}
int main()

{
int testcase=0;

int n;

long long *a;

a=new long long[200];

cin>>testcase;

int i=0;

int d,b,c;

while(i<testcase)
{
cin>>n;

for(int j=0,k=1;j<n;j++,k++)
{
a[j]=k;
}


for(int p=0;p<=pow(2,n)-1;p++)
{
cout<<'{';

d=p;
for(int m=0;m<n;m++)
{

c=pow(2,n-1);

b=c&d;

if(b!=0)

cout<<a[m]<<' ';

d=d<<1;
}

cout<<'}';

cout<<endl;
}

cout<<endl;

i++;
}
return 0;
}

 

[woodbrian77]

It would make your code a lot easier to read if


You indented consistently.
You doubled space between lines only to separate sections of your
functions.

You used the space bar more frequently.

I'm with you for the first two, but I've seen
some who I think are good programmers not use
many spaces within a line of code, and I write
it that way sometimes also:

http://webEbenezer.net/misc/direct.cc

If you google for recursion in C,

Watch out for Google.

Duckduckgo cares about your privacy:

https://Duckduckgo.com


http://donttrack.us


Brian
Ebenezer Enterprises
http://webEbenezer.net

 

[Stefan Ram]

The given code looks like:
int testcase=0;
cin>>testcase;
while(i<testcase)
Now, there are many problems you might pick with that code, but
anything caused by initializing testcase to a default value in case
the cin input fails is not among them. Would you rather that the
subsequent loop go running off to some undetermined possibly huge
number just because testcase was never given a value?

Yes, otherwise the real error (not checking the stream
state after reading) might remain hidden even longer!

 

[David Brown]

On Fri, 07 Feb 2014 11:04:40 -0800 in comp.lang.c++, Barry Schwarz


Because you should never define an uninitialized variable without a
really good reason!

The given code looks like:
int testcase=0;
cin>>testcase;
while(i<testcase)

Now, there are many problems you might pick with that code, but
anything caused by initializing testcase to a default value in case
the cin input fails is not among them. Would you rather that the
subsequent loop go running off to some undetermined possibly huge
number just because testcase was never given a value?

You should never unnecessarily initialise a variable, because that stops
the compiler checking your code for you.

If you leave "int testcase;" uninitialised, and later use it without
first setting its value, then the compiler's warnings will tell you.
But if you've used "int testcase = 0;", then the compiler can't help you
spot that error.

 

[Victor Bazarov]

You should never unnecessarily initialise a variable, because that stops
the compiler checking your code for you.

If you leave "int testcase;" uninitialised, and later use it without
first setting its value, then the compiler's warnings will tell you. But
if you've used "int testcase = 0;", then the compiler can't help you
spot that error.

Reliance on compiler warnings can only be done in conjunction with other
ways of ensuring correctness of the code. Code reviews and following
coding standards are other methods. However, in the end there is no
single action that would completely protect of making a mistake.
Besides, warnings are non-normative and therefore are not consistent
from compiler to compiler or even from one version of the same compiler
to another.

That said, a random value is worse than a known one. It can lead to
unpredictable behavior of the program. Repeatability, even if the
actions of the program are incorrect, helps tremendously in fixing the bugs.

V

 

[Stefan Ram]

That said, a random value is worse than a known one.

n3290 does not call it »random«:

»if no initialization is performed, an object with automatic
or dynamic storage duration has indeterminate value.«

 

[Öö Tiib]

n3290 does not call it »random«:

»if no initialization is performed, an object with automatic
or dynamic storage duration has indeterminate value.«

Victor's point still holds since random is just (more useful) subset
of indeterminate. So if random is worse than known then indeterminate
is even worse.

 

[Stefan Ram]

Victor's point still holds since random is just (more useful) subset
of indeterminate.

When someone says: »x e A« (»x is an element of A.«), and
the specs say: »x e B«, and »A c B« (»A is a subset of B«),
then »x e A« does /not/ follow from the specs (from »x e B«).
(It would follow if instead »B c A« would be true.)

Hey, we're on topic again, as the subject says: »subset«!

 

[David Brown]

Reliance on compiler warnings can only be done in conjunction with other
ways of ensuring correctness of the code. Code reviews and following
coding standards are other methods. However, in the end there is no
single action that would completely protect of making a mistake.
Besides, warnings are non-normative and therefore are not consistent
from compiler to compiler or even from one version of the same compiler
to another.

That's all true - compiler warnings are an aid to avoiding bugs, but
they certainly don't cover everything. However, appropriate use of
compiler warnings should be a normal part of your development
methodology. If you are using a compiler that does not have a
reasonable level of warnings, then it is a good idea to use an external
tool (a "lint" tool), or simply pass the same code though a compiler
that /is/ good at static error checking. Since gcc is a suitable
choice, and is free, there is no good excuse for not using it as a
minimum (llvm is an alternative).

The worst thing you can do is say that since your compiler is not
perfect at static error checking, you should ignore it!

That said, a random value is worse than a known one. It can lead to
unpredictable behavior of the program. Repeatability, even if the
actions of the program are incorrect, helps tremendously in fixing the
bugs.

In a case like this, the initial value is only ever used if there is a
bug in later code. Giving the variable an initial value hides the bug
from helpful tools, and it certainly does not remove the bug. It is a
far stretch to claim that it makes the bug less bad (by having a known
value rather than an indeterminate one) - the bug is there, and the
program will not work.