Creating pythagorean triples from input.

[Jason Heyes]

#include <iostream>

class triple {
private:
// representation
unsigned int a, b;
public:
// constructors
triple(int x = 0, int y = 0): a(x), b(y) { }
// operators
triple& operator=(const triple& t) {
a = t.a; b = t.b;
return *this;
}
friend
std::istream& operator>>(std::istream& is, triple& t) {
int a = 0;
if (is >> a) {
int b = 0;
if (is >> b) {
t = triple(a, b);
}
}
return is;
}
friend
std:stream& operator<<(std:stream& os, const triple& t) {
return os << t.a << ' ' << t.b;
}
};

Thanks for the input.

 

[Jason Heyes]

Wrong? The best code is written when the requirements are the clearest.
You are trying to get people to both write the requirements and the code
to meet them. What is this, circus? If you want to learn to set program
or product requirements, this is not the right place. Try newsgroup
comp.software-eng. At this point you've been given relevant solutions,
go use them. Come back when you have some other _language_ problem.

If you want to see plenty of code, google for it. Many good products are
shipped in source code form. Read it, learn it. Have you tried books?
Many good books have source code in them, didn't you know? What about
magazines? C/C++ User's Journal, Dr.Dobbs Journal, to name a couple.
They are good source of decent code as well..

V

This is the last time I ask people to write code to requirements in this
forum. It just gets too personal.

 

[John Harrison]

Ok. The requirements say to write a function that reads pythagorean
triples. So the appropriate action when a pythagorean triple is not
specified in the input is to fail. Its just the same as when an integer
isn't specified in the input and operator>>(std::istream &, int &) fails.
Why is this not obvious? Here is how the function could be used in a
program:

PythagoreanTriple triple;
while (cin >> triple)
cout << "PythagoreanTriple <" << triple.a << ", " << triple.b << ", "
<< triple.c << ">" << endl;

Please don't regard this as an amendment to the original requirements
because it isn't. The original requirements are complete. Everything I've
said here is obvious.

It still doesn't seem tremendously difficult, making a few assumptions on
your still imperfectly specified problem

class PythagoreanTriple
{
public:
PythagoreanTriple(int a, int b, int c);
};

istream& operator>>(istream& in, PythagoreanTriple& t)
{
int a, b;
if (!(is >> a && is >> b))
return is;
double c = (int)sqrt((double)a*a + (double)b*b);
if (c != floor(c))
{
is.setstate(ios_base::fail);
return is;
}
t = PythagoreanTriple(a, b, (int)c);
return is;
}

It can definitely be improved in various ways, but its a start. Its also
untested.

john

 

[Karl Heinz Buchegger]

The "trivial" problem relates to a recurring problem in design and coding
that I currently experience. A few questions that arise are:

* How should I design the PythagoreanTriple class?
* Should I have a factory class for PythagoreanTriple?
* Is it the role of operator>> to verify its inputs?
* Should PythagoreanTripleFactory::create be written so that it returns
boolean?

These are questions I could answer with some good code - if only I had some.

The first 2 and your last point have nothing to do with what you asked.
Point 3 is actually a good point.
But:
1) you didn't raise that question in your posting at all.
2) sure it should verify its input. The interesting part however
is: How to react in case of invalid input?
But this question wasn't asked either.

As it turns out, your question is *not* about pythagorean triples. You
would have the very same problems when needing to read any other input,
eg. such as a date, from a formatted text stream.

Maybe you should rephrase your question?

 

[Karl Heinz Buchegger]

The task has nothing to do with syntax parsing. This should have been made
clearer in the requirements.

Your requirements talk about:
'an example is <3,4,5>'
So I take it for granted that your input equals "<3,4,5>"
Reading that is definitly parsing.

Input := "<" number "," number "," number ">" .

If this is not what you want or where your problem is, then please
be specific. Every regular in this newsgroup knows what you mean
with 'ppythagorean triplet'. You don't need to talk at length about
this topic when at the same time you don't even tell us what your
real problem is.

As for my exact problem there are several
aspects of design and coding that aren't working for me. These will become
clearer as I see more and more code. The problem isn't easy to explain.
Please don't make me try.

If you cannot express your problem, how should we know what to
answer to help you.

Doing things this way is much easier, I believe.

