Printable View
I am working on a c++ book and currently writing a program to solve complex numbers.The problem i have is that i have to read in a string and tokenize it and parse it to set the real and imaginary part of a complex number.I am thinking of tokenizing based on space but i dont think thats a good idea.
Read up on stringstreams. (That would provide a solution independent of whitespace)
First, extract a double from the stream. (Assign it to the real part.)
Extract a character. (and store 1 or -1 in the imaginary part depending on it.)
Extract another character and discard it.
Finally extract a double and multiply it to the imaginary part.
Then post your code here if you want further help.
A complex number can either be something like:
(1.2, 3.4)
or just
1.2
So you need to read a char and see if it's a '('. If it isn't, unget the char and read a double into the real part and set the imaginary part to 0.0. If the initial char is a '(', then read a double into the real part, read another char (it should be a comma), then read the next double into the imaginary part, then read another char (it should be a ')' ).
What if i have a string like this " 2.1 +4.1i20i".Would i need to check to see if the string is a valid complex numberQuote:
Originally Posted by manasij7479
You could.
For example, in your example; you can check if the second character you extracted is not 'i' or 'j'. That would catch the wrong format as it would read '4' there.
The second one is not worth checking (though you can easily, by seeing if you're at the end of the stream).
i am sorry,I do not get what you meant by saying in the bolded part aboveQuote:
Originally Posted by manasij7479
Consider: a+ib ..where a and b are doubles.Quote:
Originally Posted by sigur47
After getting the sign (here '+'), you have to extract another character from the stream to reach the b part.
If the extracted character isn't i or j, the format of the complex number isn't valid.
my question is if the format of the complex number is not valid,should i adapt my parser to get the best out of the solutionQuote:
Originally Posted by manasij7479
Nope.
Parsing is by its nature a matter of including certain bits and excluding others.
If the input isn't valid you can explain why it isn't valid (say via error message), but trying to adapt your parser to guess at any input and still behave properly is a game that can't be won.
Soma
A paragraph from The Art of UNIX Programming:Quote:
Originally Posted by sigur47
Quote:
Rule of Repair: Repair what you can — but when you must fail, fail noisily and as soon as possible.
Software should be transparent in the way that it fails, as well as in normal operation. It's best when software can cope with unexpected conditions by adapting to them, but the worst kinds of bugs are those in which the repair doesn't succeed and the problem quietly causes corruption that doesn't show up until much later.
Therefore, write your software to cope with incorrect inputs and its own execution errors as gracefully as possible. But when it cannot, make it fail in a way that makes diagnosis of the problem as easy as possible.
Consider also Postel's Prescription:[10] “Be liberal in what you accept, and conservative in what you send”. Postel was speaking of network service programs, but the underlying idea is more general. Well-designed programs cooperate with other programs by making as much sense as they can from ill-formed inputs; they either fail noisily or pass strictly clean and correct data to the next program in the chain.
However, heed also this warning:
The original HTML documents recommended “be generous in what you accept”, and it has bedeviled us ever since because each browser accepts a different superset of the specifications. It is the specifications that should be generous, not their interpretation. -- Doug McIlroy
McIlroy adjures us to design for generosity rather than compensating for inadequate standards with permissive implementations. Otherwise, as he rightly points out, it's all too easy to end up in tag soup.