A Simple Experiment for Advancing the Discussion

[chrisw]

No it doesn't. It applies perfectly to writing a fucntion such as Go-parser. Take a look at someone else's code for the same thing and ....... similar code production by second programmer.

It's a great concept. It's fractal, applies at whatever level is being considered.

Chris,

Did you read this post?
http://www.talkchess.com/forum/viewtopi ... 747#213747

Yes. I didn't answer it because it felt it was too far off stage left from the point I was making in the post you answered.

I don't think you answer a piece about two code lines on "infinite" parsing and variable setting with 30 lines of program.

"infinite" and "ponder" parsing is forced and produces pretty much the same code. Was all I was trying to say.

[bob]

do it fast, do it first. The underlying reason for the development of the field of "software engineering". I've done large-scale software development as well, not as part of an academic undertaking either, and where results would lead to continuation of the project or cancellation. And we did have standards. High standards. For support reasons...

[chrisw]

do it fast, do it first. The underlying reason for the development of the field of "software engineering". I've done large-scale software development as well, not as part of an academic undertaking either, and where results would lead to continuation of the project or cancellation. And we did have standards. High standards. For support reasons...

Ok, thanks for the good tone. Although we've had some fun today, you and I owe it to the forum to behave ourselves a bit. I'm game for keeping the level ok. You too.

Support is very important, as is getting out bug-free stuff. Did you ever work with the Japenese? Unbelievable attitude to development and bugs. Absolute zero-tolerance. The english are absolutely the worst, the final version is the beta basically. Culture clash massive when one works with Japanese. However, I learnt more about getting stuff out and right and making it work in all variations from one Japanese manager they put to oversee their contracts. Great people. Revolutionised my company for sure.

[Zach Wegner]

Yes. I didn't answer it because it felt it was too far off stage left from the point I was making in the post you answered.

I don't think you answer a piece about two code lines on "infinite" parsing and variable setting with 30 lines of program.

"infinite" and "ponder" parsing is forced and produces pretty much the same code. Was all I was trying to say.

Then this whole thread should be deleted. The code comparison between Rybka and Fruit involves far more than even my 30 lines of code. And even then, the way it parses infinite and ponder are different.

This argument is really just a bunch of nonsense. You are saying that if you take what, 5 lines from the comparison out of 100+, then it doesn't matter if those lines are similar, because it's a completely obvious way to do it. But given that in the only other example you have it's done differently, what the hell are you arguing about? You say that the UCI parser similarity is "utterly trivial". It's only trivial if you ignore 95% of the code.

And perhaps you also have a good explanation for why the int value ("creatively" called movetime by Rick Fadden, named after the UCI parameter of the same name...) is compared to a float 0.0?? You should probably also come up with an explanation for how the other points I made in that post are so "utterly obvious", if you want to say that the UCI code example is trivial...

[Uri Blass]

string.h should be included. I get no errors from ICC when compiling without it and did notice. The only risk is that the compiler assumes I am using strcmp() properly (which I am) so I might miss an important warning.

argc is the number of command line arguments +1.

argv[0] is a pointer to a string containing the name of the executable you are running.

argv[1] is a pointer to the first argument.

argv[2] same for second.

argc would be 4 since there are four total arguments, counting the name of the executable...

to run it, you just type "calc one + two" if you called the executable "calc".

It runs on my linux laptop with no problem.

I could run it from the command line by start->programs->accessories->command prompt.

Your code does not do exactly the task that it is asked.
The task is to translate one plus two to 3 when you translate one + two to 3.

Uri

[RegicideX]

1) The functions being compared are very similar in purpose and they are similar in purpose in most if not all chess programs.

OK, show us some similar code in, lets say, Crafty and Fruit. Or Glaurung and Slowchess. Or TSCP and Pepito.

I wait, ty.

"Similar in purpose" is not "similar in code." Read what I wrote.

Also, you should obviously interpret this similarity of purpose for chess programs that are UCI compatible -- otherwise you're using semantic nitpicking.

Emotions fly of the handle enough as it is -- there is no need for bad reading.

[chrisw]

Yes. I didn't answer it because it felt it was too far off stage left from the point I was making in the post you answered.

I don't think you answer a piece about two code lines on "infinite" parsing and variable setting with 30 lines of program.

"infinite" and "ponder" parsing is forced and produces pretty much the same code. Was all I was trying to say.

Then this whole thread should be deleted. The code comparison between Rybka and Fruit involves far more than even my 30 lines of code. And even then, the way it parses infinite and ponder are different.

This argument is really just a bunch of nonsense. You are saying that if you take what, 5 lines from the comparison out of 100+, then it doesn't matter if those lines are similar, because it's a completely obvious way to do it. But given that in the only other example you have it's done differently, what the hell are you arguing about? You say that the UCI parser similarity is "utterly trivial". It's only trivial if you ignore 95% of the code.

And perhaps you also have a good explanation for why the int value ("creatively" called movetime by Rick Fadden, named after the UCI parameter of the same name...) is compared to a float 0.0?? You should probably also come up with an explanation for how the other points I made in that post are so "utterly obvious", if you want to say that the UCI code example is trivial...

I don't understand what you are doing. You told us you are producing and have more material and will be publishing it. I've said on many occasions now I don't want to keep having discussions until your new material is out. Vas says he is waiting for it. Yet, your side is continually harping back to this really quite weak, or maybe from your point of view, not exactly universally accepted UCI example. It clear that you know/knew that you needed more or something else to make progress with your case.

You realise it won't just be me who intuits that your hunt for more evidence has ground to a halt? Don't you? Why else are you here banging on about the old stuff? Why here now again on the old stuff? If not because the other hunt has failed?

If it has, and you're not making progress, I think you owe it to the person attacked and his business to say so.

[Zach Wegner]

Or perhaps you could now say that the UCI code is not "trivial". There are in fact remarkable similarities that I think you will be hard pressed to find in any other engine.

Stick to the topic, please.

[chrisw]

Or perhaps you could now say that the UCI code is not "trivial". There are in fact remarkable similarities that I think you will be hard pressed to find in any other engine.

Stick to the topic, please.

The UCI code is not the engine.

It is trivial. The similarties are slight and do not necessarily indicate cut 'n paste as the anti-antis side has shown.

[Zach Wegner]

Do you have an explanation for the specific similarities I pointed out?