Not really. Easier for you. But definitly not for us. We have
to use our crystal balls to guess your question. The performance
of your question up to now, should already have told you that.

 

[Karl Heinz Buchegger]

Ok. The requirements say to write a function that reads pythagorean triples.
So the appropriate action when a pythagorean triple is not specified in the
input is to fail. Its just the same as when an integer isn't specified in
the input and operator>>(std::istream &, int &) fails. Why is this not
obvious?

You are funny, you know?

You start a thread which asks us to write code for something that looks
a lot like homework. Only after several answers it turns out that your
real problem is located in a very different section:

How to proceed if an input operator detects invalid input.

With no word have you addressed your real problem in the original
posting. You could eg. have asked

How do I proceed in in stream input operator if I detect an invalid
input? I know that eg reading an int may fail. How do I do the same
for my class? How do I force the stream to an invalid state? Or
are there better ways? What about throwing an exception?
Any thoughts welcome.

Instead you teach us a lot about phtagorean triplets which are really
unimportant to your real question. You would the very same problem
when you read eg. a date and get 30-feb-2004 as input.

To summarize: You don't ask the question you should ask but complain
that nobody is going to answer the question you didn't ask.

Here is how the function could be used in a program:

PythagoreanTriple triple;
while (cin >> triple)
cout << "PythagoreanTriple <" << triple.a << ", " << triple.b << ", " <<
triple.c << ">" << endl;

Please don't regard this as an amendment to the original requirements
because it isn't. The original requirements are complete. Everything I've
said here is obvious.

In your mind only.
Dream on.

Good luck to you.

 

[Jason Heyes]

It still doesn't seem tremendously difficult, making a few assumptions on
your still imperfectly specified problem

class PythagoreanTriple
{
public:
PythagoreanTriple(int a, int b, int c);
};

istream& operator>>(istream& in, PythagoreanTriple& t)
{
int a, b;
if (!(is >> a && is >> b))
return is;
double c = (int)sqrt((double)a*a + (double)b*b);
if (c != floor(c))
{
is.setstate(ios_base::fail);
return is;
}
t = PythagoreanTriple(a, b, (int)c);
return is;
}

It can definitely be improved in various ways, but its a start. Its also
untested.

john

This code achieves almost all of the required functionality so thats great.
As an improvement I would suggest adding tests for integers a and b so that
<-3,-4,5> is not mistaken for a pythagorean triple. But thats a minor issue.
Well done.

 

[John Harrison]

This code achieves almost all of the required functionality so thats
great. As an improvement I would suggest adding tests for integers a and b
so that <-3,-4,5> is not mistaken for a pythagorean triple. But thats a
minor issue. Well done.

Well gee, thank you very much.

I would be worried about the overflow that could occur when converting from
a double to an int.

You could consider using unsigned int instead of int if you don't
consider -3, -4 and 5 a Pythagorean triple.

john

 

[Michiel Salters]

The "trivial" problem relates to a recurring problem in design and coding
that I currently experience. A few questions that arise are:

* How should I design the PythagoreanTriple class?
* Should I have a factory class for PythagoreanTriple?
* Is it the role of operator>> to verify its inputs?
* Should PythagoreanTripleFactory::create be written so that it returns
boolean?

These are questions I could answer with some good code - if only I had some.

Well, we could write code. But if that's what you want to know, why
didn't you ask for these specific points? It's a lot easier to answer
these questions. No need to write code.

* How should I design the PythagoreanTriple class?

Why do you think you need such a class? The basic requirement is a function
f: int x int -> int
C++ is not Java: when you want a function, write a function.

* Should I have a factory class for PythagoreanTriple?

No class = no factory

* Is it the role of operator>> to verify its inputs?

Usually yes. Some errors might be caught by the class ctor or assignment,
but in general operator>> has to extract a number of fields from the
stream and then buid a class from those fields. If one of these fields
is missing or malformed, you cannot proceed. That means operator>> is
the only function capable of flagging that error.

* Should PythagoreanTripleFactory::create be written so that it returns
boolean?

No. What would it return? Success or failure? That is better communicated
using exceptions. A Factory::create() should return the created object.

Regards,
Michiel Salters

 

[velthuijsen]

* How should I design the PythagoreanTriple class?

The way you'd design any other class. Try to write up what it needs to
do, try to figure out what it needs for input to do whatever you want
it to do.

