Sorry, I made a confusion between various versions of Scid, and I thought
the engine output history was removed since a long time for UCI engine. And
indeed it is, as I find this kind of output (history) is confusing and of
little use (I am not aware of any chess app that displays full history).
Pascal
2008/6/25 Roy Brunjes <[EMAIL PROTECTED]>:
> Pascal,
>
> I disagree that this is a mis-configuration. Showing multiple PVs is one
> thing, what I am asking for is entirely different. Please look closely at
> the example again and I think you should see what I am asking for is NOT
> just setting multiPV mode to 4 or something similar. MultiPV set to 4 slows
> down the search as well which a single PV analysis with history enabled (to
> show the results of each previous ply) does not.
>
> Also, how can it be a misconiguration if it worked differently in 3.6.23
> and no changes were made to the configuration for 3.6.24? If there is no
> configuration change, the behavior of the software should be the same -- at
> least that is what most people expect with software upgrades in my
> experience.
>
> Respectfully,
>
> Roy
>
>
> ----- Original Message ----
> From: "[EMAIL PROTECTED]" <
> [EMAIL PROTECTED]>
> To: [email protected]
> Sent: Tuesday, June 24, 2008 3:15:57 PM
> Subject: Scid-users Digest, Vol 23, Issue 29
>
> Send Scid-users mailing list submissions to
> [email protected]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/scid-users
> or, via email, send a message with subject or body 'help' to
> [EMAIL PROTECTED]
>
> You can reach the person managing the list at
> [EMAIL PROTECTED]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Scid-users digest..."
> Today's Topics:
>
> 1. Re: Tiny enhancements (Pascal Georges)
> 2. Re: A CentriScid Project (Pascal Georges)
> 3. Re: A CentriScid Project (Alexander Wagner)
> 4. Re: Tiny enhancements (Alexander Wagner)
>
>
> -----Inline Message Follows-----
>
> Sounds a good idea. Maybe this could also switch to the
> analyis mode Roy asked for?
>
> I don't know what this analysis mode is, could you explain me?
>
> Ah it was a recent threat on the list. Here's the essential
> quote:
>
> ----------------------------------------------------------------------
> I tried to post screen shots to show the differences but
> that may not make it to the rest of you (some sort of
> moderator action may be needed I think). So, here are the
> differences (typed by hand):
>
> 3.6.24 shows this (only one line of output in the analysis window) for a
> 13 ply search:
> 13 +0.13 Nf3 Nc6 g3 Nf6 Bg5 d5 O-O d4 d3 h5 Bg5 Qd6
>
> 3.6.23 shows this for a search:
>
> 13 +0.11 Nc3 Nf6 Nf3 e6 e4 Nc6 <etc>
>
> 13 +0.12 d4 Nf6 Nc3 e6 Nf3 Bb4 <etc>
>
> 14 +0.11 d4 Nf6 Nc3 e6 Nf4 Bb4 <etc>
>
> That is different! Is there a way to make .24 work like .23?
>
> Thanks!
> ----------------------------------------------------------------------
> For me, until further notice it is a simple problem of user
> misconfiguration of MultiPV for an UCI engine.
>
> Pascal
>
>
>
> -----Inline Attachment Follows-----
>
>
>
> 2008/6/24 Alexander Wagner <[EMAIL PROTECTED]>:
>
>> Giorgio Bellegotti wrote:
>>
>> Hi!
>>
>> Sounds a good idea. Maybe this could also switch to the
>>>> analyis mode Roy asked for?
>>>>
>>>>
>>> I don't know what this analysis mode is, could you explain me?
>>>
>>
>> Ah it was a recent threat on the list. Here's the essential
>> quote:
>>
>> ----------------------------------------------------------------------
>> I tried to post screen shots to show the differences but
>> that may not make it to the rest of you (some sort of
>> moderator action may be needed I think). So, here are the
>> differences (typed by hand):
>>
>> 3.6.24 shows this (only one line of output in the analysis window) for a
>> 13 ply search:
>> 13 +0.13 Nf3 Nc6 g3 Nf6 Bg5 d5 O-O d4 d3 h5 Bg5 Qd6
>>
>> 3.6.23 shows this for a search:
>>
>> 13 +0.11 Nc3 Nf6 Nf3 e6 e4 Nc6 <etc>
>>
>> 13 +0.12 d4 Nf6 Nc3 e6 Nf3 Bb4 <etc>
>>
>> 14 +0.11 d4 Nf6 Nc3 e6 Nf4 Bb4 <etc>
>>
>> That is different! Is there a way to make .24 work like .23?
>>
>> Thanks!
>> ----------------------------------------------------------------------
>
>
> For me, until further notice it is a simple problem of user
> misconfiguration of MultiPV for an UCI engine.
>
> Pascal
>
>
>
> -----Inline Attachment Follows-----
>
>
>
> 2008/6/24 Alexander Wagner <[EMAIL PROTECTED]>:
>
>>
>> Hi!
>>
>> 2008/6/24 Alexander Wagner <[EMAIL PROTECTED] <mailto:
>>> [EMAIL PROTECTED]>>:
>>>
>>> CentriScid_ID 123456
>>> CentriScid_Version 10
>>> CentriScid_TacticPly 23
>>> CentriScid_TacticSolution Nxf3 ...
>>> CentriScid_OpeningBlunder 7
>>> CentriScid_OpeningBlunderSideToMove black
>>>
>>>
>>> This has a major disadvantage. How do I cite that game? By
>>> just printing out the whole block? Consider I'd want to show
>>> the game easily with a single tag you could do something
>>> like
>>>
>>> $ scid CentriScid -search CentriScid:12-123456
>>>
>>>
>>> The CentriScid_ID tag is a key. It is sufficient to designate a game.
>>>
>>
>> Nope.
>>
>> The version n+1 superseedes the previous one. If you use (version, Id)
>>> tuple as a key you consider several distinct games, from a DB point of view.
>>>
>>
>> Exactly. This implies versioning support. One idea is to
>> even have all versions in one DB and create a release by
>> means of a suitable select/view.
>
>
> It would be awfully inefficient. I don't see the point in having N versions
> of a game. You would need proper indexes. And moreover if you have 3 M
> games, with several versions for each, searches will get slower as you add
> versions.
>
>
>>
>>
>> Searching for additional PGN tags is terribly slow. I do
>>> this all the time when I add [Ref]-tags to my larger DB to
>>> crosscheck that I did not miss to flag the games in question
>>> correctly and it is plain PITA. Sorry. Just searching the DB
>>> takes about half an hour to come to the result list. :(
>>>
>>> I was not aware of this. Do you have enough RAM related to the size of
>>> the base ?
>>>
>>
>> Well, I think that about 1.5G are enough, the base in
>> question is about 700M or 3.5Mio games. Searching via flags
>> is very fast, searching by player names etc is very fast.
>> Searching by additional header tags is slow as they are not
>> indexed.
>>
>
> I agree for a 3 M games DB. But for smaller dedicated bases, tags are good
> enough. For example I just took a 300.000 games DB and added a tag (Medal ->
> Gold) every 100 games (not by hand !). The search as plain PGN text takes
> only 36 sec on my laptop. So one solution is to have a big ref DB and
> specialized DB for openings, tactics, endings, etc.
>
> Using Scid, if I had a 10.000 games DB for each of those fields :
> - tactics,
> - my favorite openings explained with traps,
> - endings I should know,
> I would be very happy. And even such a goal seems very ambitious. So why
> try to get something scalable to 3 M games DB ?
>
> In annotation feature I added an opening blunder detection. Given the time
> taken to go through games, I never exceeded 1000 games checked with this. Of
> course you would not use this on a big Ref DB, but on a small DB where one
> opening line is pre-selected (say 20000 games). And the games flagged with
> "opening blunder" are rare.
>
> The real concern here is to have a Ref DB (big) and several dedicated DBs.
> So some games are duplicated, with the same CentriScid_ID. Not an ideal
> solution, but I don't want to set a costly high level solution if there is
> no real matter behind it : Scid has no Ref DB on its own, no opening DB, the
> only books provided are certainly not the best (I know what I am talking
> about ;- ) ) and the only "tactics" bases are those I auto-generated (just
> mate in N moves), hence their poor quality.
>
> So I don't want to build a car if nobody has gasoline.
>
>
>>
>> My main concern here is that I'd like to have something
>>> easy to implement, and to add a metadata file along with
>>> the 3 existing files is not a piece of cake.
>>>
>>
>> No, no, actually I'd like to place the CentriScid-ID as one
>> PGN Header tag. I suggested to set for a game in question
>>
>> [CmailGameName "CentriScid:12-123456"]
>>
>> (CmailGameName just as it is already used for a UID, but
>> this is up to discussion.)
>>
>> I'd just prefer to add just _one_ line there and not
>> several. This eases up entry among other features (see
>> below). I'd prefer to have a generic ID-field and not a
>> specific one, as this could be indexed. E.g. if you name it
>> "CentriScidID" it is only usable in CentriScid as otherwise
>> it is not unique anymore. Therefore the DB-name that it
>> refers to has to be part of the ID. If you drop the version
>> from the UID you can not handle versioning with it anymore,
>> IMHO this is desirable. And well, one unique number has to
>> be there.
>>
>
> I did not get where you put special markers like "rook ending at move 34",
> "tactical shot : xray" ?
>
> Pascal
>
> _______________________________________________
> Scid-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/scid-users
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Scid-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/scid-users
>
>
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Scid-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/scid-users
