Oh yea lets now forget how you bashed chessbase for the hiarcs posting
that
is newer than this one.....




Yes, it will by hyped as the latest Chessbase release, and probably
posted
at the top of the next SSDF list (a paid-for subsidiary of Chessbase) --
just in time for the holiday 2003 sales season. Well, that's my theory
anyway. That's how Shredder 7 as #1 happened, probably. They
conveniently
failed to match Shredder 7 vs Deep Fritz 7.0 which would probably have
knocked it further down the list.
--
Euc1id


-David-


--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

"Johnson Johnny" wrote in message news:68bac2be3a1f666ac34586bfbee6728e.33179@mygat e.mailgate.org...
I disagree. The Fritz engines had the same kind of problem, but they
eventually fixed it. It is indefensible for such nonsense to appear in
the
engines pane as legitimate analysis.


Who says that it's legitimate analysis? What's the authority for its
being dubbed as legitimate analysis?

It's an indication of how the engine is *working*, nothing more,
nothing less.

Mark

(Liam Too) wrote in message . com...
(Mark Houlsby) wrote in message
I would agree with this. For me, it's important to remember that
Shredder's analysis lines, like Fritz' analysis lines or, for that
matter, Kasparov's analysis lines are not "set in stone", so to speak,
inasmuch as chess has not yet been solved. It's always best to check
*any* analysis *oneself*, I find.

I just got a feeling of "deja vu" ;-)--Mark

Mark,

Chess is solved with the advent of the 32 Tablebases that is being
developed as we speak.

It's just a matter of storage and time now, perhaps a gigazillion
exabytes and/or exazillion years?

Lance Smith

Gordon,

Have you met Lance? He's an illiterate idiot who, for some reason,
considers his incoherent ramblings as a serious attempt to troll me.
He's rather odd, and more than a little embarrassing.

Cheers,
Mark

"Euc1id" wrote in message
ink.net...

I've given that some thought... If there is concern about interrupting the
engine's critical algorithm in progress, slowing it down too much: One way
would be to let the GUI apply some simple universal tests (usable with any
engine) to the line of analysis before it is printed to the screen (or
output buffer), then concatenate it if a nonsense move is encountered.
I've
already mentioned some simple tests: "mate in 1", and giving away material
for free (particularly the queen). There could be a user controlled
variable
to switch this feature on/off. My guess is a 0.1% slowdown or less is
possible, which should be acceptable to all concerned. Consider that a
line
of analysis is burped out into the real world in the GUI's engine pane in
infinite analysis mode relatively infrequently. Often it takes several
minutes between those outputs, sometimes an hour or more. [That needs to
be
fixed too! Surely an updated best line of analysis should be output at
least
every 5-10 minutes, or that option offered to user.]
--
Euc1id


I think you are wrong, the deeper the search goes, the more time it takes to
evaluate a single move in a given position, because every move produces its
own tree that grows significantly (every next ply takes roughly a square
root of the number of legal moves available), so askind the engine to
produce update of the best line is nonsense, as there is no new data to
update the best line because it considered moves 5 throu 7 in that time
frame (unless move No. 5 suddenly turns out to be better, in which case the
best line is updated without asking engine to do that).

Leonardo

"Leonardo Ljubicic" wrote in message
...
|
| "Euc1id" wrote in message
| ink.net...
|
| I've given that some thought... If there is concern about interrupting
the
| engine's critical algorithm in progress, slowing it down too much: One
way
| would be to let the GUI apply some simple universal tests (usable with
any
| engine) to the line of analysis before it is printed to the screen (or
| output buffer), then concatenate it if a nonsense move is encountered.
| I've
| already mentioned some simple tests: "mate in 1", and giving away
material
| for free (particularly the queen). There could be a user controlled
| variable
| to switch this feature on/off. My guess is a 0.1% slowdown or less is
| possible, which should be acceptable to all concerned. Consider that a
| line
| of analysis is burped out into the real world in the GUI's engine pane
in
| infinite analysis mode relatively infrequently. Often it takes several
| minutes between those outputs, sometimes an hour or more. [That needs to
| be
| fixed too! Surely an updated best line of analysis should be output at
| least
| every 5-10 minutes, or that option offered to user.]
| --
| Euc1id
|
|
| I think you are wrong, the deeper the search goes, the more time it takes
to
| evaluate a single move in a given position, because every move produces
its
| own tree that grows significantly (every next ply takes roughly a square
| root of the number of legal moves available), so askind the engine to
| produce update of the best line is nonsense, as there is no new data to
| update the best line because it considered moves 5 throu 7 in that time
| frame (unless move No. 5 suddenly turns out to be better, in which case
the
| best line is updated without asking engine to do that).
|
| Leonardo

You didn't understand my line of thought. I was not asking the engine to do
anything! The GUI could have a simple "filter" that would evaluate a line of
analysis to concatenate it when a stupid blunder is found, before it is
printed out to the screen for the user to see. Of course the engine could
have a subroutine to do this also, which would be preferable. Actually the
fact that the line of analysis needs to be "filtered" indicates to me that
there is a bug in the engine itself which needs to be fixed. I guess not
everybody agrees with the latter, but I've written chess software so am not
totally ignorant of the algorithms involved, and that's my opinion at this
point. It may be that the engine has a bug in its process of storing then
outputting this analysis data to the GUI, i.e. it's simply outputting the
wrong data. It can be tricky to code right...
--
Euc1id