* Should I have a factory class for PythagoreanTriple?

That is a design choice and it seems you've already made it seeing
your question 4.

* Is it the role of operator>> to verify its inputs?

Depends. This is one of those things you need to figure out as said in
the first point.

* Should PythagoreanTripleFactory::create be written so that it returns boolean?

Depends again on your needs.

These are questions I could answer with some good code - if only I had some.

Then write some. It would probably have cost you less time to write
something that works then that you've spend composing messages here
and replying to people that say do it yourself.
If you do make that class you can check it to your needs, does it
satisfy them all? If so you got a keeper, now go and make it
efficient.

 

[Jason Heyes]

You are funny, you know?

You start a thread which asks us to write code for something that looks
a lot like homework. Only after several answers it turns out that your
real problem is located in a very different section:

How to proceed if an input operator detects invalid input.

With no word have you addressed your real problem in the original
posting. You could eg. have asked

How do I proceed in in stream input operator if I detect an invalid
input? I know that eg reading an int may fail. How do I do the same
for my class? How do I force the stream to an invalid state? Or
are there better ways? What about throwing an exception?
Any thoughts welcome.

Instead you teach us a lot about phtagorean triplets which are really
unimportant to your real question. You would the very same problem
when you read eg. a date and get 30-feb-2004 as input.

To summarize: You don't ask the question you should ask but complain
that nobody is going to answer the question you didn't ask.

I didn't ask the question you wanted me to ask. This is why you repeatedly
probe me about my "real" problem. My "real" problem has always been to write
good code that achieves the required functionality. But you don't want to
help me do that. You would rather discuss specific problems whose solutions
are known to you.

The truth is that I don't know what my problem boils down to. So when you
ask for the real problem, all I can do is point back to the requirements.
This is done so that you may help me discover the real problem. When the
real problem is found, the solutions are obvious. Understand now?

 

[Jason Heyes]

Well gee, thank you very much.

I would be worried about the overflow that could occur when converting
from a double to an int.

You could consider using unsigned int instead of int if you don't
consider -3, -4 and 5 a Pythagorean triple.

john

The components of a pythagorean triple must be positive. This is why tests
for a and b are necessary. Even if you use unsigned int, tests for a and b
are still necessary. You don't want <0,0,0> to count as a pythagorean
triple.

The requirements don't talk about numerical issues. Take this as permission
to ignore overflow.

 

[Jason Heyes]

Your requirements talk about:
'an example is <3,4,5>'
So I take it for granted that your input equals "<3,4,5>"
Reading that is definitly parsing.

Input := "<" number "," number "," number ">" .

If this is not what you want or where your problem is, then please
be specific. Every regular in this newsgroup knows what you mean
with 'ppythagorean triplet'. You don't need to talk at length about
this topic when at the same time you don't even tell us what your
real problem is.


If you cannot express your problem, how should we know what to
answer to help you.


Not really. Easier for you. But definitly not for us. We have
to use our crystal balls to guess your question. The performance
of your question up to now, should already have told you that.

That assumes everyone who answers questions in this forum is perfect.

 

[Howard]

This is the last time I ask people to write code to requirements in this
forum.

I think I speak for everyone here when I say: GOOD!

-Howard

 

[Victor Bazarov]

I think I speak for everyone here when I say: GOOD!

Amen!

 

[John Harrison]

The components of a pythagorean triple must be positive. This is why tests
for a and b are necessary. Even if you use unsigned int, tests for a and b
are still necessary. You don't want <0,0,0> to count as a pythagorean
triple.

The requirements don't talk about numerical issues. Take this as
permission to ignore overflow.

OK, use regular ints then would be my advice. I don't like unsigned types.

john

 

[Arijit]

Amen!

The more I read this thread, the more it appears it was a troll. And
from the amount of replies and flames it generated, looks like a heck of
a brilliant one.

-Arijit

 

[Jason Heyes]

OK, use regular ints then would be my advice. I don't like unsigned types.

john

LOL me neither.

 

[Richard Herring]

#include <iostream>

class triple {
private:
// representation
unsigned int a, b;
public:
// constructors
triple(int x = 0, int y = 0): a(x), b(y) { }
// operators
triple& operator=(const triple& t) {
a = t.a; b = t.b;
return *this;
}

Why write an assignment operator when the compiler will do it for you?