How to convert Infix notation to postfix notation
Tameem
how can i convert it to postfix form using C language,,,????
spinoza1111
> i have a string as (a+b)+8-(c/d) in Infix form.
>
> how can i convert it to postfix form using C language,,,????
I will assume that that string is not the ONLY string you have to
convert. If it is, then the answer is
int main()
{
printf("ab+8+cd/-\n");
}
Each one of the following productions should be written as a separate
C function.
expression -> additionFactor [ "+"|"-" expression ]
additionFactor -> multiplicationFactor [ "*"|"/" expression ]
multiplicationFactor -> term
term -> LETTER | NUMBER | "(" expression ")" // Rightmost must balance
Write code using the above "productions" that emits postfix code. For
each production write one C function. I won't write C for you because
I don't like C, I suck at it through disuse consequent on my dislike,
and it's your homework assignment, not mine.
"->" means "consists of the following material left to right"
"|" means "or"
Lower case and camelCase words are grammar categories that will
correspond to procedures in YOUR code
Upper case words are lexemes recognised by C code
Quoted material occurs as is.
Material in square brackets is optional. An expression could be just
an additionFactor. In turn an additionFactor can be just a
multiplicationFactor and a multiplication factor a number. Therefore,
"3" is an expression.
When you parse a "term" as "(" expression ")" you must look ahead in
the overall algorithm I shall give you to find, not the first right
parenthesis, but the one that actually balances the left parenthesis.
To do this, maintain a counter. Increment it by one for each left
parenthesis the lookahead sees: decrement it by one for each right
parenthesis. When you see right parenthesis and the counter goes to
zero, you have found the right parenthesis.
OK, here's the untested and uncompiled C Sharp like pseudo code for
"expression": convert it to C:
string expressionMain(string strInstring)
{
int intIndex1 = 0;
string strPolish = "";
return expression(strInstring, ref intIndex1, ref strPolish);
}
string expression(string strInstring, ref int intIndex1, ref string
strPolish)
{
if (!additionFactor(string strInstring,
ref intIndex1,
ref strPolish)) return "Not valid";
if (strInstring[intIndex]=='+' || strInstring[intIndex]=='-')
{
int intIndexSave = intIndex1; intIndex1++;
if (expression(strInstring, ref intIndex1, ref strPolish))
strPolish += strInstring[intIndexSave];
else return("Not valid");
}
return strPolish;
}
C Sharp idioms: ref followed by type in a formal parameter list in a
function decl is like using asterisk in front of a parameter in C. It
means that the parameter is passed by reference. In C Sharp, a very
cool language, you must ALWAYS use the keyword ref in the "actual
parameters" passed when you call the function just so you know what
the hell you are doing, as opposed to C which likes to fool you.
Chapter 3 of my book Build Your Own .Net and Compiler (Edward G.
Nilges, Apress May 2004) provides a complete solution for this
homework but in Visual Basic .Net. Therefore this is not a commercial
promotion. If you find my book useful, buy it, check it out of the
library, or steal it.
Michael Schumacher
> i have a string as (a+b)+8-(c/d) in Infix form.
>
> how can i convert it to postfix form using C language,,,????
This has very little to do with the /language/ C, i.e., there's
no "built-in" way to accomplish this conversion. However, it's
of course possible to implement such a converter in C, e.g., by
writing a recursive-descent parser (for a good deal of details,
see <http://en.wikipedia.org/wiki/Operator-precedence_parser>).
You might also want to take a look at the GNU assembler (gas,
which is part of the GNU binutils package), which implements
such a recursive-descent parser to evaluate constant expressions.
mike
Gene
> i have a string as (a+b)+8-(c/d) in Infix form.
>
> how can i convert it to postfix form using C language,,,????
It this homework?
Ben Bacarisse
> On Oct 26, 12:33 pm, Tameem <etam...@gmail.com> wrote:
>> i have a string as (a+b)+8-(c/d) in Infix form.
>>
>> how can i convert it to postfix form using C language,,,????
>
> I will assume that that string is not the ONLY string you have to
> convert. If it is, then the answer is
>
> int main()
> {
> printf("ab+8+cd/-\n");
> }
>
> Each one of the following productions should be written as a separate
> C function.
>
> expression -> additionFactor [ "+"|"-" expression ]
> additionFactor -> multiplicationFactor [ "*"|"/" expression ]
> multiplicationFactor -> term
> term -> LETTER | NUMBER | "(" expression ")" // Rightmost must balance
This is not the usual grammar for expressions and is poor advice for
someone learning this stuff.
> Write code using the above "productions" that emits postfix code.
To the OP: please don't; Spinoza1111 is leading you astray. Post in a
group about programming (comp.programming is a good one) for better
advice on how to go about this. Also, if this is homework/coursework,
be open about that and explain how far you have been able to get on
your own.
<snip off-topic C#>
--
Ben.
spinoza1111
> spinoza1111<spinoza1...@yahoo.com> writes:
> > On Oct 26, 12:33 pm, Tameem <etam...@gmail.com> wrote:
> >> i have a string as (a+b)+8-(c/d) in Infix form.
>
> >> how can i convert it to postfix form using C language,,,????
>
> > I will assume that that string is not the ONLY string you have to
> > convert. If it is, then the answer is
>
> > int main()
> > {
> > printf("ab+8+cd/-\n");
> > }
>
> > Each one of the following productions should be written as a separate
> > C function.
>
> > expression -> additionFactor [ "+"|"-" expression ]
> > additionFactor -> multiplicationFactor [ "*"|"/" expression ]
> > multiplicationFactor -> term
> > term -> LETTER | NUMBER | "(" expression ")" // Rightmost must balance
>
> This is not the usual grammar for expressions and is poor advice for
> someone learning this stuff.
>
> > Write code using the above "productions" that emits postfix code.
>
Ben, please indicate the errors and don't imitate Seebach by
discussing personalities instead of ideas. As it is, you sound like a
fundamentalist *imam*.
> group about programming (comp.programming is a good one) for better
> advice on how to go about this. Also, if this is homework/coursework,
> be open about that and explain how far you have been able to get on
> your own.
>
> <snip off-topic C#>
> --
> Ben.- Hide quoted text -
>
> - Show quoted text -
spinoza1111
> > On Oct 26, 12:33 pm, Tameem <etam...@gmail.com> wrote:
> >> i have a string as (a+b)+8-(c/d) in Infix form.
>
> >> how can i convert it to postfix form using C language,,,????
>
> > I will assume that that string is not the ONLY string you have to
> > convert. If it is, then the answer is
>
> > int main()
> > {
> > printf("ab+8+cd/-\n");
> > }
>
> > Each one of the following productions should be written as a separate
> > C function.
>
> > expression -> additionFactor [ "+"|"-" expression ]
> > additionFactor -> multiplicationFactor [ "*"|"/" expression ]
> > multiplicationFactor -> term
> > term -> LETTER | NUMBER | "(" expression ")" // Rightmost must balance
>
> This is not the usual grammar for expressions and is poor advice for
> someone learning this stuff.
>
> > Write code using the above "productions" that emits postfix code.
>
I would have thought given your technical capabilities that you would
be able, instead of engaging in Fox news style politics of personal
destruction, to identify all flaws in my approach, whether in the
formal grammar of C# pseudo code.
If you cannot, I need an apology from you. NOW, punk.
> group about programming (comp.programming is a good one) for better
> advice on how to go about this. Also, if this is homework/coursework,
> be open about that and explain how far you have been able to get on
> your own.
>
> <snip off-topic C#>
C# is what C should be. As I indicated, C Sharp was used as pseudocode
because it is probably a homework assignment and the OP needs to do
this homework. The OP probably received poor algorithm guidance from
the teacher, especially if the teacher was like most people here.
Ben Bacarisse
> On Oct 26, 8:20 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>> spinoza1111<spinoza1...@yahoo.com> writes:
<snip>
>> > expression -> additionFactor [ "+"|"-" expression ]
>> > additionFactor -> multiplicationFactor [ "*"|"/" expression ]
>> > multiplicationFactor -> term
>> > term -> LETTER | NUMBER | "(" expression ")" // Rightmost must balance
>>
>> This is not the usual grammar for expressions and is poor advice for
>> someone learning this stuff.
>>
>> > Write code using the above "productions" that emits postfix code.
>>
>> To the OP: please don't;Spinoza1111is leading you astray. Post in a
[The formatting errors in the above were added by you. My typing is
bad, but not /that/ bad.]
> I would have thought given your technical capabilities that you would
> be able, instead of engaging in Fox news style politics of personal
> destruction, to identify all flaws in my approach, whether in the
> formal grammar of C# pseudo code.
It's not topical here. There must be lots of groups where you can get
advice on writing a grammar for simple expressions, but I don't know,
off hand, where would be the best place. I suggested comp.programming
to the OP, but that is probably not the best place for your question.
> If you cannot, I need an apology from you. NOW, punk.
That's OK then.
<snip>
--
Ben.
spinoza1111
> spinoza1111<spinoza1...@yahoo.com> writes:
> > On Oct 26, 8:20 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> >>spinoza1111<spinoza1...@yahoo.com> writes:
> <snip>
> >> > expression -> additionFactor [ "+"|"-" expression ]
> >> > additionFactor -> multiplicationFactor [ "*"|"/" expression ]
> >> > multiplicationFactor -> term
> >> > term -> LETTER | NUMBER | "(" expression ")" // Rightmost must balance
>
> >> This is not the usual grammar for expressions and is poor advice for
> >> someone learning this stuff.
You have not shown that it is INCORRECT. It's possible that the
"usual" grammar is incorrect (as in the case of left recursion) given
Gresham's Law that 99% of everything is crap. You need to show that
the grammar is either actually incorrect or not suitable for manual
interpretation, and I do not, personally think you qualified to do so.
This takes experience in writing an actual parser by hand.
In the first production it is obvious that on return from
additionFactor(), the parser can advance the index, and check it for
greater than end. If the index is past the end, we're done. If it is
not, the parser can check either for a plus or a minus.
If either character occurs the parser then calls itself with a source
string that is necessarily smaller guaranteeing the safety of the
recursion. But, there must be an expression when there is an operator.
Disprove this informal logic and desist the Fox news crap, please.
>
> >> > Write code using the above "productions" that emits postfix code.
>
> >> To the OP: please don't;Spinoza1111is leading you astray. Post in a
>
> [The formatting errors in the above were added by you. My typing is
> bad, but not /that/ bad.]
>
> > I would have thought given your technical capabilities that you would
> > be able, instead of engaging in Fox news style politics of personal
> > destruction, to identify all flaws in my approach, whether in the
> > formal grammar of C# pseudo code.
>
> It's not topical here. There must be lots of groups where you can get
> advice on writing a grammar for simple expressions, but I don't know,
> off hand, where would be the best place. I suggested comp.programming
> to the OP, but that is probably not the best place for your question.
His goal is to write a C program, but we don't want to give him the
homework solution. It appears that his instructor in fact knows about
as much as you about writing a recursive descent parser by hand.
Therefore he's in the right place.
Ben Bacarisse
> On Oct 27, 11:15 am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>> spinoza1111<spinoza1...@yahoo.com> writes:
>> > On Oct 26, 8:20 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>> >>spinoza1111<spinoza1...@yahoo.com> writes:
>> <snip>
>> >> > expression -> additionFactor [ "+"|"-" expression ]
>> >> > additionFactor -> multiplicationFactor [ "*"|"/" expression ]
>> >> > multiplicationFactor -> term
>> >> > term -> LETTER | NUMBER | "(" expression ")" // Rightmost must balance
>>
>> >> This is not the usual grammar for expressions and is poor advice for
>> >> someone learning this stuff.
>
> You have not shown that it is INCORRECT.
No, and I never said it was. You know where to post if you really
don't know what is wrong with it. I don't want to be drawn further
into an off topic discussion of grammars here. Only in a suitable
group will you get the very best advice; and only there would any
criticism be properly checked. Send me an email (drop the ".usenet"
to get through faster) if you really can't bear to post in a suitable
group, but then neither of us will benefit from third party scrutiny.
Alternatively, feel free to have the last word by calling me
"unqualified" or a "faggot" again. I grew up gay being called a lot
worse than "unqualified".
<snip>
> You need to show that the grammar is either actually incorrect or
> not suitable for manual interpretation, and I do not, personally
> think you qualified to do so.
<snip>
--
Ben.
John Bode
> i have a string as (a+b)+8-(c/d) in Infix form.
>
> how can i convert it to postfix form using C language,,,????
As others have said, there's no C-specific way of doing this.
However, here are the general steps you'll need to take:
First, you will need to separate the string into distinct *tokens*.
In your example, you have four kinds of tokens -- operators
('+','-','*','/'), separators ('(',')'), constants ('8'), and
identifiers ('a','b','c','d'). Generally, you'll have a set of rules
that determines what characters make up a particular kind of token
(for example, an identifier must start with a letter and consist of
only letters and digits: "a1", "foo", "x", etc.). As you scan each
character, you'll check against the currently active rule and if it
matches, you'll add it to the token.
There are two ways to go on the next step. You can either build a
full-blown recursive descent parser (a decent explanation appears on
Wikipedia), or you can use a simple stack-based converter. For the
stack-based converter, as you read the expression, you'll pass
constants and identifiers straight to output, and you'll push and pop
operators on the stack based on their precedence. If the operator on
the top of the stack has a lower precedence than the current operator,
then push the current operator. If the operator on the stack has an
equal or higher precedence than the current operator, then pop the
operator off the stack and write it to output, then push the current
operator on the stack. lparens are always pushed onto the stack;
rparens cause everything on the stack to be popped to the next
lparen. Neither lparens nor rparens are written to output.
Given your example, the operations would look something like this:
1. Read '(', push it onto the stack. Stack contents = {'('}
2. Read 'a', write it to output. Output string = "a"
3. Read '+', push it on the stack: {'(', '+'}
4. Read 'b', write it to output: "a b"
5. Read ')', pop everything off the stack to the next '(', but don't
write '(' to output. Output string is "a b +", stack contents = {}
6. Read '+', push it onto the stack: {'+'}
7. Read '8', write it to output: "a b + 8"
8. Read '-', has same precedence as '+', so pop '+' from stack, write
it to output, and push '-': "a b + 8 +", {'-'}
9. Read '(', push it onto the stack: {'-', '('}
10. Read 'c', write it to output: "a b + 8 + c"
11. Read '/', push onto stack: {'-', '(', '/'}
12. Read 'd', write to output: "a b + 8 + c d"
13. Read ')', pop everything to '(': "a b + 8 + c d /", {'-'}
14. End of string, pop remainder of stack: "a b + 8 + c d / -"
Kenny McCormack
spinoza1111 <spino...@yahoo.com> wrote:
...
>You have not shown that it is INCORRECT. It's possible that the
>"usual" grammar is incorrect (as in the case of left recursion) given
>Gresham's Law that 99% of everything is crap. You need to show that
Quibble. Sturgeon's law (although the story may be apocryphal and/or
tongue-in-cheek).
Gresham's law says that the bad drives out the good, which is, not
coincidentally, also very true and on display in comp.lang.c
spinoza1111
> On Oct 25, 11:33 pm, Tameem <etam...@gmail.com> wrote:
>
> > i have a string as (a+b)+8-(c/d) in Infix form.
>
> > how can i convert it to postfix form using C language,,,????
>
> As others have said, there's no C-specific way of doing this.
> However, here are the general steps you'll need to take:
>
> First, you will need to separate the string into distinct *tokens*.
> In your example, you have four kinds of tokens -- operators
> ('+','-','*','/'), separators ('(',')'), constants ('8'), and
> identifiers ('a','b','c','d'). Generally, you'll have a set of rules
> that determines what characters make up a particular kind of token
> (for example, an identifier must start with a letter and consist of
> only letters and digits: "a1", "foo", "x", etc.). As you scan each
> character, you'll check against the currently active rule and if it
> matches, you'll add it to the token.
Might be overkill given that the problem statement implies that
symbols are a letter, and scanning non-integer tokens might be beyond
the requirements of the problem...since the OP's teacher hasn't told
him what a number is, and a fully general number recognizer that
recognizes signs, exponents, and decimal points is a project in
itself. Therefore a number is probably an integer, and this can be
recognized by adhoc code. A separate pass for lexical analysis is
probably overkill.
>
> There are two ways to go on the next step. You can either build a
> full-blown recursive descent parser (a decent explanation appears on
> Wikipedia), or you can use a simple stack-based converter. For the
> stack-based converter, as you read the expression, you'll pass
> constants and identifiers straight to output, and you'll push and pop
> operators on the stack based on their precedence. If the operator on
> the top of the stack has a lower precedence than the current operator,
> then push the current operator. If the operator on the stack has an
> equal or higher precedence than the current operator, then pop the
> operator off the stack and write it to output, then push the current
> operator on the stack. lparens are always pushed onto the stack;
> rparens cause everything on the stack to be popped to the next
> lparen. Neither lparens nor rparens are written to output.
Very nice and correct, perhaps clearer than a grammar based solution,
with the caveats that when the top of the stack is an LP, anything
other than RP must be stacked and RP is an error. Also may not catch
some errors.
spinoza1111
> spinoza1111<spinoza1...@yahoo.com> writes:
> > On Oct 27, 11:15 am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> >>spinoza1111<spinoza1...@yahoo.com> writes:
> >> > On Oct 26, 8:20 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> >> >>spinoza1111<spinoza1...@yahoo.com> writes:
> >> <snip>
> >> >> > expression -> additionFactor [ "+"|"-" expression ]
> >> >> > additionFactor -> multiplicationFactor [ "*"|"/" expression ]
> >> >> > multiplicationFactor -> term
> >> >> > term -> LETTER | NUMBER | "(" expression ")" // Rightmost must balance
>
> >> >> This is not the usual grammar for expressions and is poor advice for
> >> >> someone learning this stuff.
>
> > You have not shown that it is INCORRECT.
>
> No, and I never said it was. You know where to post if you really
> don't know what is wrong with it. I don't want to be drawn further
> into an off topic discussion of grammars here. Only in a suitable
> group will you get the very best advice; and only there would any
> criticism be properly checked. Send me an email (drop the ".usenet"
> to get through faster) if you really can't bear to post in a suitable
> group, but then neither of us will benefit from third party scrutiny.
>
> Alternatively, feel free to have the last word by calling me
> "unqualified" or a "faggot" again. I grew up gay being called a lot
> worse than "unqualified".
Give me a break. What part of hyperbole don't you faggots understand?
Furthermore, any claims you might have had to being treated in a
politically correct fashion were made moot when you started to join
electronic mobs and to propagate lies about individuals here. Frankly,
I do not understand groups who form identities as "oppressed" and
their claims to be spoken about in a civil fashion when they do not
extend this civility towards others or their own members.
According to some of my sources, systematic "trashing" of targeted
individuals began in the women's movement as the complement to women's
demands to be spoken of in a new language cleansed of "honey" and
"babe". It was directed at women inside the movement. Likewise, Larry
Kramer, a gay man, has spoken of the way in which gay people demand
kid glove treatment and cleansed language from straights...while
trashing each other and infecting each other with AIDs.
Groups demand charity that is denied, that they deny, to individuals.
spinoza1111
Ben Bacarisse noticed that I used the wrong grammar and informed me by
email in a very professional way. The grammar should be the following
for direct conversion to code!!
expression → additionFactor [ "+"|"-" additionFactor ] *
additionFactor → multiplicationFactor [ "*"|"/" multiplicationFactor ]
*
multiplicationFactor → LETTER | NUMBER | "(" expression ")"
That is, an expression is a series of one or more additionFactors.
When there are at least two, they are separated by plus or minus. The
replacement of the right recursive call to expression by the iteration
over additionFactor (the asterisk expressing iteration) causes the
addition/subtraction to left associate naturally. Likewise for the
call to expression in the second production.
I also made this same error when developing the code for Build Your
Own .Net Language and Compiler but did not have Ben Bacarisse's expert
assistance. Instead, I discovered it in testing the code for the first
toy compiler in ch 3 and mention the problem, and its solution, in my
book. I was too lazy when posting to check my own goddamn book and
shall try to be more diligent in the future. However, such diligence
shall be pearls before swine in some cases and in others the exception
that proves the rule.
When I make an error I make each error twice, it seems to give the old
brain extra time to relearn things it learned in the past; in the past
week I have made the comma-as-operator-versus-separator as well as
this error twice. I do regret if the original post was useless to the
original poster, because as Ben pointed out, it right-associative.
But (big but): my post was of far greater quality, errors and all,
that the uncollegial crap which constitutes 99% of the postings here.
As was Ben's correction. This dialogue is what this facility should be
all the time, not denials that something is true unaccompanied by
information as to what is, and the politics of personal destruction.
Because of this, no response to this thread by Richard Heathfield will
be either read by me nor responded to by me.
Ben: thanks for your assistance and the very professional manner in
which you made it. If there are other errors please let me know.
Likewise for all other readers, except Richard Heathfield. I do not
think he's qualified to discuss this issue.
Richard Heathfield
spinoza1111 wrote:
<snip>
> When I make an error I make each error twice,
If only that were true.
<snip>
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within
spinoza1111
>
> - Show quoted text -
Here is a C Sharp implementation of recursive descent to translate
infix to Polish notation. It runs as a command line program. If an
infix expression is entered in its command line, this expression is
converted to Polish notation and the result is displayed.
If the command line contains no operands, a test suite is run. It
should produce this output:
Expect "2 4 3 + /": "2 4 3 + /"
Expect "2 4 / 3 +": "2 4 / 3 +"
Expect "2 4 3 + /": "2 4 3 + /"
Expect "10 113 2 2 4 3 + / + 2 + 2 + - + a *": "10 113 2 2 4 3 + / + 2
+ 2 + - + a *"
Expect error: "Error detected at or near character 3 in "11+":
Addition or subtraction operator is not followed by addFactor"
Expect error: "Error detected at or near character 2 in "11 +":
Expected addition or subtraction operator not found"
Expect "10 113 + a *": "10 113 + a *"
Expect "10 113 + a *": "10 113 + a *"
Expect "1": "1"
Expect "a b + c -": "a b + c -"
Expect "1 1 +": "1 1 +"
Here is the code. It should constitute the complete Program.CS file in
a .Net C Sharp command line mode application. It was tested under .Net
C Sharp Express, a free product available from Microsoft. Comments are
welcome.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace infix2Polish
{
class Program
{
static void Main(string[] strArgs)
{
if (strArgs.GetUpperBound(0) < 0)
Console.WriteLine(tester());
else
Console.WriteLine(infix2Polish(strArgs[0]));
return;
}
private static string tester()
{
return "Expect \"2 4 3 + /\": \"" +
infix2Polish("2/(4+3)") + "\"" +
Environment.NewLine +
"Expect \"2 4 / 3 +\": \"" +
infix2Polish("2/4+3") + "\"" +
Environment.NewLine +
"Expect \"2 4 3 + /\": \"" +
infix2Polish("((2/(4+3)))") + "\"" +
Environment.NewLine +
"Expect " +
"\"10 113 2 2 4 3 + / + 2 + 2 " +
"+ - + a *\": \"" +
infix2Polish
("((10+(113-(2+((((((2/(4+3)))))))+2+2))))*a") +
"\"" +
Environment.NewLine +
"Expect error: \"" +
infix2Polish("11+") + "\"" +
Environment.NewLine +
"Expect error: \"" +
infix2Polish("11 +") + "\"" +
Environment.NewLine +
"Expect \"10 113 + a *\": \"" +
infix2Polish("(10+113)*a") + "\"" +
Environment.NewLine +
"Expect \"10 113 + a *\": \"" +
infix2Polish("((10+113))*a") + "\"" +
Environment.NewLine +
"Expect \"1\": \"" +
infix2Polish("1") + "\"" +
Environment.NewLine +
"Expect \"a b + c -\": \"" +
infix2Polish("a+b-c") + "\"" +
Environment.NewLine +
"Expect \"1 1 +\": \"" +
infix2Polish("1+1") + "\"" +
Environment.NewLine;
}
private static string infix2Polish(string strInfix)
{
string strPolish = "";
int intIndex1 = 0;
string strErrorMessage = "";
if (!expression(strInfix,
ref strPolish,
ref intIndex1,
ref strErrorMessage))
return strErrorMessage;
return strPolish.Trim();
}
private static bool expression
(string strInfix,
ref string strPolish,
ref int intIndex,
ref string strErrorMessage)
{
return expression(strInfix,
ref strPolish,
ref intIndex,
ref strErrorMessage,
strInfix.Length - 1);
}
private static bool expression
(string strInfix,
ref string strPolish,
ref int intIndex,
ref string strErrorMessage,
int intEnd)
{// expression -> addFactor [ +|- addFactor ] *
if (!addFactor(strInfix,
ref strPolish,
ref intIndex,
ref strErrorMessage,
intEnd))
return errorHandler
(strInfix,
intIndex,
ref strErrorMessage,
"Expression doesn't start with " +
"addFactor");
char chrAddOp = ' ';
while (intIndex <= intEnd)
{
if ((chrAddOp = strInfix[intIndex]) != '+'
&&
chrAddOp != '-')
return errorHandler
(strInfix,
intIndex,
ref strErrorMessage,
"Expected addition or subtraction " +
"operator not found");
intIndex++;
if (intIndex > intEnd
||
!addFactor(strInfix,
ref strPolish,
ref intIndex,
ref strErrorMessage,
intEnd))
return errorHandler
(strInfix,
intIndex,
ref strErrorMessage,
"Addition or subtraction " +
"operator is not followed by " +
"addFactor");
strPolish += chrAddOp.ToString() + ' ';
}
return true;
}
private static bool addFactor
(string strInfix,
ref string strPolish,
ref int intIndex,
ref string strErrorMessage,
int intEnd)
{// addFactor -> mulFactor [ *|/ mulFactor ] *
if (!mulFactor(strInfix,
ref strPolish,
ref intIndex,
ref strErrorMessage,
intEnd))
return errorHandler
(strInfix,
intIndex,
ref strErrorMessage,
"Expected multiplication factor " +
"not found");
char chrMulOp = ' ';
while (intIndex <= intEnd
&&
((chrMulOp = strInfix[intIndex]) == '*'
||
chrMulOp == '/'))
{
intIndex++;
if (intIndex > intEnd
||
!mulFactor(strInfix,
ref strPolish,
ref intIndex,
ref strErrorMessage,
intEnd))
return errorHandler
(strInfix,
intIndex,
ref strErrorMessage,
"Expected multiplication factor " +
"not found");
strPolish += chrMulOp.ToString() + ' ';
}
return true;
}
private static bool mulFactor
(string strInfix,
ref string strPolish,
ref int intIndex,
ref string strErrorMessage,
int intEnd)
{// mulFactor -> LETTER|NUMBER|"(" expression ")"
if (strInfix[intIndex] >= 'a'
&&
strInfix[intIndex] <= 'z')
{
strPolish += strInfix[intIndex++].ToString() +
' ';
return true;
}
int intIndex1 = intIndex;
while(intIndex <= intEnd
&&
(strInfix[intIndex] >= '0'
&&
strInfix[intIndex] <= '9'))
strPolish += strInfix[intIndex++];
if (intIndex > intIndex1)
{
strPolish += ' ';
return true;
}
if (strInfix[intIndex] == '(')
{
intIndex++;
int intLevel = 1;
int intIndexAhead = 0;
for (intIndexAhead = intIndex;
intIndexAhead <= intEnd;
intIndexAhead++)
{
switch (strInfix[intIndexAhead])
{
case '(':
{
intLevel++; break;
}
case ')':
{
intLevel--;
if (intLevel == 0) goto exit;
break;
}
default: break;
}
}
exit:
if (!expression(strInfix,
ref strPolish,
ref intIndex,
ref strErrorMessage,
intIndexAhead - 1))
return errorHandler
(strInfix,
intIndex,
ref strErrorMessage,
"Nested expression invalid");
intIndex++;
}
return true;
}
private static bool errorHandler
(string strInfix,
int intIndex,
ref string strBase,
string strMessage)
{
strBase +=
(strBase == "" ? "" : "; ") +
"Error detected at or near " +
"character " +
intIndex.ToString() + " " +
"in " + "\"" + strInfix + "\": " +
strMessage;
return false;
}
}
}
Richard Heathfield
<8fb20e6c-b3cf-4af1...@a39g2000pre.googlegroups.com>,
spinoza1111 wrote:
<150 lines of quoted but unaddressed text snipped>
> Here is a C Sharp implementation of recursive descent to translate
> infix to Polish notation.
The microsoft.public.dotnet.languages.csharp newsgroup exists for C#
discussions; posting your code there will give you the best chance of
getting informed reviews of that code.
<290 lines of off-topic material snipped>
spinoza1111
> In
> <8fb20e6c-b3cf-4af1-87e1-7c5597145...@a39g2000pre.googlegroups.com>,
>
> spinoza1111wrote:
>
> <150 lines of quoted but unaddressed text snipped>
>
> > Here is a C Sharp implementation of recursive descent to translate
> > infix to Polish notation.
>
> The microsoft.public.dotnet.languages.csharp newsgroup exists for C#
> discussions; posting your code there will give you the best chance of
> getting informed reviews of that code.
I published it here to show the OP that the grammar based approach
works, and give him "pseudo code" for his C assignment, without doing
his homework for him.
Since by now he's probably handed in his assignment, I challenge you
to translate the C Sharp code to C. Should be easy since you're such a
Studly Dudley C programmer. >
Richard Heathfield
<ae71bbc0-4a9e-46dd...@a37g2000prf.googlegroups.com>,
spinoza1111 wrote:
> On Nov 1, 12:06 am, Richard Heathfield <r...@see.sig.invalid> wrote:
>> In
>>
<8fb20e6c-b3cf-4af1-87e1-7c5597145...@a39g2000pre.googlegroups.com>,
>>
>> spinoza1111wrote:
>>
>> <150 lines of quoted but unaddressed text snipped>
>>
>> > Here is a C Sharp implementation of recursive descent to
>> > translate infix to Polish notation.
>>
>> The microsoft.public.dotnet.languages.csharp newsgroup exists for
>> C# discussions; posting your code there will give you the best
>> chance of getting informed reviews of that code.
>
> I published it here to show the OP that the grammar based approach
> works,
If the OP is wise, he will treat any of your code, in whatever
language, with a great deal of suspicion.
> and give him "pseudo code" for his C assignment, without
> doing his homework for him.
>
> Since by now he's probably handed in his assignment, I challenge you
> to translate the C Sharp code to C.
I see no value in reinventing that particular wheel. I already have
working recursive descent code. What would be the point in
translating yours? If it works (which I doubt), I gain nothing. If it
doesn't work, I gain less still.
<snip>
Ben Bacarisse
<snip>
> I published it here to show the OP that the grammar based approach
> works, and give him "pseudo code" for his C assignment, without doing
> his homework for him.
>
> Since by now he's probably handed in his assignment, I challenge you
> to translate the C Sharp code to C.
That would not be useful. Your code does not parse the language
defined by the grammar, and what it does do, it does in a rather
roundabout way.
<snip>
--
Ben.
spinoza1111
If you think the grammar is correct, say so clearly. You imply it but
are too graceless to say it. Now the issue is whether the code
supports the correct grammar correctly.
You present no evidence for the first claim. As to the second, it
means you've never seen this simple algorithm.
>
> <snip>
> --
> Ben.
spinoza1111
> In
>
> spinoza1111wrote:
> > On Nov 1, 12:06 am, Richard Heathfield <r...@see.sig.invalid> wrote:
> >> In
>
> <8fb20e6c-b3cf-4af1-87e1-7c5597145...@a39g2000pre.googlegroups.com>,
>
>
>
> >> spinoza1111wrote:
>
> >> <150 lines of quoted but unaddressed text snipped>
>
> >> > Here is a C Sharp implementation of recursive descent to
> >> > translate infix to Polish notation.
>
> >> The microsoft.public.dotnet.languages.csharp newsgroup exists for
> >> C# discussions; posting your code there will give you the best
> >> chance of getting informed reviews of that code.
>
> > I published it here to show the OP that the grammar based approach
> > works,
>
> If the OP is wise, he will treat any of your code, in whatever
> language, with a great deal of suspicion.
>
> > and give him "pseudo code" for his C assignment, without
> > doing his homework for him.
>
> > Since by now he's probably handed in his assignment, I challenge you
> > to translate the C Sharp code to C.
>
> I see no value in reinventing that particular wheel. I already have
> working recursive descent code. What would be the point in
Did you write it or did you steal it?
> translating yours? If it works (which I doubt), I gain nothing. If it
I need to see you actually write new C code. You have a big mouth when
it comes to putting down people but the only time when you put your
big mouth on the line (the Spark Notes test) you failed. I am giving
you another chance.
I wrote and debugged a recursive descent parser for my book. I wrote
it again here after correcting the grammar because I think it's
incumbent on each one of us to be able to orally present an algorithm,
and writing it anew and posting it for comments simulates this oral
presentation.
It also demonstrates that the material is sufficiently complex for
smart people to make stupid mistakes (Knuth has himself said he
consistently gets binary search wrong the first time), and that the
stupid people aren't the ones making the mistakes.
It's the people too ready to trash and if possible render unemployable
their fellow human beings (by creating a record here) while explaining
away their own mistakes as you explained away your failure to get a
decent grade on the Spark Notes test.
You are as such contemptible.
Seebs
> Did you write it or did you steal it?
Presumably wrote it. I mean, come on. A parser is NOT that hard; I've
written one from scratch (maybe two) and done a few with yacc, and while
the code in question doubtless sucked (hint: everyone's first language
sucks), it worked fine.
> I need to see you actually write new C code.
Er, why?
> You have a big mouth when
> it comes to putting down people but the only time when you put your
> big mouth on the line (the Spark Notes test) you failed. I am giving
> you another chance.
... Wait, SPARK NOTES?
You're telling me that you are comparing Richard Heathfield to SPARK NOTES
and you think that a discrepancy means he's wrong?
Please tell me that it's still Halloween where you are and you went as
a troll.
> I wrote and debugged a recursive descent parser for my book. I wrote
> it again here after correcting the grammar
... Wait, uhm.
Does that mean the one in the book is wrong?
If so, then how did this not show up in debugging?
> It also demonstrates that the material is sufficiently complex for
> smart people to make stupid mistakes (Knuth has himself said he
> consistently gets binary search wrong the first time), and that the
> stupid people aren't the ones making the mistakes.
Stupid people make mistakes too.
> It's the people too ready to trash and if possible render unemployable
> their fellow human beings (by creating a record here) while explaining
> away their own mistakes as you explained away your failure to get a
> decent grade on the Spark Notes test.
I am totally fascinated by the concept of such a test. Is it ...
Hmm.
Well, I went and looked, and found:
http://www.sparknotes.com/cs/pointers/review/quiz.html
This is a funny quiz. It is full of errors.
Is this the quiz you used?
Please let me know.
-s
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
spinoza1111
> On 2009-11-01,spinoza1111<spinoza1...@yahoo.com> wrote:
>
> > Did you write it or did you steal it?
>
> Presumably wrote it. I mean, come on. A parser is NOT that hard; I've
> written one from scratch (maybe two) and done a few with yacc, and while
> the code in question doubtless sucked (hint: everyone's first language
> sucks), it worked fine.
>
> > I need to see you actually write new C code.
>
> Er, why?
Because I don't think you're competent.
>
> > You have a big mouth when
> > it comes to putting down people but the only time when you put your
> > big mouth on the line (the Spark Notes test) you failed. I am giving
> > you another chance.
>
> ... Wait, SPARK NOTES?
>
> You're telling me that you are comparing Richard Heathfield to SPARK NOTES
> and you think that a discrepancy means he's wrong?
Yes. The anonymous team who drafted the Spark Notes test were more
competent than Heathfield, just as Schildt is also more competent than
you.
Note that I don't say "at C" because to be competent at a mistake is
to be subhuman. No, I mean more competent human beings. You know what
a human being is, don't you?
>
> Please tell me that it's still Halloween where you are and you went as
> a troll.
>
> > I wrote and debugged a recursive descent parser for my book. I wrote
> > it again here after correcting the grammar
>
> ... Wait, uhm.
>
> Does that mean the one in the book is wrong?
No. Like many smart people without serious personality disorders I
make typical mistakes: Knuth has confessed he makes the same mistake
in binary search each time he implements it anew. These brain farts
show that we're thinking non-autistically, like actual human beings.
You know what a human being is, or used to be?
I made the same error while developing the book but while coding
noticed it was wrong, and corrected it, using my mistake to explain
things.
I don't have to be right all the time whereas you must be since
otherwise you're a frightened little boy.
>
> If so, then how did this not show up in debugging?
It didn't show since fixed it. As I've said, I made the mistake
twice: in 2003 while writing the book, and last week when replying to
the OP.
>
> > It also demonstrates that the material is sufficiently complex for
> > smart people to make stupid mistakes (Knuth has himself said he
> > consistently gets binary search wrong the first time), and that the
> > stupid people aren't the ones making the mistakes.
>
> Stupid people make mistakes too.
Arguably less than smart people because stupid people have to work at
7-11 where their actions are monitored, or on funny little embedded
systems as opposed to actually important systems such as Microsoft
boxes, and their work is constantly checked.
>
> > It's the people too ready to trash and if possible render unemployable
> > their fellow human beings (by creating a record here) while explaining
> > away their own mistakes as you explained away your failure to get a
> > decent grade on the Spark Notes test.
>
> I am totally fascinated by the concept of such a test. Is it ...
> Hmm.
>
> Well, I went and looked, and found:
>
> http://www.sparknotes.com/cs/pointers/review/quiz.html
>
> This is a funny quiz. It is full of errors.
Document each error. Is that why you failed to graduate properly and
did not get an MSCS? You sat in the test finding errors instead of
answering questions?
>
> Is this the quiz you used?
>
> Please let me know.
You're not really worth it.
>
> -s
> --
> Copyright 2009, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.nethttp://www.seebs.net/log/<-- lawsuits, religion, and funny pictureshttp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Richard Heathfield
spinoza1111 wrote:
What do you think?
>> translating yours? If it works (which I doubt), I gain nothing. If
>> it
>
> I need to see you actually write new C code.
On the other hand, the world would benefit significantly if you would
stop writing new C code. You're not very good at it. I've written
(probably) millions of lines of new C code over the years, and I
continue to write new C code. If you need to see me actually writing
it, you'll have to trick me into hiring you, which is not going to be
easy.
> You have a big mouth
> when it comes to putting down people but the only time when you put
> your big mouth on the line (the Spark Notes test) you failed.
For the benefit of those who may not know, the subject of the Spark
Notes test in question was C++, not C. Although we don't actually
know whether it was written by someone who had learned their C++ from
Schildt, it seems likely. EGN did that test and scored badly. I did
the test too, refused to answer several questions because it was
clear that they had no correct answer, pointed out several questions
where either the question, the answers, or both were flawed but where
it was possible to guess the intent of the reader, and still managed
(meaninglessly) to score higher than EGN. EGN ascribes significance
to the results of this flawed test, and says I failed it because I
only scored more points than him. In my view, it was the test that
failed.
> I am giving you another chance.
Go on then, dig out the Spark Notes C test if there is one, and we'll
tell you what's wrong with it. And then you can blame C for the idiot
that wrote the test (assuming an idiot did write the test, which is
not a given but seems likely).
> I wrote and debugged a recursive descent parser for my book.
I have only your word for that.
<nonsense snipped>
Seebs
>> Er, why?
> Because I don't think you're competent.
Wait, me too, or just Richard?
> Yes. The anonymous team who drafted the Spark Notes test were more
> competent than Heathfield, just as Schildt is also more competent than
> you.
... What the fuck?
> Note that I don't say "at C" because to be competent at a mistake is
> to be subhuman.
You clearly do not understand why Buster Keaton rocks.
> No, I mean more competent human beings. You know what
> a human being is, don't you?
Normally, yes.
However, even if we grant that they're hypothetically competent
at "being human beings" or whatever, that still doesn't make their test
informative as to whether someone knows C.
And come to think of it... It sounds like you've just asserted that,
if Richard Heathfield can write C competently, that makes him subhuman.
You're not exactly making a persuasive argument here that he should show
you how good his code is.
> No. Like many smart people without serious personality disorders I
> make typical mistakes:
This is also true of stupid people without serious personality disorders,
smart people with serious personality disorders, or stupid people with
serious personality disorders.
> Knuth has confessed he makes the same mistake
> in binary search each time he implements it anew. These brain farts
> show that we're thinking non-autistically, like actual human beings.
Actually, they don't. Because autistic people make those same kinds of
mistakes.
> I don't have to be right all the time whereas you must be since
> otherwise you're a frightened little boy.
This would be much, much, more persuasive if I hadn't admitted to at least
half a dozen errors in comp.lang.c in the last month or so.
> Arguably less than smart people because stupid people have to work at
> 7-11 where their actions are monitored, or on funny little embedded
> systems as opposed to actually important systems such as Microsoft
> boxes, and their work is constantly checked.
Oh, I see. You're trying to sneakily imply that I'm stupid. No, not buying
it. I certainly have my cognitive flaws, but "stupidity" is not one
of them.
> Document each error.
I'll just give you my favorite:
After this code executes
int arr[10];
int i;
i = &arr[9] - arr;
what is the value of i?
(A) 8
(B) 9
(C) 10
(D) Won't compile
Go ahead, guess what their answer is. Guess what mine was. And guess
what my compiler says if I try it. :) (Hint: The last two are both
the correct answer. Theirs isn't.)
> Is that why you failed to graduate properly and
> did not get an MSCS?
Who said I failed to graduate properly? I graduated just fine with a BA.
I didn't feel like doing more school at the time, so I just started going out
and doing stuff.
> You sat in the test finding errors instead of
> answering questions?
Funny thing, when I was doing tests written by college professors rather
than by random people on the internet, I didn't find nearly so many errors.
:)
> You're not really worth it.
From which I infer that this WAS the test you used, or part of the same test,
and that the idea that there might be unambiguous errors in that test would
undermine the quality of your argument against Richard Heathfield?
-s
--
Seebs
> For the benefit of those who may not know, the subject of the Spark
> Notes test in question was C++, not C.
Oh, then it was a different one.
Looking at this one, though, I think I would share your evaluation. Many
of the questions are ambiguous or poorly phrased, a few are just plain
wrong.
spinoza1111
Since Ben is too lazy and too discourteous to reply with errors, I
shall reply with errors in the code that I found when starting to
convert it to C.
Briefly it failed for a null string and a blank.
It failed (out of bounds subscript) in the mulFactor recognizer when
the infix expression was a null string. This is because mulFactor is
what would be in a more elaborate parser a lexxer looking to the next
character and returning some agreed on symbol when the input is at an
end. Therefore, mulFactor has to take responsibility in the absence of
a lexxer for detailed pointer checks. It started by looking for a
letter without checking intIndex for being out of bounds.
It needed this check. The second test in mulFactor did not since the
bounds check is part of the while condition. But the third test for a
left parenthesis also needed this check.
I put a new check at the start of mulFactor, returning false when
intIndex>intEnd. I also added a false and error return when mulFactor,
which again combines the jobs of mulFactor and lex, fails to find one
of its three alternatives: letter, number, parenthesized expression. I
also made the output of the regression test more readable.
Note that people who make mistakes learn more even if like Knuth wrt
binary search they make them more than once, IF they are not
constantly interrupted by autistic twerps. They also teach more.
There may have been other mistakes in this code. I have neither
formally nor informally proved it correct. But apart from making an
unsupported claim, Bacarisse has as yet provided no insights. I have
had to do so, so far, wrt to the null string and blank character bug.
Nothing could more clearly indicate the pathology of a newsgroup so
dominated by autistic twerps.
Here is the new test regression output, followed by the new code.
Expect "": For the infix expression "", the Polish expression or error
report is
Error detected at or near character 0 in "": Expected multiplication
factor not found; Error detected at or near character 0 in "":
Expression doesn't start with addFactor
--------------------------------------------
Expect "": For the infix expression " ", the Polish expression or
error report is
Error detected at or near character 0 in " ": Unexpected character '
'; Error detected at or near character 0 in " ": Expected
multiplication factor not found; Error detected at or near character 0
in " ": Expression doesn't start with addFactor
--------------------------------------------
Expect "2 4 3 + /": For the infix expression "2/(4+3)", the Polish
expression or error report is
2 4 3 + /
--------------------------------------------
Expect "2 4 / 3 +": For the infix expression "2/4+3", the Polish
expression or error report is
2 4 / 3 +
--------------------------------------------
Expect "2 4 3 + /": For the infix expression "((2/(4+3)))", the Polish
expression or error report is
2 4 3 + /
--------------------------------------------
Expect "10 113 2 2 4 3 + / + 2 + 2 + - + a *": For the infix
expression "((10+(113-(2+((((((2/(4+3)))))))+2+2))))*a", the Polish
expression or error report is
10 113 2 2 4 3 + / + 2 + 2 + - + a *"
--------------------------------------------
Expect error: For the infix expression "11+", the Polish expression or
error report is
Error detected at or near character 3 in "11+": Addition or
subtraction operator is not followed by addFactor
--------------------------------------------
Expect error: For the infix expression "11 +", the Polish expression
or error report is
Error detected at or near character 2 in "11 +": Expected addition or
subtraction operator not found
--------------------------------------------
Expect "10 113 + a *": For the infix expression "(10+113)*a", the
Polish expression or error report is
10 113 + a *
--------------------------------------------
Expect "10 113 + a *": For the infix expression "((10+113))*a", the
Polish expression or error report is
10 113 + a *
--------------------------------------------
Expect "1": For the infix expression "1", the Polish expression or
error report is
1
--------------------------------------------
Expect "a b + c -": For the infix expression "a+b-c", the Polish
expression or error report is
a b + c -
--------------------------------------------
Expect "1 1 +": For the infix expression "1+1", the Polish expression
or error report is
1 1 +
--------------------------------------------
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace infix2Polish
{
class Program
{
static void Main(string[] strArgs)
{
if (strArgs.GetUpperBound(0) < 0)
Console.WriteLine(tester());
else
Console.WriteLine(infix2Polish(strArgs[0]));
return;
}
private static string tester()
{
string strSep =
Environment.NewLine +
"--------------------------------------------" +
Environment.NewLine;
return "Expect \"\": " +
infix2PolishTest("") +
strSep +
"Expect \"\": " +
infix2PolishTest(" ") +
strSep +
"Expect \"2 4 3 + /\": " +
infix2PolishTest("2/(4+3)") +
strSep +
"Expect \"2 4 / 3 +\": " +
infix2PolishTest("2/4+3") +
strSep +
"Expect \"2 4 3 + /\": " +
infix2PolishTest("((2/(4+3)))") +
strSep +
"Expect " +
"\"10 113 2 2 4 3 + / + 2 + 2 " +
"+ - + a *\": " +
infix2PolishTest
("((10+(113-(2+((((((2/(4+3)))))))+2+2))))*a") +
"\"" +
strSep +
"Expect error: " +
infix2PolishTest("11+") +
strSep +
"Expect error: " +
infix2PolishTest("11 +") +
strSep +
"Expect \"10 113 + a *\": " +
infix2PolishTest("(10+113)*a") +
strSep +
"Expect \"10 113 + a *\": " +
infix2PolishTest("((10+113))*a") +
strSep +
"Expect \"1\": " +
infix2PolishTest("1")+
strSep +
"Expect \"a b + c -\": " +
infix2PolishTest("a+b-c") +
strSep +
"Expect \"1 1 +\": " +
infix2PolishTest("1+1") +
strSep;
}
private static string infix2PolishTest(string strInfix)
{
return "For the infix expression " +
"\"" + strInfix + "\", " +
"the Polish expression or error report is " +
Environment.NewLine +
Environment.NewLine +
infix2Polish(strInfix);
}
if (intIndex > intEnd) return false;
else
return errorHandler(strInfix,
intIndex,
ref strErrorMessage,
"Unexpected character " +
"'" + strInfix[intIndex] + "'");
spinoza1111
One nit: it shouldn't say here and on the next line "expect a null
string": it should say "expect an error".
I will take Peter's and Richard's silence on these posts to indicate
incompetence to study this code and find flaws.
I shall take Ben's as indicating that he's out Trick or Treating, or
is studying the code desparate to find a justification for his slander.
Seebs
> incompetence to study this code and find flaws.
I don't know the language you wrote it in, and also don't feel a lot of
need to try to find flaws in your code.
Write something in a language I know and post it in an appropriate group
and I'd be glad to critique it for you. My interest level in learning
C# is pretty low to begin with, and trying to learn it just to critique
your code seems particularly pointless.
spinoza1111
> On 2009-11-01,spinoza1111<spinoza1...@yahoo.com> wrote:
>
> > I will take Peter's and Richard's silence on these posts to indicate
> > incompetence to study this code and find flaws.
>
> I don't know the language you wrote it in, and also don't feel a lot of
> need to try to find flaws in your code.
>
> Write something in a language I know and post it in an appropriate group
> and I'd be glad to critique it for you. My interest level in learning
> C# is pretty low to begin with, and trying to learn it just to critique
> your code seems particularly pointless.
I have written it in C# as a way to prototype it for the original
poster without doing his homework for him, and now that he's probably
handed in the assignment, I am rewriting it in C, using the C Sharp as
a prototype.
Furthermore, I have taken the risk of critiqueing C without being, any
more, completely familiar with the language. I submit that you're
afraid that I will laugh at you should you critique C Sharp. Fear not.
I am no autistic twerp.
The original intent of programming language design on the part of
Grace Hopper, John Backus, Edsger Dijkstra and the men who created
Algol was NOT to create a group of mutually incomprehensible tribal
languages and a bunch of phony "experts". Therefore, real computer
scientists are willing to comment on code in unfamiliar languages, for
essentially the same reason that in a humanistic structured
walkthrough, contributions from all members are encouraged, and any
"pecking order", especially some pecking order dominated by autistic
twerps, where the savagery is complementary to the savagery with which
some of these twerps were treated growing up, is discouraged.
Can you write it in C using my C Sharp as a prototype, given that C
Sharp is broadly similar to C?
spinoza1111
>
> > I will take Peter's and Richard's silence on these posts to indicate
> > incompetence to study this code and find flaws.
>
> I don't know the language you wrote it in, and also don't feel a lot of
> need to try to find flaws in your code.
>
> Write something in a language I know and post it in an appropriate group
Furthermore, the idea that computer languages are even distinct is
absurd. That they are is a historical accident, caused by the large
number of errors made in language design in the early days.
Insofar as "knowledge" of C is knowledge of mistakes, C has no
standing as an academic subject and should not be spoken of as a
computer language. Instead, it should be considered a pathology which
computer scientists must learn for the same reason doctors must learn
cancer.
People whose main claim to expertise in C should be sent to re-
education camps on the model of UN centres in Africa which train
former guerrillas in useful trades.
And the world still needs one programming language that can be used by
everyone. The guy on the screen in the 1984 Apple commercial was
right.
> and I'd be glad to critique it for you. My interest level in learning
> C# is pretty low to begin with, and trying to learn it just to critique
> your code seems particularly pointless.
>
> -s
> --
Seebs
> more, completely familiar with the language. I submit that you're
> afraid that I will laugh at you should you critique C Sharp. Fear not.
> I am no autistic twerp.
It's not that, it's that I don't know the language and wouldn't care to
try to criticize code in a language I don't know. You're welcome to laugh
at me anyway if you wish. It may help if you imagine that I've got a big
red clown nose. Honk honk! Honk honk!
> The original intent of programming language design on the part of
> Grace Hopper, John Backus, Edsger Dijkstra and the men who created
> Algol
Your name-dropping is starting to make me wonder if it's NPD week in
comp.lang.c. Why do you obsessively cite to other people's accomplishments?
> was NOT to create a group of mutually incomprehensible tribal
> languages and a bunch of phony "experts".
Doubtless it wasn't.
> Therefore, real computer
> scientists are willing to comment on code in unfamiliar languages,
Ahh. I see. The intent of the people who developed natural human language
was not to create a group of mutually incomprehensible tribal languages
and a bunch of phony "experts", which is why real linguists are willing to
review books in unfamiliar languages.
Furthermore, it's worth pointing out that C# was not created by the
luminaries of the field, but rather by Microsoft, and that their history
strongly suggests that it was *exactly* their intent to create a tribal
language mutually-incomprehensible with other languages and a bunch of
phony "experts", because that's been their strategy throughout the
last thirty or so years.
> for
> essentially the same reason that in a humanistic structured
> walkthrough, contributions from all members are encouraged, and any
> "pecking order", especially some pecking order dominated by autistic
> twerps, where the savagery is complementary to the savagery with which
> some of these twerps were treated growing up, is discouraged.
This is a beautiful example of the kind of rant that keeps us coming back
to your posts. I'm sufficiently free of pecking orders that it's considered
a neurological disorder, and you're ranting at me about pecking orders.
That's amusing.
But it doesn't change the fact that I don't know C#, and have pretty much
no interest in reviewing hundreds of lines of non-C code in comp.lang.c. I
would react the same way to a suggestion that I review a ton of shell
script code here, even though I consider myself basically competent to
review shell scripts.
> Can you write it in C using my C Sharp as a prototype, given that C
> Sharp is broadly similar to C?
I probably could, but I don't see why I'd bother. I can write C code
from all sorts of stuff, but this seems like fundamentally dull code.
Pick something fun!
Seebs
> absurd. That they are is a historical accident, caused by the large
> number of errors made in language design in the early days.
Hmm. You should hook up with Scott Nudds, I'm sure he'd appreciate your
insights into the merits of language design.
I don't think I find your argument persuasive. I do not think there exists
a universally ideal language design; in fact, it seems to me that
domain-specific languages are a compelling choice for many applications.
I view languages as tools. I expect to see a single unified language
about the time I expect to see a single unified woodworking tool, and
for about the same reasons.
> Insofar as "knowledge" of C is knowledge of mistakes,
Except you've never shown this. You've asserted that it fails to conform
to your expectations, and that you think this is a mistake, but you've not
exactly proven your point.
> C has no
> standing as an academic subject and should not be spoken of as a
> computer language. Instead, it should be considered a pathology which
> computer scientists must learn for the same reason doctors must learn
> cancer.
That's a whole lot of very pretty rhetoric, but again, you have to prove
your point before arguing further from it.
> People whose main claim to expertise in C should be sent to re-
> education camps on the model of UN centres in Africa which train
> former guerrillas in useful trades.
This isn't a sentence, but if it were, I'd bet it would be a stupid
one. You seem to have omitted a clause, though. Anyway, don't worry,
I'm almost certainly more famous for expertise in Bourne shell than
I am for expertise in C now. (And if you want to see a language which
is chock full of astounding mistakes, Bourne shell is a true marvel
of the art. It isn't used because it's an incredibly well-designed
language, but because it's extremely widely available and fairly
flexible, and we've learned how to overcome most of the weaknesses.)
> And the world still needs one programming language that can be used by
> everyone. The guy on the screen in the 1984 Apple commercial was
> right.
You know, it's a shame that we wasted thousands and thousands of years
of peoples' time researching computer science and language design when we
coulda just watched a superbowl ad and gotten the real answer.
Tell you what, just as a quick sanity check:
The one programming language that can be used by everyone:
* Should have a way to express explicit invocation of specific machine
instructions, yes/no?
* Should completely abstract away memory management so there's no such
things as pointers, yes/no?
* Should be designed for "intelligent" people rather than "autistic twerps",
yes/no?
* Should be accessible to people who are not particularly intelligent,
yes/no?
* Should compile directly to machine-specific instructions, yes/no?
* Should be interpreted dynamically and allow for the evaluation of
strings of text, yes/no?
I'm really looking forward to your answers.
-s
--
Richard Heathfield
<snip>
> Well, I went and looked, and found:
>
> http://www.sparknotes.com/cs/pointers/review/quiz.html
>
> This is a funny quiz. It is full of errors.
Oooh, you found a C version. Well done.
> Is this the quiz you used?
No, he's banging on about the C++ version, which is similarly riddled.
The following answers assume (where possible) that the test setter
knows C. This is a poor assumption, so I've annotated the answers.
1. (b) - sizeof(int[10]) != sizeof(int *) EORWS[*]. The setter may
expect (a) - it's a common misconception.
2. (b) - sizeof "hello world" != sizeof(char *) EORWS. The setter may
expect (a) - it's another common misconception.
3. (b) - C's indexing is zero-based. One would hope that the setter
knows this.
4. (b) - str cannot be a character pointer variable that holds a
string, but if it points to that string, str[3] has the value 'd',
not 'a'. One would hope that the setter knows this.
5. (b) - you can't actually pass an array to a function, but if you
try, it is not the address of the array that is passed, but the
address of the first element of the array. (The difference is in the
/type/.) The setter may expect (a) - it's a common misconception.
6. (b) - C doesn't have pass by reference, so addresses of variables
can't be passed by reference. The setter may expect (a) - it's a
common misconception.
7. (b) - false for one-and-a-half reasons; firstly it's a typedef, not
an object definition, and secondly even if it were a definition it's
for ints, not integers. All ints are integers, but not all integers
are ints. I think the setter and I will agree on at least the first
reason, if not the second.
8. (a) - about time we had an (a). This one seems fair enough - whilst
it is true that malloc can fail, it is also true that it can succeed!
And it is certainly possible to allocate memory for an (unnamed)
array.
9. (b) - I suspect that vTrue is a typo for True, but in any case it's
false so that's fine. Unless the setter doesn't know about the dot
operator, of course.
10. (b) - assuming that *p and i have the same type (which is not made
clear). If they don't, then (d) is also a correct answer (i.e. not a
correct assignment).
11. (d) - but they mean '\0', not '\\0'
12. (c) must surely be the intended answer, although of course a
segfault is *not* guaranteed.
13. (c) - I think this question is fair enough.
14. (a) is (probably) the intended answer, but the real answer is that
the behaviour of the program is undefined because it calls a variadic
function without a valid prototype in scope.
15. (b) is (probably) the intended answer, but again the real answer
is that the program's behaviour is undefined, for the same reason as
the previous question.
16. (a) is (probably) the intended answer, but the real answer is that
the behaviour of the program is undefined because it calls a variadic
function without a valid prototype in scope.
17. (d) is undoubtedly the intended answer. In C, the value of NULL is
always 0. Its type is either int or void *.
18. (a), assuming the question setter is simply ascertaining that the
positioning (or indeed the presence) of the whitespace is irrelevant
to this particular line of code.
19. (b), although the wording is a little odd. It is certainly false
that you can't have pointers to functions.
20. (b) - and it's a reasonable question, albeit rather simple.
21. (c) - provided that the integers mentioned in (c) are ints, which
isn't specified.
22. (c) is the correct answer. I can't predict what answer the test
setter wants.
23. (b) is the obvious answer. I can think of a number of (weaselly)
ways to justify the answer (a), but I suspect the setter can't.
24. (b). The test itself uses pointers to other types.
25. (a) is probably (and ought to be) the intended answer; for
example, int p[6]; *p = 42; - of course, there are situations in
which an array /cannot/ be used as a constant pointer. For example:
int arr[32]; int *p = arr; size_t s1 = sizeof arr; s2 = sizeof p;
will give different values for s1 and s2 (EORWS).
26. (d) is intended, but should say "any of the above" since it
clearly can't hold all of them at once (unions notwithstanding).
27. (d) is the intended answer. Actually, it's the "address operator"
or "unary & operator".
28. (b) - you can't multiply pointers!
29. (d) is the expected answer, but the real answer is that the
behaviour of the code is undefined.
30. (d) - and this is the first *good* question.
31. (b) - obvious.
32. (c) - obvious.
33. (a) - obvious.
34. (c) is the intended answer. Also, the cast is pointless.
35. (d) - obvious.
36. (d) - obvious.
37. (a) - obvious.
38. (d) - obvious.
39. (c) - obvious.
40. (a) - obvious.
41. Insufficient information to answer the question. If spark() is
passed x (which is not stated in the question), then obviously the
answer is (a). Otherwise, obviously the answer is (b).
42. (b) - obvious.
43. (d) is the correct answer - argv is actually a pointer to pointer
to char, which points at the first element of an array of strings. It
is not clear what answer is intended, however.
44. (b) - ignoring the 0b prefix.
45. (d) - obvious.
The answering mechanism gave incorrect responses to several of these
questions, of which Q42 is the most embarrassing - it wants 10, where
the answer is quite obviously 9. I can think of no reasonable
circumstance in which any competent C programmer could possibly
imagine that 10 is a correct answer to that question.
In short, a lousy test.
* EORWS = Except On Really Weird Systems
Richard Heathfield
<26d6ea84-e198-491b...@v37g2000prg.googlegroups.com>,
spinoza1111 wrote:
> On Nov 1, 10:31 am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
<snip>
>> Your code does not parse the language
>> defined by the grammar, and what it does do, it does in a rather
>> roundabout way.
>
> If you think the grammar is correct, say so clearly. You imply it
> but are too graceless to say it. Now the issue is whether the code
> supports the correct grammar correctly.
>
> You present no evidence for the first claim. As to the second, it
> means you've never seen this simple algorithm.
Why do you expect other people to present evidence for their claims,
when you rarely if ever present any evidence for yours?
Richard Heathfield
spinoza1111 wrote:
<snip>
> I will take Peter's and Richard's silence on these posts to indicate
> incompetence to study this code and find flaws.
How kind. In return, I will take your failure to present evidence,
when asked, of any specific claim you make as your acceptance that
that specific claim is false. Which makes the vast, vast, vast vast
vast majority of your claims false.
<snip>
Seebs
Linky?
> 2. (b) - sizeof "hello world" != sizeof(char *) EORWS. The setter may
> expect (a) - it's another common misconception.
My quibble: A string is not "equivalent to a pointer to character".
A string is a series of bytes terminated by a null byte.
> 4. (b) - str cannot be a character pointer variable that holds a
> string, but if it points to that string, str[3] has the value 'd',
> not 'a'. One would hope that the setter knows this.
In a fit of inspired brilliance, I actually got that one wrong.
It is not every day I can be tripped up by the fencepost.
> 6. (b) - C doesn't have pass by reference, so addresses of variables
> can't be passed by reference. The setter may expect (a) - it's a
> common misconception.
Yes, exactly.
> 9. (b) - I suspect that vTrue is a typo for True, but in any case it's
> false so that's fine. Unless the setter doesn't know about the dot
> operator, of course.
I went with "false", because, as you note, you can't use -> on a struct,
only on a pointer-to-struct.
> 11. (d) - but they mean '\0', not '\\0'
Uh-huh.
> 14. (a) is (probably) the intended answer, but the real answer is that
> the behaviour of the program is undefined because it calls a variadic
> function without a valid prototype in scope.
Heh.
> 17. (d) is undoubtedly the intended answer. In C, the value of NULL is
> always 0. Its type is either int or void *.
I love this question. "In most languages..." Uh, lolwut?
Also, while 0x00000000 is indeed a value which compares equal to NULL,
it's not necessarily a reasonable guess as to the value NULL has. But
it's a likely output from, say, trying to print a null pointer with %p.
But... most *languages*?
> 25. (a) is probably (and ought to be) the intended answer; for
> example, int p[6]; *p = 42; - of course, there are situations in
> which an array /cannot/ be used as a constant pointer. For example:
> int arr[32]; int *p = arr; size_t s1 = sizeof arr; s2 = sizeof p;
> will give different values for s1 and s2 (EORWS).
Yeah. I feel that an array really can't be used as a constant pointer,
because (e.g.) it has the wrong size, etcetera.
> 26. (d) is intended, but should say "any of the above" since it
> clearly can't hold all of them at once (unions notwithstanding).
Pointers as a class can store all, so I think it's okay.
> 29. (d) is the expected answer, but the real answer is that the
> behaviour of the code is undefined.
Yup.
> 34. (c) is the intended answer. Also, the cast is pointless.
But possibly there to throw you off.
> 43. (d) is the correct answer - argv is actually a pointer to pointer
> to char, which points at the first element of an array of strings. It
> is not clear what answer is intended, however.
I think they want "array of arrays of characters". But it's not, because
an array of arrays of characters would have to specify the size of the
sub-arrays.
> The answering mechanism gave incorrect responses to several of these
> questions, of which Q42 is the most embarrassing - it wants 10, where
> the answer is quite obviously 9. I can think of no reasonable
> circumstance in which any competent C programmer could possibly
> imagine that 10 is a correct answer to that question.
Yeah. That was the one that really stood out for me as being Just Plain
Dumb.
Malcolm McLean
>
> That would not be useful. Your code does not parse the language
> defined by the grammar, and what it does do, it does in a rather
> roundabout way.
>
the layman, these might seem to be the result of inexperience. Actually even
highly-qualified programmers of twenty years' or more experience make such
errors, and not infrequently either.
To allude to a bug is a very bad way of making a bug report. If you allude
in a supercilious manner, as someone did for my book "Basic Algorithms" it
can also backfire (many of the bug reports I received turned out to be
false, there's nothing bad about that since one false report and one true
report is better than no reports at all, unless the attitude of the reporter
is that the bug indicvates stupidity on the part of the author).
Richard Heathfield
> On 2009-11-01, Richard Heathfield <r...@see.sig.invalid> wrote:
>> No, he's banging on about the C++ version, which is similarly
>> riddled.
>
> Linky?
Can't find it anywhere. Sorry. EGN will know where it is, though.
<snip>
Malcolm McLean
>
>Yes. The anonymous team who drafted the Spark Notes test were more
>competent than Heathfield, just as Schildt is also more competent than
>you.
>
>Note that I don't say "at C" because to be competent at a mistake is
>to be subhuman.
>
psychological profile tests in womens' magazines that no-one with any sense
would take seriously.
The problem is that if a question is at all interesting it will have more
than one answer. Sure, you can ask, "which construct is portable?". However
the assumption that C bytes are 8 bits is probably more portable than the
assumption that a long is at least 32 bits. 8 bit bytes are so useful that
compiler writers fake them up even when the underlying hardware won't
support the reads, even though the standard doesn't require this. Whilst on
tiny systems int is sometimes 8 bits and long 16 bits, to encourage
programmers to use integers that fit in registers where possible. So to
answer a question about "portability" you need to explain the situation.
Which won't fit in atick box.
Seebs
> The problem is that if a question is at all interesting it will have more
> than one answer. Sure, you can ask, "which construct is portable?". However
> the assumption that C bytes are 8 bits is probably more portable than the
> assumption that a long is at least 32 bits. 8 bit bytes are so useful that
> compiler writers fake them up even when the underlying hardware won't
> support the reads, even though the standard doesn't require this. Whilst on
> tiny systems int is sometimes 8 bits and long 16 bits, to encourage
> programmers to use integers that fit in registers where possible. So to
> answer a question about "portability" you need to explain the situation.
> Which won't fit in atick box.
Obviously, nothing with I8L16 has complied with any C standard, but perhaps
you could identify an example of any machine ever, anywhere, which has
implemented C in such a way?
I can't imagine it. The convenient existence of char and short for small
objects makes it seem awfully strange to imagine anyone implementing that.
-s
--
Malcolm McLean
"Seebs" <usenet...@seebs.net> wrote in message
> Obviously, nothing with I8L16 has complied with any C standard, but
> perhaps
> you could identify an example of any machine ever, anywhere, which has
> implemented C in such a way?
>
> I can't imagine it. The convenient existence of char and short for small
> objects makes it seem awfully strange to imagine anyone implementing that.
>
intended to run a parking ticket meter. (In the event a rival company got
the job, but not before we'd looked at the system to prepare our tender).
Malcolm McLean
> luminaries of the field, but rather by Microsoft, and that their history
> strongly suggests that it was *exactly* their intent to create a tribal
> language mutually-incomprehensible with other languages and a bunch of
> phony "experts", because that's been their strategy throughout the
> last thirty or so years.
>
Windows to other operating systems, whilst not making it too difficult to
port code from other operating systems to Windows. However they don't want
to be seen to be doing this.
Commercial and engineering considerations don't always coincide.
Seebs
> intended to run a parking ticket meter. (In the event a rival company got
> the job, but not before we'd looked at the system to prepare our tender).
Weird. I could imagine someone just punting and saying "we can't even
pretend to implement C, here's a stripped down system with nothing supported",
but I can't imagine someone calling a system with 8-bit ints "C". What
year was this about?
Nick Keighley
> It's possible that the
> "usual" grammar is incorrect (as in the case of left recursion) given
> Gresham's Law that 99% of everything is crap.
"Gresham's law is commonly stated: "Bad money drives out good""
"Sturgeon's Law. “Ninety percent of everything is crud.”"
Richard Heathfield
<c0c39cab-e025-4732...@w19g2000yqk.googlegroups.com>,
Nick Keighley wrote:
> On 27 Oct, 06:39, spinoza1111 <spinoza1...@yahoo.com> wrote:
>
>> It's possible that the
>> "usual" grammar is incorrect (as in the case of left recursion)
>> given Gresham's Law that 99% of everything is crap.
>
> "Gresham's law is commonly stated: "Bad money drives out good""
>
> "Sturgeon's Law. ?Ninety percent of everything is crud.?"
Yes, he's been told that over and over again, and he still gets it
wrong.
Malcolm McLean
> On 2009-11-01, Malcolm McLean <regn...@btinternet.com> wrote:
>> One system I used had 8 bit ints. It was a tiny 4K embedded chip, and it
>> was
>> intended to run a parking ticket meter. (In the event a rival company got
>> the job, but not before we'd looked at the system to prepare our tender).
>
> Weird. I could imagine someone just punting and saying "we can't even
> pretend to implement C, here's a stripped down system with nothing
> supported",
> but I can't imagine someone calling a system with 8-bit ints "C". What
> year was this about?
>
down. doubles were 3 bytes, for instance, which probably breaks some of the
standard somewhere.
Richard Heathfield
<snip>
> One system I used had 8 bit ints. It was a tiny 4K embedded chip,
> and it was intended to run a parking ticket meter.
I always thought there was something vaguely DarkSide-ish about you.
> (In the event a
> rival company got the job, but not before we'd looked at the system
> to prepare our tender).
Which company beat you? Microsith?
osmium
>Furthermore, the idea that computer languages are even distinct is
>absurd. That they are is a historical accident, caused by the large
>number of errors made in language design in the early days.
AFAICT, you claim involvement dating to the mid 50's, so this should be easy
for you. I'd like to see your list of the large number of errors in the
design of Algol 60. As a matter of fact there *was* a very good language
available early on, but it never caught on in the USA; and the US, IBM and
Microsoft has been dominant in the computer field for a very long time.
Ben Bacarisse
> On Nov 1, 10:31 am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>> spinoza1111<spinoza1...@yahoo.com> writes:
>>
>> <snip>
>>
>> > I published it here to show the OP that the grammar based approach
>> > works, and give him "pseudo code" for his C assignment, without doing
>> > his homework for him.
>>
>> > Since by now he's probably handed in his assignment, I challenge you
>> > to translate the C Sharp code to C.
>>
>> That would not be useful. Your code does not parse the language
>> defined by the grammar, and what it does do, it does in a rather
>> roundabout way.
>
> If you think the grammar is correct, say so clearly. You imply it but
> are too graceless to say it. Now the issue is whether the code
> supports the correct grammar correctly.
>
> You present no evidence for the first claim. As to the second, it
> means you've never seen this simple algorithm.
The evidence of the first is the truth of the second. The evidence
for the second is the code you posted. The set of strings that it
accepts is not a mystery. Whether that set is the same as the
language defined by the grammar is simple matter of fact. All the
evidence is there.
What you mean, I think, is that I am not being helpful enough. You
don't want to take the time to understand or test your code and you'd
like me to help more. If you want help writing a recursive descent
parser, post a question in a group where it is topical. If you want
help with you C#, post in a C# group. The details are off topic here.
You are probably correct about the last point: I may never have seen
that particular algorithm. There are lots of incorrect parsing
algorithms and despite having seen, literally, hundreds of students
try to do what you tried, I may well never have seen that particular
version.
--
Ben.
spinoza1111
> In <c67d9a14-64a2-41cb-ac39-148fbae42...@j9g2000prh.googlegroups.com>,
>
> spinoza1111wrote:
>
> <snip>
>
> > I will take Peter's and Richard's silence on these posts to indicate
> > incompetence to study this code and find flaws.
>
> How kind. In return, I will take your failure to present evidence,
> when asked, of any specific claim you make as your acceptance that
> that specific claim is false. Which makes the vast, vast, vast vast
> vast majority of your claims false.
You're silly bastard.
You see, in practically every post you mention my "errors" in the same
way people prefer to repeat "the errors of Schildt" as if this cite of
a cite makes the errors more numerous.
spinoza1111
>
> - Show quoted text -...
Ben Bacarisse sent me email identifying what he considered several
problems:
1. "(" : produced he said an invalid array reference
2. "////2": failed he said
3. "((((2" produced he said the Polish expression 2
4. "(": failed he said
5. "()" failed he said
6. "+" failed, he said
I added each case to the regression tests in tester() and only ((((2
failed, producing without error the Polish expression 2. 1, and 3-5
all work with the most recent version of the program which corrected
failures to test end of expression.
I have, in the latest version below (following the output of the
latest regression test), added an error call before the "exit:" label
that is the target of a go to (eek!) when intLevel is zero on the
detection of right parenthesis. If the loop that balances the
parentheses fails to match it will exit and this error will be caught.
Ben said the code was roundabout, and he doesn't seem to like the
"lookahead" strategy that finds matching parentheses. It uses a go to
(eek) which is unnecessary and can be replaced by an extra test on
exit from the balancing loop (if intIndex>intEnd, then parentheses do
not balance, otherwise call expression() recursively).
An alternative would be to treat end of string as a separate grammar
symbol, I believe, although I have not worked this strategy out in
detail.
Ben's use of email to identify errors saves a lot of pibble pabble
back and forth and I recommend it.
Here is the latest regression test, followed by the latest code.
Expect error: For the infix expression "(", the Polish expression or
error report is
Error detected at or near character 1 in "(": Parentheses are not
balanced; Error detected at or near character 1 in "(": Expected
multiplication factor not found; Error detected at or near character 1
in "(": Expression doesn't start with addFactor
--------------------------------------------
Expect error: For the infix expression "////2", the Polish expression
or error report is
Error detected at or near character 0 in "////2": Unexpected character
'/'; Error detected at or near character 0 in "////2": Expected
multiplication factor not found; Error detected at or near character 0
in "////2": Expression doesn't start with addFactor
--------------------------------------------
Expect error: For the infix expression "((((2", the Polish expression
or error report is
Error detected at or near character 1 in "((((2": Parentheses are not
balanced; Error detected at or near character 1 in "((((2": Expected
multiplication factor not found; Error detected at or near character 1
in "((((2": Expression doesn't start with addFactor
--------------------------------------------
Expect error: For the infix expression "()", the Polish expression or
error report is
Error detected at or near character 1 in "()": Expected multiplication
factor not found; Error detected at or near character 1 in "()":
Expression doesn't start with addFactor; Error detected at or near
character 1 in "()": Nested expression invalid; Error detected at or
near character 1 in "()": Expected multiplication factor not found;
Error detected at or near character 1 in "()": Expression doesn't
start with addFactor
--------------------------------------------
Expect error: For the infix expression "+", the Polish expression or
error report is
Error detected at or near character 0 in "+": Unexpected character
'+'; Error detected at or near character 0 in "+": Expected
multiplication factor not found; Error detected at or near character 0
in "+": Expression doesn't start with addFactor
1 1 +
--------------------------------------------
return "Expect error: " +
infix2PolishTest("(") +
strSep +
"Expect error: " +
infix2PolishTest("////2") +
strSep +
"Expect error: " +
infix2PolishTest("((((2") +
strSep +
"Expect error: " +
infix2PolishTest("()") +
strSep +
"Expect error: " +
infix2PolishTest("+") +
"Parentheses are not balanced");
spinoza1111
ADDRESS ALL OF BEN'S CONCERNS
spinoza1111
Hey, asshole:
This is just absurd. I refer you to the effort I made to provide a
regression test. As a result, I have addressed EACH ISSUE you have
raised by email. Do me the courtesy of not enabling the jerks in this
ng and admitting this.
> like me to help more. If you want help writing a recursive descent
I wrote a book on doing this, but I of course need help as do we all
when we code, even in a language with which we're familiar, because,
as Dijsktra knew and you don't seem to, software is hard. When will
you learn this simple lesson?
Perhaps a new form of personality disorder exists in which one doesn't
make errors found by others, but if this is so, I see this ability
only in people with serious personality disorders. These may be an
artifact of overfocus on code, but in view of the damage they do to
both the people with these disorders and the targets of their vicious
little tirades, I don't think it's worth it...especially since we know
how, through the collegial and humane structured walkthrough from
which we exclude both managers and autistic twerps, to eradicate bugs.
> parser, post a question in a group where it is topical. If you want
> help with you C#, post in a C# group. The details are off topic here.
>
> You are probably correct about the last point: I may never have seen
> that particular algorithm. There are lots of incorrect parsing
> algorithms and despite having seen, literally, hundreds of students
> try to do what you tried, I may well never have seen that particular
> version.
It's not an incorrect algorithm. It's available in dozens of sources.
I CODED the algorithm (code isn't an algorithm) in a language in which
I'm familiar in a very limited amount of time, on the Lamma Island
ferry during a six day work week. To save time and add to ontopic
discussion, I posted the first version, which I knew probably had
bugs, for comment, since (for the last time, asshole), the OP was
supposed to write the C, not me. The C Sharp simply demonstrates how
the algorithm works.
You are welcome to find further problems. But stop acting like an
asshole in public. You are enabling the real assholes.
>
> --
> Ben.- Hide quoted text -
spinoza1111
Dik has documented the fact that Algol's evaluation order was
nondeterministic. We now know that this is a mistake, since we now
know how to optimize.
spinoza1111
> "spinoza1111" <spinoza1...@yahoo.com> wrote in message
>
> >Yes. The anonymous team who drafted the Spark Notes test were more
> >competent than Heathfield, just as Schildt is also more competent than
> >you.
>
> >Note that I don't say "at C" because to be competent at a mistake is
> >to be subhuman.
>
> But multiple choice tests are a mistake as well, unless they are
> psychological profile tests in womens' magazines that no-one with any sense
> would take seriously.
Multiple choice tests are a reality, and should not be rejected
because they are "hard" or "contain errors". I now teach, among other
things, test preparation to Asian students who are systematically
discriminated against by American universities.
They don't have cushy jobs. They don't have Richard's leisure to
condemn the tests they must pass with high scores. Therefore I tell
them that it's not their concern if they find an error on a test.
I also tell them that the only answer they should mark should be the
best answer, and (1) there might be > 1 right answers (2) usually only
one correct answer and (3) in the case of an error in the test, the
best might not even be correct.
Nonetheless, if one has studied K & R, the Sparknotes is probably easy
because one (unless one's an autistic twerp) has learned two things in
any class, no matter how technical:
(1) The "right stuff"
(2) The favored interpretation
(2) is more important in English and other humanities but is even true
in mathematics. In the case of Sparknotes, the best answers reflect
what is usually taught and what, in practice, creates programmers who
can program, as opposed to programmers who (1) insist on always being
right and (2) start campaigns of personal destruction when their will
is thwarted.
>
> The problem is that if a question is at all interesting it will have more
> than one answer. Sure, you can ask, "which construct is portable?". However
> the assumption that C bytes are 8 bits is probably more portable than the
> assumption that a long is at least 32 bits. 8 bit bytes are so useful that
> compiler writers fake them up even when the underlying hardware won't
> support the reads, even though the standard doesn't require this. Whilst on
> tiny systems int is sometimes 8 bits and long 16 bits, to encourage
> programmers to use integers that fit in registers where possible. So to
> answer a question about "portability" you need to explain the situation.
> Which won't fit in atick box.
Excellent points, all of them.
If you want to be a computer scientist, then be a computer scientist:
if you want to be a programmer, be a programmer.
spinoza1111
> On 2009-11-01,spinoza1111<spinoza1...@yahoo.com> wrote:
>
> > Furthermore, the idea that computer languages are even distinct is
> > absurd. That they are is a historical accident, caused by the large
> > number of errors made in language design in the early days.
>
> Hmm. You should hook up with Scott Nudds, I'm sure he'd appreciate your
> insights into the merits of language design.
>
> I don't think I find your argument persuasive. I do not think there exists
> a universally ideal language design; in fact, it seems to me that
> domain-specific languages are a compelling choice for many applications.
>
> I view languages as tools. I expect to see a single unified language
> about the time I expect to see a single unified woodworking tool, and
> for about the same reasons.
>
> > Insofar as "knowledge" of C is knowledge of mistakes,
>
> Except you've never shown this. You've asserted that it fails to conform
> to your expectations, and that you think this is a mistake, but you've not
> exactly proven your point.
Are you seriously defending a()+b() reordering, not reordering a()||b
(), and backwards parameters? If so you're not qualified to speak on
programming languages in my opinion.
>
> > C has no
> > standing as an academic subject and should not be spoken of as a
> > computer language. Instead, it should be considered a pathology which
> > computer scientists must learn for the same reason doctors must learn
> > cancer.
>
> That's a whole lot of very pretty rhetoric, but again, you have to prove
> your point before arguing further from it.
>
> > People whose main claim to expertise in C should be sent to re-
> > education camps on the model of UN centres in Africa which train
> > former guerrillas in useful trades.
>
> This isn't a sentence, but if it were, I'd bet it would be a stupid
Typo. Change in to is.
> one. You seem to have omitted a clause, though. Anyway, don't worry,
> I'm almost certainly more famous for expertise in Bourne shell than
> I am for expertise in C now. (And if you want to see a language which
> is chock full of astounding mistakes, Bourne shell is a true marvel
> of the art. It isn't used because it's an incredibly well-designed
> language, but because it's extremely widely available and fairly
> flexible, and we've learned how to overcome most of the weaknesses.)
>
> > And the world still needs one programming language that can be used by
> > everyone. The guy on the screen in the 1984 Apple commercial was
> > right.
>
> You know, it's a shame that we wasted thousands and thousands of years
> of peoples' time researching computer science and language design when we
> coulda just watched a superbowl ad and gotten the real answer.
>
> Tell you what, just as a quick sanity check:
>
> The one programming language that can be used by everyone:
> * Should have a way to express explicit invocation of specific machine
> instructions, yes/no?
No.
> * Should completely abstract away memory management so there's no such
> things as pointers, yes/no?
What part of safe v unsafe mode don't you understand?
> * Should be designed for "intelligent" people rather than "autistic twerps",
> yes/no?
A big fat YES
> * Should be accessible to people who are not particularly intelligent,
> yes/no?
A big fat NO, and intelligence is NOT measured by IQ score. It's
primarily measured (for example on the modern SAT, even though this
doesn't purport to measure intelligence) by the ability to express
oneself accurately in one's native language.
> * Should compile directly to machine-specific instructions, yes/no?
No.
> * Should be interpreted dynamically and allow for the evaluation of
> strings of text, yes/no?
Yes
>
> I'm really looking forward to your answers.
>
> -s
> --
> Copyright 2009, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.nethttp://www.seebs.net/log/<-- lawsuits, religion, and funny pictureshttp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
osmium
Now I know what you consider a "large number": one. That casts your
observations in a different light.
Nick Keighley
> i have a string as (a+b)+8-(c/d) in Infix form.
>
> how can i convert it to postfix form using C language,,,????
have you looked at Dijkstra's Shunting-yard algorithm? Probably what
your instructor meant you to do rather than building a parser.
Kenny McCormack
spinoza1111 <spino...@yahoo.com> wrote:
...
>You (RH, Ed) are as such contemptible.
This is news???
Seebs
> Dik has documented the fact that Algol's evaluation order was
> nondeterministic. We now know that this is a mistake, since we now
> know how to optimize.
You keep making this claim, but you never actually establish a chain of
reasoning from undisputed facts which has this as a conclusion.
-s
--
Seebs
> way people prefer to repeat "the errors of Schildt" as if this cite of
> a cite makes the errors more numerous.
No one seems to be doing any such thing, in either case.
Seebs
> because they are "hard" or "contain errors".
In general, multiple choice tests are less good than other tests, but
are favored anyway because of the possible for automatic scoring. In
short, they make compromises in one attribute to score well in another.
A familiar theme; I'm surprised you aren't out campaigning against
these "mistakes."
> I also tell them that the only answer they should mark should be the
> best answer, and (1) there might be > 1 right answers (2) usually only
> one correct answer and (3) in the case of an error in the test, the
> best might not even be correct.
Seems right.
> Nonetheless, if one has studied K & R, the Sparknotes is probably easy
> because one (unless one's an autistic twerp) has learned two things in
> any class, no matter how technical:
>
> (1) The "right stuff"
> (2) The favored interpretation
That would work if they didn't have questions in which they choose an
answer which is unambiguously neither correct nor a favored interpretation.
> (2) is more important in English and other humanities but is even true
> in mathematics. In the case of Sparknotes, the best answers reflect
> what is usually taught and what, in practice, creates programmers who
> can program, as opposed to programmers who (1) insist on always being
> right and (2) start campaigns of personal destruction when their will
> is thwarted.
Actually, people who go with "what is usually taught" rather than what works
do about as well as a hypothetical structural engineer who goes with common
fashion rather than actual functionality.
Seebs
>> Except you've never shown this. �You've asserted that it fails to conform
>> to your expectations, and that you think this is a mistake, but you've not
>> exactly proven your point.
> Are you seriously defending a()+b() reordering, not reordering a()||b
> (), and backwards parameters?
Why, yes.
> If so you're not qualified to speak on
> programming languages in my opinion.
This is exactly my point. Read that quoted paragraph again.
"You've asserted that it fails to conform to your expectations,
and that you think this is a mistake, but you've not exactly proven
your point."
You haven't actually made any argument for this except a bald assertion
that "intelligent" people would expect it. You haven't established that
this is true. You haven't established that, if it is true, it should
be a significant component of language design. You haven't established
that it trumps other points.
I gave you a clear and concrete reason for which || should not be reordered,
which does not apply to +, but you seem unable to actually respond to or
make technical arguments. Ironically, despite your huge wall-of-text
complaints about other people making things personal, you use your insult
of the week about ten times as often as you make actual technical statements.
We've established that you dislike me, but you haven't shown that this is
a sound basis for a change in the design of programming languages.
>> > People whose main claim to expertise in C should be sent to re-
>> > education camps on the model of UN centres in Africa which train
>> > former guerrillas in useful trades.
>> This isn't a sentence, but if it were, I'd bet it would be a stupid
> Typo. Change in to is.
Figured.
>> The one programming language that can be used by everyone:
>> * Should have a way to express explicit invocation of specific machine
>> � instructions, yes/no?
> No.
Well. Congratulations, you've proposed that everyone use a language
that can't actually implement operating systems on most currently-available
hardware.
You fail at language design. Thanks for playing.
>> * Should completely abstract away memory management so there's no such
>> � things as pointers, yes/no?
> What part of safe v unsafe mode don't you understand?
Hmm. I'd guess that'd be the part where I've never heard of them?
>> * Should be designed for "intelligent" people rather than "autistic twerps",
>> � yes/no?
> A big fat YES
Expected.
>> * Should be accessible to people who are not particularly intelligent,
>> � yes/no?
> A big fat NO,
Then it can't be used by everyone, because the majority of people are
not partiicularly intelligent.
> and intelligence is NOT measured by IQ score.
Not having one, I would hardly claim that it is. :P
> It's
> primarily measured (for example on the modern SAT, even though this
> doesn't purport to measure intelligence) by the ability to express
> oneself accurately in one's native language.
Indeed. Which is interesting, because you suck at that.
>> * Should compile directly to machine-specific instructions, yes/no?
> No.
>> * Should be interpreted dynamically and allow for the evaluation of
>> � strings of text, yes/no?
> Yes
Well, that sounds nice on paper, but turns out to pretty much suck for anyone
who wants battery life.
Also, and this is merely a technical point, I'm sure...
How exactly is your language supposed to be implemented? It can't be
implemented in itself. We need something that produces machine-specific
instructions, at least for the forseeable future, to allow chips to run
code. So that something else must be used to implement your language,
which means we can't have a single language used by everybody.
Please think these ideas through for five minutes or so before suggesting
them, 'k?
-s
--
Richard Harter
wrote:
>On 2009-11-01, spinoza1111 <spino...@yahoo.com> wrote:
>
>> People whose main claim to expertise in C should be sent to re-
>> education camps on the model of UN centres in Africa which train
>> former guerrillas in useful trades.
>
>This isn't a sentence, but if it were, I'd bet it would be a stupid
>one. You seem to have omitted a clause, though.
It looks like a legitimate sentence to me, save that 'which'
should have been 'that'.
Welcome to alt.english.usage.
Richard Harter, c...@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
Kafka wasn't an author;
Kafka was a prophet!
Joe Wright
[ snip ]
>> Document each error.
>
> I'll just give you my favorite:
>
> After this code executes
>
> int arr[10];
> int i;
> i = &arr[9] - arr;
>
> what is the value of i?
> (A) 8
> (B) 9
> (C) 10
> (D) Won't compile
>
> Go ahead, guess what their answer is. Guess what mine was. And guess
> what my compiler says if I try it. :) (Hint: The last two are both
> the correct answer. Theirs isn't.)
>
Seebs - As my new hero contra spino I tend to support you. But looking at your
example I saw 9 - 0 which is 9. I wrote a little program (below) and compiled it
with each of my 4 C compilers. All 4 compiled it without diags and when run, all
4 report the value of i as 9. What did I miss?
#include <stdio.h>
int main(void)
{
int arr[10];
int i;
i = &arr[9] - arr;
printf("%d\n", i);
return 0;
}
--
Joe Wright
"If you rob Peter to pay Paul you can depend on the support of Paul."
Richard Harter
wrote:
>On 01 Nov 2009 09:07:09 GMT, Seebs <usenet...@seebs.net>
>wrote:
>
>>On 2009-11-01, spinoza1111 <spino...@yahoo.com> wrote:
>
>>
>>> People whose main claim to expertise in C should be sent to re-
>>> education camps on the model of UN centres in Africa which train
>>> former guerrillas in useful trades.
>>
>>This isn't a sentence, but if it were, I'd bet it would be a stupid
>>one. You seem to have omitted a clause, though.
>
>It looks like a legitimate sentence to me, save that 'which'
>should have been 'that'.
Oops, my bad. There is an 'is' missing. I'm with the wide boy
on this one, though - it's a typo.
Richard Heathfield
What you missed is probably the correct interpretation of "the last
two". It threw me for a moment as well. At first I thought he meant
"(C) and (D)", which doesn't work at all. I was about to tell him so,
and then... <voice tone="silly"> weeeelllll, I got to thinking about
that, and I thought, this is Seebs, would he really be that dumb?,
and then I thought, maybe he means some other "last two"</voice>, and
it turns out that by "the last two" he means (1) "what my answer was"
and (2) "what my compiler says if I try it". We are left to infer
that his answer, and the compiler's answer, are (B) 9, unlike "their
answer", (C) 10 (which is of course wrong).
spinoza1111
> On Sun, 01 Nov 2009 17:04:29 GMT, c...@tiac.net (Richard Harter)
> wrote:
>
> >wrote:
>
> >>On 2009-11-01,spinoza1111<spinoza1...@yahoo.com> wrote:
>
> >>> People whose main claim to expertise in C should be sent to re-
> >>> education camps on the model of UN centres in Africa which train
> >>> former guerrillas in useful trades.
>
> >>This isn't a sentence, but if it were, I'd bet it would be a stupid
> >>one. You seem to have omitted a clause, though.
>
> >It looks like a legitimate sentence to me, save that 'which'
> >should have been 'that'.
>
> Oops, my bad. There is an 'is' missing. I'm with the wide boy
> on this one, though - it's a typo.
>
> Kafka wasn't an author;
> Kafka was a prophet!
Let me all save you guys a lot of trouble:
People whose main claim to expertise IS C should be sent to re-
> >>> education camps on the model of UN centres in Africa which train
> >>> former guerrillas in useful trades.
The subject is people subsetted by those whose main claim is C. The
main verb is modal: "should be sent". The indirect object is "re-
education camps". This should be done "on the model of ", which is an
adverbial.
Seebs
> Seebs wrote:
>> I'll just give you my favorite:
>>
>> After this code executes
>>
>> int arr[10];
>> int i;
>> i = &arr[9] - arr;
>>
>> what is the value of i?
>> (A) 8
>> (B) 9
>> (C) 10
>> (D) Won't compile
>> Go ahead, guess what their answer is. Guess what mine was. And guess
>> what my compiler says if I try it. :) (Hint: The last two are both
>> the correct answer. Theirs isn't.)
> Seebs - As my new hero contra spino I tend to support you. But looking
> at your example I saw 9 - 0 which is 9. I wrote a little program (below)
> and compiled it with each of my 4 C compilers. All 4 compiled it without
> diags and when run, all 4 report the value of i as 9. What did I miss?
You missed nothing. The sparknotes people, however, feel that the answer
is (C) 10.
Keith Thompson
[...]
> 17. (d) is undoubtedly the intended answer. In C, the value of NULL is
> always 0. Its type is either int or void *.
[...]
Tiny quibble: The type of NULL can be void* or any integer type.
For example:
#define NULL 0ULL
is legal.
(Actually, I'm not certain it can be an integer type narrower than
int.)
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Ben Bacarisse
> "Ben Bacarisse" <ben.u...@bsb.me.uk> wrote in message
>>
>> That would not be useful. Your code does not parse the language
>> defined by the grammar, and what it does do, it does in a rather
>> roundabout way.
>>
> Computer code frquently contains errors which are simple lapses of logic. To
> the layman, these might seem to be the result of inexperience. Actually even
> highly-qualified programmers of twenty years' or more experience make such
> errors, and not infrequently either.
True. Spiniza1111 may be highly qualified and very experienced but
the grammar he posted was wrong and then the code that purports to
parse the corrected grammar did not do so. These may be due to simple
lapses of logic, but Spiniza1111 was suggesting that the code be used
as a model to follow. I thought (maybe wrongly) that it was worth
discouraging that use.
> To allude to a bug is a very bad way of making a bug report.
I am not making a bug report. I don't want to facilitate
Spiniza1111's desire to have an off-topic discussion of his C# code
here. Saying nothing may have been preferable.
<snip>
--
Ben.
spinoza1111
> "Malcolm McLean" <regniz...@btinternet.com> writes:
> > "Ben Bacarisse" <ben.use...@bsb.me.uk> wrote in message
>
> >> That would not be useful. Your code does not parse the language
> >> defined by the grammar, and what it does do, it does in a rather
> >> roundabout way.
>
> > Computer code frquently contains errors which are simple lapses of logic. To
> > the layman, these might seem to be the result of inexperience. Actually even
> > highly-qualified programmers of twenty years' or more experience make such
> > errors, and not infrequently either.
>
> True. Spiniza1111 may be highly qualified and very experienced but
> the grammar he posted was wrong and then the code that purports to
> parse the corrected grammar did not do so. These may be due to simple
> lapses of logic, but Spiniza1111 was suggesting that the code be used
> as a model to follow. I thought (maybe wrongly) that it was worth
> discouraging that use.
Ben, do you make the above claim about the most recent version, or are
you deliberately using past tense in order to dishonestly persist in a
claim? If so, you are indeed an "asshole" after all.
spinoza1111
Programmers are not engineers. Engineers have legal certification
procedures which programmers do not have. Programmers compare
themselves to engineers, but the best coder here, Bacarisse, prefers
at the crisis to stop reviewing code and make assertions about the
first version of the C Sharp parsing solution to Malcolm without
acknowledging whether or not the third version addresses his concerns.
Engineers don't do this because their limited job security provides
them the self-confidence and self-esteem of adults, a self-confidence
and self-esteem that is lacking in nearly every programmer I have
known.
At the Glosten Associates in Seattle in 1986, I wrote the first
version of their very successful GSSP graphical program for ship
stability. I worked with men certified as Ocean Engineers and I was
very impressed by their decency. Years later, during the Iraq war, I
met them again at a shipping conference and was also impressed to
learn that the company was not trying to get contracts in Iraq because
most of its employees and its principals felt this to be folly. This
is what integrity looks like. It's not trying to weasel out of your
responsiblities to decency by claiming a fashionable disease such as
autism.
I posted a C Sharp "prototype" here in answer to the OP's question in
order to back up my claim that the problem of converting infix to
Polish can be solved by a formal grammar approach. Bacarisse asserted
in public without proof that the prototype was broken despite also
implying that he didn't know C Sharp.
Because I respect his coding and analysis skills I asked for further
comment. I received private email which indicated that, despite
Bacarisse's claim that he didn't know C Sharp, he'd nonetheless ran
the code, using a C Sharp system, possibly free .Net "Express".
He found several problems. All but one I'd found independent of him
within 24 hours of posting the code, and they were caused by missing
bounds checks which I'd already added. The last was failure to emit an
error report when parentheses were unbalanced and this I fixed in the
third version.
Whenever someone uses an approach, or here, a closely related
programming language meant to fix C, that others don't feel qualified
to work with, it's "off-topic". But the politics of personal
destruction are always on-topic, and I shall at will from now on start
using words like "asshole" to describe people who think they are being
cute when they engage in these politics.
I have yet to see Richard Heathfield or Peter Seebach simulate what
computer science teachers and teachers of programming have to do in
the classroom. This is write pseudo or real code on the board and
explain it. Neither seem capable of posting other than canned replies
and neither are willing to take the risk. Only Keith Thompson has the
combination of technical integrity and courage to do so.
I believe it's possible for an intelligent programmer to intelligently
comment about reasonably clear code in a language HE DOES NOT KNOW,
and I believe that for the same reason as in the traditional
structured walkthough comments from all are welcome, people here
should have the courage to step outside their comfort zones and study
non-C code that's germane to the issue. The problem is that little
coders are desparately afraid to do so, and prefer being Snidely
Snively to being men.
In my very limited spare time I am converting my little parser to C to
RElearn more about C in order to better defend Schildt, with all of
his flaws, because I think collegiality and decency are far more
important than being a cute little asshole of a computer programmer,
who's used, in our society, to create wealth for the wealthy and then
thrown aside at the age of 40. When I have something I will post it to
this thread.
When will you people grow up? Hopefully before I have to become a C
expert for the second time in my life!
>
> -s
> --
spinoza1111
> "Malcolm McLean" <regniz...@btinternet.com> writes:
>
> >> That would not be useful. Your code does not parse the language
> >> defined by the grammar, and what it does do, it does in a rather
> >> roundabout way.
>
> > Computer code frquently contains errors which are simple lapses of logic. To
> > the layman, these might seem to be the result of inexperience. Actually even
> > highly-qualified programmers of twenty years' or more experience make such
> > errors, and not infrequently either.
>
> True. Spiniza1111 may be highly qualified and very experienced but
> the grammar he posted was wrong and then the code that purports to
The first version was wrong.
> parse the corrected grammar did not do so. These may be due to simple
The first version didn't test out of bounds in all cases. The second
version failed to flag unbalanced parentheses. Both versions were
instrumented with far more literate error reports and far more
thorough test cases than 99% of the code posted here, and little
enough new code is ever posted, even in C, because people prefer being
assholes.
The third version addresses all your concerns.
Stop being an asshole.
Peter Nilsson
> ...
> (Actually, I'm not certain [NULL] can be an integer type
> narrower than int.)
#define NULL ((char)0)
--
Peter
Ben Bacarisse
> On Nov 2, 4:57 am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>> "Malcolm McLean" <regniz...@btinternet.com> writes:
>> > "Ben Bacarisse" <ben.use...@bsb.me.uk> wrote in message
>>
>> >> That would not be useful. Your code does not parse the language
>> >> defined by the grammar, and what it does do, it does in a rather
>> >> roundabout way.
>>
>> > Computer code frquently contains errors which are simple lapses of logic. To
>> > the layman, these might seem to be the result of inexperience. Actually even
>> > highly-qualified programmers of twenty years' or more experience make such
>> > errors, and not infrequently either.
>>
>> True. Spiniza1111 may be highly qualified and very experienced but
>> the grammar he posted was wrong and then the code that purports to
>> parse the corrected grammar did not do so. These may be due to simple
>> lapses of logic, but Spiniza1111 was suggesting that the code be used
>> as a model to follow. I thought (maybe wrongly) that it was worth
>> discouraging that use.
>
> Ben, do you make the above claim about the most recent version,
No.
> or are
> you deliberately using past tense in order to dishonestly persist in a
> claim?
I used the past tense to talk about what I had said because that is
what Malcolm commented on.
<snip>
--
Ben.
Keith Thompson
Yes, I should have thought of that, thanks.
Curtis Dyer
> On 2009-11-01, spinoza1111 <spino...@yahoo.com> wrote:
>> On Nov 1, 2:11�pm, Seebs <usenet-nos...@seebs.net> wrote:
<snip>
>> Arguably less than smart people because stupid people have to
>> work at 7-11 where their actions are monitored, or on funny
>> little embedded systems as opposed to actually important
>> systems such as Microsoft boxes, and their work is constantly
>> checked.
Wow.
> Oh, I see. You're trying to sneakily imply that I'm stupid.
> No, not buying it. I certainly have my cognitive flaws, but
> "stupidity" is not one of them.
Am I interpreting spinoza1111's remark here correctly? It also
seems he is slighting programmers who work on embedded systems. I
suppose this shouldn't be surprising, but it's just so painfully
absurd. The many contributions of embedded systems programmers (I'm
not one, but do admire them) are demonstrably undeniable.
<snip>
--
"Don't worry about efficiency until you've attained correctness."
~ Eric Sosman, comp.lang.c
spinoza1111
notation convertor. When run from the command line it should execute
all cases used to test the C Sharp version correctly. Its string
handling is simpler owing to the limitations of C.
This code unless it is seriously fucked up demonstrates the
practicality of using a formal language based approach to infix to
Polish notation. It's also part of my project of relearning C.
Comments as opposed to BS welcome.
#include <stdio.H>
#include <stdlib.H>
#define MAX_POLISH_LENGTH 100
int errorHandler(char *strMessage)
{
printf("\n%s\n", strMessage); return 0;
}
int errorHandlerSyntax(int intIndex, char *strMessage)
{
printf("\nError at character %d: %s\n",
intIndex,
strMessage);
return 0;
}
int stringLength(char *strInstring)
{
int intIndex1;
for (intIndex1 = 0;
strInstring[intIndex1] != '\0';
intIndex1++) { }
return intIndex1;
}
int stringAppendChar(char *strInstring,
char chrNew,
int intMaxLength)
{
int intLength = stringLength(strInstring);
if (intLength >= intMaxLength - 1)
{
errorHandler
("Cannot append character: string too long");
return 0;
}
strInstring[intLength] = chrNew;
strInstring[intLength + 1] = '\0';
return -1;
}
int appendPolish(char *strPolish, char chrNext)
{
return
((*strPolish == '\0' || *strPolish == ' ')
?
-1
:
stringAppendChar(strPolish,
' ',
MAX_POLISH_LENGTH))
&&
stringAppendChar(strPolish,
chrNext,
MAX_POLISH_LENGTH)
&&
stringAppendChar(strPolish, ' ', MAX_POLISH_LENGTH);
}
int expression(char *strInfix,
char *strPolish,
int *intPtrIndex,
int intEnd);
int mulFactor(char *strInfix,
char *strPolish,
int *intPtrIndex,
int intEnd)
{ /* mulFactor = LETTER | NUMBER | '(' expression ')' */
int intIndexStart = 0;
int intLevel = 0;
char chrNext = ' ';
int intInner;
if (*intPtrIndex > intEnd)
return errorHandlerSyntax(*intPtrIndex,
"mulFactor unavailable");
chrNext = strInfix[*intPtrIndex];
if (chrNext >= 'a' && chrNext <= 'z')
{
(*intPtrIndex)++;
return appendPolish(strPolish, chrNext);
}
intIndexStart = *intPtrIndex;
while(*intPtrIndex <= intEnd
&&
(chrNext = strInfix[*intPtrIndex]) >= '0'
&&
chrNext <= '9')
{
if (!stringAppendChar(strPolish,
chrNext,
MAX_POLISH_LENGTH))
return 0;
(*intPtrIndex)++;
}
if (*intPtrIndex > intIndexStart)
return stringAppendChar(strPolish,
' ',
MAX_POLISH_LENGTH);
if (chrNext == '(')
{
intLevel = 1;
(*intPtrIndex)++;
intInner = *intPtrIndex;
while (intLevel > 0 && *intPtrIndex <= intEnd)
{
if ((chrNext = strInfix[(*intPtrIndex)++]) == '(')
{
intLevel++;
}
else
{
if (chrNext == ')')
{
intLevel--;
}
}
}
if (intLevel > 0)
return errorHandlerSyntax
(intInner - 1,
"Unbalanced left parenthesis");
if (!expression(strInfix,
strPolish,
&intInner,
*intPtrIndex - 2))
return errorHandlerSyntax
(intInner,
"Expression doesn't appear in parentheses");
//(*intPtrIndex)++;
return -1;
}
return 0;
}
int addFactor(char *strInfix,
char *strPolish,
int *intPtrIndex,
int intEnd)
{ /* addFactor = mulFactor [ *|/ mulFactor ] */
char chrMulOp = ' ';
int intStartIndex = 0;
if (!mulFactor(strInfix, strPolish, intPtrIndex, intEnd))
{
errorHandlerSyntax(*intPtrIndex, "mulFactor not found");
return 0;
}
if (*intPtrIndex > intEnd) return -1;
intStartIndex = *intPtrIndex;
while (*intPtrIndex <= intEnd)
{
if ((chrMulOp = strInfix[*intPtrIndex]) != '*'
&&
chrMulOp != '/')
return -1;
(*intPtrIndex)++;
if (*intPtrIndex > intEnd
||
!mulFactor(strInfix,
strPolish,
intPtrIndex,
intEnd))
return errorHandlerSyntax
(*intPtrIndex,
"Mul/div op not followed by mulFactor");
if (!appendPolish(strPolish, chrMulOp)) return 0;
}
return -1;
}
int expression(char *strInfix,
char *strPolish,
int *intPtrIndex,
int intEnd)
{ /* expression = addFactor [ +|- addFactor ] */
char chrAddOp = ' ';
int intStartIndex = 0;
if (!addFactor(strInfix, strPolish, intPtrIndex, intEnd))
{
errorHandlerSyntax(*intPtrIndex, "addFactor not found");
return 0;
}
intStartIndex = *intPtrIndex;
while (*intPtrIndex <= intEnd)
{
if ((chrAddOp = strInfix[*intPtrIndex]) != '+'
&&
chrAddOp != '-')
return -1;
(*intPtrIndex)++;
if (*intPtrIndex > intEnd
||
!addFactor(strInfix,
strPolish,
intPtrIndex,
intEnd))
return errorHandlerSyntax
(*intPtrIndex,
"Add/sub op not followed by addFactor");
appendPolish(strPolish, chrAddOp);
}
return -1;
}
char *infix2Polish(char *strInfix)
{
int intIndex = 0;
char *strPolish = malloc(MAX_POLISH_LENGTH);
if (strPolish == 0)
errorHandler("Can't get storage");
strPolish[0] = '\0';
if (!expression(strInfix,
strPolish,
&intIndex,
stringLength(strInfix) - 1))
{
errorHandler("Can't parse expression");
return "";
}
return strPolish;
}
void tester()
{
printf("Expect 10 113 + a *: %s\n",
infix2Polish("(10+113)*a"));
printf("Expect error (see above): %s\n",
infix2Polish("("));
printf("Expect error (see above): %s\n",
infix2Polish("((((2"));
printf("Expect error (see above): %s\n",
infix2Polish("////2"));
printf("Expect error (see above): %s\n",
infix2Polish(""));
printf("Expect error (see above): %s\n",
infix2Polish("("));
printf("Expect error (see above): %s\n",
infix2Polish("()"));
printf("Expect error (see above): %s\n",
infix2Polish("(((5))"));
printf("Expect 5: %s\n",
infix2Polish("(((5)))"));
printf("Expect 5: %s\n",
infix2Polish("((5))"));
printf("Expect 10 113 2 2 4 3 + / + 2 + 2 + - + a *: %s\n",
infix2Polish("((10+(113-(2+((((((2/(4+3)))))))+2+2))))*a"));
printf("Expect 1: %s\n",
infix2Polish("1"));
printf("Expect 1 1 +: %s\n",
infix2Polish("1+1"));
printf("Expect a: %s\n",
infix2Polish("a"));
printf("Expect a b +: %s\n",
infix2Polish("a+b"));
}
int main(int intArgCount, char **strArgs)
{
tester();
return;
}
Nick Keighley
> On 31 Oct 2009, Seebs <usenet-nos...@seebs.net> wrote:
>
> > On 2009-11-01, spinoza1111 <spinoza1...@yahoo.com> wrote:
> >> On Nov 1, 2:11 pm, Seebs <usenet-nos...@seebs.net> wrote:
>
> <snip>
>
> >> Arguably less than smart people because stupid people have to
> >> work at 7-11 where their actions are monitored, or on funny
> >> little embedded systems as opposed to actually important
> >> systems such as Microsoft boxes, and their work is constantly
> >> checked.
>
> Wow.
>
> > Oh, I see. You're trying to sneakily imply that I'm stupid.
> > No, not buying it. I certainly have my cognitive flaws, but
> > "stupidity" is not one of them.
>
> Am I interpreting spinoza1111's remark here correctly? It also
> seems he is slighting programmers who work on embedded systems. I
> suppose this shouldn't be surprising, but it's just so painfully
> absurd. The many contributions of embedded systems programmers (I'm
> not one, but do admire them) are demonstrably undeniable.
in many cases I'd be much more scared of bad programming practices in
an embedded system (think anti-lock brakes) than in a Microsoft box.
Nick Keighley
> On Nov 1, 4:34 pm, Seebs <usenet-nos...@seebs.net> wrote:
>
> > On 2009-11-01,spinoza1111<spinoza1...@yahoo.com> wrote:
>
> > > incompetence to study this code and find flaws.
>
> > I don't know the language you wrote it in, and also don't feel a lot of
> > need to try to find flaws in your code.
>
> > Write something in a language I know and post it in an appropriate group
>
> Furthermore, the idea that computer languages are even distinct is
> absurd. That they are is a historical accident, caused by the large
> number of errors made in language design in the early days.
>
> standing as an academic subject and should not be spoken of as a
> computer language. Instead, it should be considered a pathology which
> computer scientists must learn for the same reason doctors must learn
> cancer.
>
> education camps on the model of UN centres in Africa which train
> former guerrillas in useful trades.
>
> everyone. The guy on the screen in the 1984 Apple commercial was
> right.
Could you review this? (the utility library only provides the unit-
test and display-line functions)
*********************************************************************
;;; infix_postfix.scm
;;;
;;; infix to postscript converter
(load "library/utilities.scm")
;;;
;;; stack
(define (_stack-list s) (car s)) ; for internal use
(define (make-stack) '(()))
(define (stack-empty? s) (null? (_stack-list s)))
(define (stack-push! s item) (set-car! s (cons item (_stack-list s))))
(define (stack-top s)
(if (stack-empty? s) (error "empty stack"))
(car (_stack-list s)))
(define (stack-pop! s)
(let ((top (stack-top s)))
(set-car! s (cdr (_stack-list s)))
top))
;;;
;;; queue
; BEWARE: make-queue etc. are built-ins in chicken scheme
(define (_q-list q) (car q)) ; for internal use
(define (make-q) '(()))
(define (clear-q q) (set-car! q '()))
(define (q-empty? q) (null? (_q-list q)))
(define (q-add! q item)
(let ((new-q (append (_q-list q) (list item))))
(set-car! q new-q)))
(define (q-remove! q)
(if (q-empty? q) (error "empty queue"))
(let ((item (car (_q-list q))))
(set-car! q (cdr (_q-list q)))
item))
(define (q->list q) (_q-list q))
;;;
;;; token-stream
(define (make-tokstream s) (list s))
(define (tokstream-get! ts)
(define (empty? s) (zero? (string-length s)))
(let loop ((s (car ts)))
(if (empty? s)
'()
(let ((first (string-ref s 0)))
(if (char=? first #\space)
(loop (substring s 1 (string-length s)))
(begin
(set-car! ts (substring s 1 (string-length
s)))
first))))))
(define (tokstream->list ts) (car ts))
;;;
;;; infix to postfix conversion
;; the operators and their precedence
(define operators '((#\+ 1) (#\- 1) (#\* 2) (#\/ 2)))
;; converts infix to postfix using Dijkstra's Shunting Yard algorithm
;; the algorithm is from the Wikipedia article on the algorithm
(define (infix->postfix infix)
(let (
(in (make-tokstream infix))
(stack (make-stack))
(output (make-q)))
(define (operand? tok) (char-alphabetic? tok))
(define (operator? tok) (assq tok operators))
(define (open-brak? tok) (char=? tok #\()) ; beware
confuses syntax hiliter
(define (close-brak? tok) (char=? tok #\))) ; beware
confuses syntax hiliter
(define (precedence op) (cadr (assq op operators)))
(define (do-operand token) (q-add! output token))
(define (do-open-brak tok) (stack-push! stack tok))
(define (do-close-brak tok)
(let until-open-brak ((x '()))
(if (stack-empty? stack) (error "missing closing
bracket"))
(if (open-brak? (stack-top stack))
(stack-pop! stack) ; discard bracket
(begin
(q-add! output (stack-pop! stack))
(until-open-brak '())))))
(define (do-operator token)
(let while-operators ((x '()))
(if (and (not (stack-empty? stack)) (operator? (stack-
top stack)))
(if (<= (precedence token) (precedence (stack-top
stack)) )
(begin
(q-add! output (stack-pop! stack))
(while-operators x)))))
(stack-push! stack token))
(define (flush-stack)
(let loop ((x '())) ; x is a dummy argument
(if (not (stack-empty? stack))
(if (or (open-brak? (stack-top stack))
(close-brak? (stack-top stack)))
(error "infix->postfix: mismatched bracket")
(begin
(q-add! output (stack-pop! stack))
(loop '())
)))))
; turn the output queue into a string
(define (create-output-string)
(let loop ((s ""))
(if (not (q-empty? output))
(loop (string-append
s
(if (zero? (string-length s)) "" " ")
(string (q-remove! output))))
s)))
(define (trace-me token)
(display-line "infix-postfix: processing token" token
"stream" (tokstream->list in)
"output" (q->list output)))
; infix->postfix body
(clear-q output) ; bug work-around
(if (not (q-empty? output)) (error "output queue not empty!"))
(let while-tokens ((token (tokstream-get! in)))
;(trace-me token)
(if (not (null? token))
(begin
(cond
((operand? token) (do-operand token))
((operator? token) (do-operator token))
((open-brak? token) (do-open-brak token))
((close-brak? token) (do-close-brak token))
(else (error "unrecognised token")))
(while-tokens (tokstream-get! in)))))
; no more tokens
(flush-stack)
(create-output-string)
)) ; end infix->postfix
;;;
;;; test harness
(define (test-infix->postfix)
(unit-test infix->postfix string=? ("a + b * c") "a b c * +")
(unit-test infix->postfix string=? ("a + b - c") "a b + c -")
(unit-test infix->postfix string=? ("a * b - c") "a b * c -")
(unit-test infix->postfix string=? ("(a + b) * c") "a b + c *")
(unit-test infix->postfix string=? ("(a+b)+z-(c/d)") "a b + z + c
d / -")
'all-tests-ok)
*********************************************************************
This version doesn't handle numbers, function calls or right-
associative operators. The trace-me was used for debugging
spinoza1111
wrote:
>
> - Show quoted text -
Sure, if you pay me or review my C infix2Polish conversion.
Gene
> i have a string as (a+b)+8-(c/d) in Infix form.
>
> how can i convert it to postfix form using C language,,,????
I suppose that if this is homework, the due date has passed.
// Convert ;-separated infix expressions on stdin to postfix on
stdout.
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <stdarg.h>
// error handler
void die(char *msg)
{
fprintf(stderr, "\ndie: %s\n", msg);
exit(1);
}
// scanner
int lookahead;
int peek() { return lookahead; }
int peek_is(char *set)
{
return strchr(set, peek()) != NULL;
}
void advance(void)
{
do lookahead = getchar(); while (isspace(lookahead));
}
// parser for gramar:
// expr -> term { [+-] term }
// term -> factor { [*/] factor }
// factor -> ALNUM | "(" expr ")"
void term(void);
void factor(void);
void expr(void)
{
term();
while (peek_is("+-")) {
int op = peek();
advance();
term();
printf("%c", op);
}
}
void term(void)
{
factor();
while (peek_is("*/")) {
int op = peek();
advance();
factor();
printf("%c", op);
}
}
void factor(void)
{
if (isalnum(peek())) {
int literal = peek();
advance();
printf("%c", literal);
}
else if (peek() == '(') {
advance();
expr();
if (!peek_is(")")) die("expected )");
advance();
}
else
die("expected factor");
}
// user interface
int main(void)
{
advance();
do {
expr();
if (!peek_is(";")) die("expected ;");
printf("\n");
advance();
} while (peek() != EOF);
return 0;
}
Nick Keighley
<snip lump of code>
> > This version doesn't handle numbers, function calls or right-
> > associative operators. The trace-me was used for debugging
>
> Sure, if you pay me or review my C infix2Polish conversion
but, I wasn't claiming that knowledge of one language automatically
implied knowledge of another. Or that all languages were "essentially
the same"
Richard
> In article
> <fe798d09-500d-4fc1...@k13g2000prh.googlegroups.com>,
> spinoza1111 <spino...@yahoo.com> wrote:
>
>> This post contains the promised C code version of the infix to Polish
>> notation convertor.
>
> Promised to whom? I didn't ask for it.
And you are who exactly?
And why would you be so concerned as to who it was promised for? Or do
all posts needs to be cleared by your good self first?
--
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c
Richard Heathfield
<fe798d09-500d-4fc1...@k13g2000prh.googlegroups.com>,
spinoza1111 wrote:
> This post contains the promised C code version of the infix to
> Polish notation convertor. When run from the command line it should
> execute all cases used to test the C Sharp version correctly. Its
> string handling is simpler owing to the limitations of C.
>
> This code unless it is seriously fucked up demonstrates the
> practicality of using a formal language based approach to infix to
> Polish notation. It's also part of my project of relearning C.
>
> Comments as opposed to BS welcome.
>
>
> #include <stdio.H>
foo.c:1: stdio.H: No such file or directory
> #include <stdlib.H>
foo.c:3: stdlib.H: No such file or directory
Fixing those and moving on...
foo.c: In function `stringAppendChar':
foo.c:37: warning: passing arg 1 of `errorHandler' discards qualifiers
from pointer target type
foo.c: At top level:
foo.c: In function `appendPolish':
foo.c:54: warning: passing arg 2 of `stringAppendChar' with different
width due to prototype
foo.c:58: warning: passing arg 2 of `stringAppendChar' with different
width due to prototype
foo.c:60: warning: passing arg 2 of `stringAppendChar' with different
width due to prototype
foo.c: At top level:
foo.c: In function `mulFactor':
foo.c:79: warning: passing arg 2 of `errorHandlerSyntax' discards
qualifiers from pointer target type
foo.c:84: warning: passing arg 2 of `appendPolish' with different
width due to prototype
foo.c:95: warning: passing arg 2 of `stringAppendChar' with different
width due to prototype
foo.c:102: warning: passing arg 2 of `stringAppendChar' with different
width due to prototype
foo.c:125: warning: passing arg 2 of `errorHandlerSyntax' discards
qualifiers from pointer target type
foo.c:132: warning: passing arg 2 of `errorHandlerSyntax' discards
qualifiers from pointer target type
[Diagnostic message for // removed - code adjusted and recompiled]
foo.c: At top level:
foo.c:143: warning: no previous prototype for `addFactor'
foo.c: In function `addFactor':
foo.c:148: warning: passing arg 2 of `errorHandlerSyntax' discards
qualifiers from pointer target type
foo.c:168: warning: passing arg 2 of `errorHandlerSyntax' discards
qualifiers from pointer target type
foo.c:169: warning: passing arg 2 of `appendPolish' with different
width due to prototype
foo.c: In function `expression':
foo.c:183: warning: passing arg 2 of `errorHandlerSyntax' discards
qualifiers from pointer target type
foo.c:202: warning: passing arg 2 of `errorHandlerSyntax' discards
qualifiers from pointer target type
foo.c:203: warning: passing arg 2 of `appendPolish' with different
width due to prototype
foo.c: At top level:
foo.c:209: warning: no previous prototype for `infix2Polish'
foo.c: In function `infix2Polish':
foo.c:213: warning: passing arg 1 of `errorHandler' discards
qualifiers from pointer target type
foo.c:220: warning: passing arg 1 of `errorHandler' discards
qualifiers from pointer target type
foo.c:221: warning: return discards qualifiers from pointer target
type
foo.c: At top level:
foo.c:227: warning: function declaration isn't a prototype
foo.c: In function `tester':
foo.c:229: warning: passing arg 1 of `infix2Polish' discards
qualifiers from pointer target type
foo.c:231: warning: passing arg 1 of `infix2Polish' discards
qualifiers from pointer target type
foo.c:233: warning: passing arg 1 of `infix2Polish' discards
qualifiers from pointer target type
foo.c:235: warning: passing arg 1 of `infix2Polish' discards
qualifiers from pointer target type
foo.c:237: warning: passing arg 1 of `infix2Polish' discards
qualifiers from pointer target type
foo.c:239: warning: passing arg 1 of `infix2Polish' discards
qualifiers from pointer target type
foo.c:241: warning: passing arg 1 of `infix2Polish' discards
qualifiers from pointer target type
foo.c:243: warning: passing arg 1 of `infix2Polish' discards
qualifiers from pointer target type
foo.c:245: warning: passing arg 1 of `infix2Polish' discards
qualifiers from pointer target type
foo.c:247: warning: passing arg 1 of `infix2Polish' discards
qualifiers from pointer target type
foo.c:249: warning: passing arg 1 of `infix2Polish' discards
qualifiers from pointer target type
foo.c:251: warning: passing arg 1 of `infix2Polish' discards
qualifiers from pointer target type
foo.c:253: warning: passing arg 1 of `infix2Polish' discards
qualifiers from pointer target type
foo.c:255: warning: passing arg 1 of `infix2Polish' discards
qualifiers from pointer target type
foo.c:257: warning: passing arg 1 of `infix2Polish' discards
qualifiers from pointer target type
foo.c: In function `main':
foo.c:263: warning: `return' with no value, in function returning
non-void
foo.c:260: warning: unused parameter `intArgCount'
foo.c:260: warning: unused parameter `strArgs'
spinoza1111
>
> - Show quoted text -
Thanks for this. Looks like you stole my approach, but I find that
most gratifying if true, and an indication that "great minds think
alike" if not. Your contribution at a minimum is to show just how
gnomic and terse one can be in C. It would not be appropriate to
credit me since it is a common and solid algorithm that has been
around for years.
Hope you don't mind, but I'm going to copy this code and incorporate
it in what will not be a three way test: of my C Sharp version, my C
version and your gnomic C. I want to add more testing (using a random
generator in C Sharp), a GUI and timing comparisions and shall report
back.
spinoza1111
Again it looks like you stole this, and again I forgive you, or ask
your forgiveness if I have accused you falsely. If you swiped it from
my grammar, you forgot to put an asterisk after the right curley
braces to indicate that there can be zero, one or more occurences of
the term or factor, preceded by its binary operator.
If you did not swipe it, then you may be using curley braces to
indicate zero one or more repetitions of the braced content; but this
would be your unique idiom, I've never seen it.
Your code supports zero one or more and this looks correct.
Also, the standard meaning of square brackets is that the bracketed
material is optional: but the binary operators you have bracketed are
most assuredly not optional as I think you know.
spinoza1111
> In article <hcma6f$j3...@news.eternal-september.org>,
> Curtis Dyer <dye...@gmail.com> wrote:
>
>
>
>
>
> > On 31 Oct 2009, Seebs <usenet-nos...@seebs.net> wrote:
>
> > > On 2009-11-01,spinoza1111<spinoza1...@yahoo.com> wrote:
> > >> On Nov 1, 2:11 pm, Seebs <usenet-nos...@seebs.net> wrote:
>
> > <snip>
>
> > >> Arguably less than smart people because stupid people have to
> > >> work at 7-11 where their actions are monitored, or on funny
> > >> little embedded systems as opposed to actually important
> > >> systems such as Microsoft boxes, and their work is constantly
> > >> checked.
>
> > Wow.
>
> > > Oh, I see. You're trying to sneakily imply that I'm stupid.
> > > No, not buying it. I certainly have my cognitive flaws, but
> > > "stupidity" is not one of them.
>
> > seems he is slighting programmers who work on embedded systems. I
> > suppose this shouldn't be surprising, but it's just so painfully
> > absurd. The many contributions of embedded systems programmers (I'm
> > not one, but do admire them) are demonstrably undeniable.
>
> That seems to be anyone who cannot do the Computer Science equivalent of
> deducing the properties of the universe from the definition of a point.
> Then he wonders why we sneer at him.
>
> In the 18th century, people used to visit Bedlam with pointed sticks,
> poking the lunatics inside to make them gibber. With Spinny, even that
> is unnecessary. Any rational response causes him to gibber
> uncontrollably.
So you're nothing more than a Regency lout?
>
> Watching Spinny's train of "logic", I'm reminded of the Soviets'
> constant denigration of the West as "warmongers", the rationale for
> which which went something like as follows:
>
> 1) We are in conflict with you
> 2) If you were to agree with our point of view, the conflict would cease
> 3) Since you choose not to take an action which would remove the
> conflict, you are actively seeking to prolong the conflict
> 4) In actively seeking to prolong the conflict, you are therefore a
> warmonger
>
This logic merely mirrored that of the West. The question is "who
started it". As it happened, the West started the Cold War in 1950 by
arming the Greek right wing, resulting in the murder of a Western
journalist, several years of slaughter in Greece, and military
dictatorship in that country.
I find here that friendly attempts to discuss code are met by the
creation of a permanent record which could threaten my employment. As
it happens, I am good at what I do, and this includes more than being
a code monkey, so in fact my Internet record has never harmed my
employment and has gotten my hired at at least one job
But I find other people including real contributors like Navia being
treated in like fashion. I also have "inside" information on the
effect of the anti-Schildt campaign, long a staple of clc, the sources
of which I am not at liberty to disclose, and this effect amounts to
that of civil and criminal libel under UK and American law.
Next time do your homework.
> There must be a word which describes this sort of thought process.
>
> --
> Tim
>
> "That excessive bail ought not to be required, nor excessive fines imposed,
> nor cruel and unusual punishments inflicted" -- Bill of Rights 1689- Hide quoted text -
Richard Heathfield
<75284980-34e3-44bc...@u36g2000prn.googlegroups.com>,
spinoza1111 wrote:
> On Nov 2, 10:10 pm, Gene <gene.ress...@gmail.com> wrote:
<snip>
>> // parser for gramar:
>> // expr -> term { [+-] term }
>> // term -> factor { [*/] factor }
>
> Again it looks like you stole this,
It's a minor re"word"ing of p72 of the Dragon Book [Aho, Sethi, Ullman
1986].
Kenny McCormack
Richard <rgr...@gmail.com> wrote:
>Tim Streater <timst...@waitrose.com> writes:
>
>> In article
>> <fe798d09-500d-4fc1...@k13g2000prh.googlegroups.com>,
>> spinoza1111 <spino...@yahoo.com> wrote:
>>
>>> This post contains the promised C code version of the infix to Polish
>>> notation convertor.
>>
>> Promised to whom? I didn't ask for it.
>
>And you are who exactly?
>
>And why would you be so concerned as to who it was promised for? Or do
>all posts needs to be cleared by your good self first?
It really makes the regs (and, most especially, the reg-wannabees like
Mr. Streater here) nervous to be seen as in any way requesting anything
(other than order-in-the-court, of course). That is, it destroys their
game to be seen as being in the position of asking for something as
opposed to always being the givers of knowledge.
Notice the recent hoo-hah about whether or not Kiki/RH had requested
anything from Jacob. Notice how much virtual ink was expended
discussing what was, in fact, just a small, jocular, off-the-cuff remark
from Jacob.
Kiki was obviously much distressed by both of the following
implications, and spared no effort to try to dispel both:
1) That they (Kiki and/or RH) had requested something from lowly Jacob.
2) That, in response to and in fulfillment of said request, Jacob
had actually, out of the goodness of his heart, produced something
of value.
Richard
Yowza. I can see that would have created a stir. Along that vein of
thought, I'm amazed that they tolerate Keighley aiding and abetting
them recently - almost as if he had his own seat at the high table.
Gene
>
This doesn't qualify as anything like theft or great thinking. For
fun, I wrote the code in about 5 minutes after the OP posted (based on
http://groups.google.com/group/comp.lang.c/msg/fe772c9d6a28fdc4), but
refrained from posting it because it was probably homework for the
OP. This is a standard example or homework assignment for just about
any undergrad course that covers recursive descent parsing. The
gramamr with minor variations is in at least a dozen complier design
textbooks including ASU. Usually it's given in left-recursive form,
and then the author or student go through the L-rec removal, left-
factoring, and BNF conversion. RPN generation is a trivial example of
attribute evaluation.