In article , Euc1id wrote:
"Leonardo Ljubicic" wrote in message
...
|
| "Euc1id" wrote in message
| ink.net...
|
| I've given that some thought... If there is concern about interrupting
the
| engine's critical algorithm in progress, slowing it down too much: One
way
| would be to let the GUI apply some simple universal tests (usable with
any
| engine) to the line of analysis before it is printed to the screen (or
| output buffer), then concatenate it if a nonsense move is encountered.
| I've
| already mentioned some simple tests: "mate in 1", and giving away
material
| for free (particularly the queen). There could be a user controlled
| variable
| to switch this feature on/off. My guess is a 0.1% slowdown or less is
| possible, which should be acceptable to all concerned. Consider that a
| line
| of analysis is burped out into the real world in the GUI's engine pane
in
| infinite analysis mode relatively infrequently. Often it takes several
| minutes between those outputs, sometimes an hour or more. [That needs to
| be
| fixed too! Surely an updated best line of analysis should be output at
| least
| every 5-10 minutes, or that option offered to user.]
| --
| Euc1id
|
|
| I think you are wrong, the deeper the search goes, the more time it takes
to
| evaluate a single move in a given position, because every move produces
its
| own tree that grows significantly (every next ply takes roughly a square
| root of the number of legal moves available), so askind the engine to
| produce update of the best line is nonsense, as there is no new data to
| update the best line because it considered moves 5 throu 7 in that time
| frame (unless move No. 5 suddenly turns out to be better, in which case
the
| best line is updated without asking engine to do that).
|
| Leonardo

You didn't understand my line of thought. I was not asking the
engine to do anything! The GUI could have a simple "filter"
that would evaluate a line of analysis to concatenate it when a
stupid blunder is found, before it is printed out to the screen
for the user to see.

Hmmm. So your solution to solving world hunger would start with
solving world hunger?

--
Neil Cerutti

(Mark Houlsby) wrote in message . com...

Gordon,

Have you met Lance? He's an illiterate idiot who, for some reason,
considers his incoherent ramblings as a serious attempt to troll me.
He's rather odd, and more than a little embarrassing.

Cheers, Mark

LOL! so you've seen my debate with Nick.

From: Neil Cerutti
Date: 06/10/03 17:00 GMT Daylight Time
Message-id:

In article , Euc1id wrote:
"Leonardo Ljubicic" wrote in message
...
|
| "Euc1id" wrote in message
| ink.net...
|
| I've given that some thought... If there is concern about interrupting
the
| engine's critical algorithm in progress, slowing it down too much: One
way
| would be to let the GUI apply some simple universal tests (usable with
any
| engine) to the line of analysis before it is printed to the screen (or
| output buffer), then concatenate it if a nonsense move is encountered.
| I've
| already mentioned some simple tests: "mate in 1", and giving away
material
| for free (particularly the queen). There could be a user controlled
| variable
| to switch this feature on/off. My guess is a 0.1% slowdown or less is
| possible, which should be acceptable to all concerned. Consider that a
| line
| of analysis is burped out into the real world in the GUI's engine pane
in
| infinite analysis mode relatively infrequently. Often it takes several
| minutes between those outputs, sometimes an hour or more. [That needs to
| be
| fixed too! Surely an updated best line of analysis should be output at
| least
| every 5-10 minutes, or that option offered to user.]
| --
| Euc1id
|
|
| I think you are wrong, the deeper the search goes, the more time it takes
to
| evaluate a single move in a given position, because every move produces
its
| own tree that grows significantly (every next ply takes roughly a square
| root of the number of legal moves available), so askind the engine to
| produce update of the best line is nonsense, as there is no new data to
| update the best line because it considered moves 5 throu 7 in that time
| frame (unless move No. 5 suddenly turns out to be better, in which case
the
| best line is updated without asking engine to do that).
|
| Leonardo

You didn't understand my line of thought. I was not asking the
engine to do anything! The GUI could have a simple "filter"
that would evaluate a line of analysis to concatenate it when a
stupid blunder is found, before it is printed out to the screen
for the user to see.

Hmmm. So your solution to solving world hunger would start with
solving world hunger?

--
Neil Cerutti


ROTFLMAO!!!!

Good one!!!!!!

Mark Houlsby

From: (Liam Too)
Date: 06/10/03 18:32 GMT Daylight Time
Message-id:

(Mark Houlsby) wrote in message
.com...

Gordon,

Have you met Lance? He's an illiterate idiot who, for some reason,
considers his incoherent ramblings as a serious attempt to troll me.
He's rather odd, and more than a little embarrassing.

Cheers, Mark

LOL! so you've seen my debate with Nick.


'Edmund: Seen it, pinched it, spent it.'
--Richard Curtis and Ben Elton (Blackadder II, BBCTV)

Opprobrium.

It's a really big word! Look at all of those letters in a row!

Look it up! Go on...off you go!

Moron.