Using SEE to prune in main search

[outAtime]

ok, just thought id give a heads up, it could have been a false positive, although Avira Antivirus is supposedly a top antivirus. Ill dl the zip again and see what happens.

[outAtime]

http://sourceforge.net/projects/zct/files/

click on:

Looking for the latest version? Download zct-032451_ja.zip (975.8 KB)

downloaded and then scanned zip file with avira:

Starting the file scan:

Begin scan in 'C:\Documents and Settings\Administrator\My Documents\Downloads\zct-032451_ja.zip'
C:\Documents and Settings\Administrator\My Documents\Downloads\zct-032451_ja.zip
[0] Archive type: ZIP
[DETECTION] Is the TR/Crypt.XPACK.Gen Trojan
--> zct-032451_ja/zct32_ja.exe
[DETECTION] Is the TR/Crypt.XPACK.Gen Trojan
--> zct-032451_ja/zct32_smp_ja.exe
[DETECTION] Is the TR/Crypt.XPACK.Gen Trojan

Beginning disinfection:
C:\Documents and Settings\Administrator\My Documents\Downloads\zct-032451_ja.zip
[DETECTION] Is the TR/Crypt.XPACK.Gen Trojan
[NOTE] The file was moved to the quarantine directory under the name '47241950.qua'.


End of the scan: January 11, 2011 15:28

That's about all I can do to try to help, maybe try something other than an online scanner to detect this. Kapersky is supposed to be a good antivirus, so i dont know. I guess all I can say is anyone using the popular antivirus avira will likely think this is packaged with something unwanted I dont know why there is this detection.

[silentshark]

http://sourceforge.net/projects/zct/files/

click on:

Looking for the latest version? Download zct-032451_ja.zip (975.8 KB)

downloaded and then scanned zip file with avira:

Starting the file scan:

Begin scan in 'C:\Documents and Settings\Administrator\My Documents\Downloads\zct-032451_ja.zip'
C:\Documents and Settings\Administrator\My Documents\Downloads\zct-032451_ja.zip
[0] Archive type: ZIP
[DETECTION] Is the TR/Crypt.XPACK.Gen Trojan
--> zct-032451_ja/zct32_ja.exe
[DETECTION] Is the TR/Crypt.XPACK.Gen Trojan
--> zct-032451_ja/zct32_smp_ja.exe
[DETECTION] Is the TR/Crypt.XPACK.Gen Trojan

Beginning disinfection:
C:\Documents and Settings\Administrator\My Documents\Downloads\zct-032451_ja.zip
[DETECTION] Is the TR/Crypt.XPACK.Gen Trojan
[NOTE] The file was moved to the quarantine directory under the name '47241950.qua'.


End of the scan: January 11, 2011 15:28

That's about all I can do to try to help, maybe try something other than an online scanner to detect this. Kapersky is supposed to be a good antivirus, so i dont know. I guess all I can say is anyone using the popular antivirus avira will likely think this is packaged with something unwanted I dont know why there is this detection.

almost certainly a false positive.. www.virustotal.com is a great way to get a view from many AV systems on any file you suspect. In this case, 1 out of the 43 AV engines is suspicious. In my experience, this is a strong indicator of a false positive. See http://www.virustotal.com/file-scan/rep ... 1294772372

[outAtime]

Fascinating site! Thanks for the link. Anyways, Im interested in this idea of using q-search to decide if to use LMR or not. What would I do to test the idea, set a flag in q_search (q_high = TRUE) for a fail high (q_score > alpha) and make it a LMR condition?
Ive read the other posts, but its still not exactly clear since most are using SEE, which I do not have.

[lkaufman]

[quote="bob"][quote= I don't extend losing (SEE) checks and I will even reduce them...[/quote]

Are you saying that you reduce them just as if they were losing (SEE) non-checks? If so that seems wrong to me, because checks are always worth looking at more than they would be if they were not checks, since the number of replies is so much smaller. Perhaps you just do more conservative reductions on them?

[bob]

Are you saying that you reduce them just as if they were losing (SEE) non-checks? If so that seems wrong to me, because checks are always worth looking at more than they would be if they were not checks, since the number of replies is so much smaller. Perhaps you just do more conservative reductions on them?

No. If SEE < 0 for a check, it is not extended, and is reduced like any other move to boot... If you think about it, I'll bet you play games every week where there are checking moves that you don't even consider.... because they are obviously just spite checks that do nothing more than delay something for a move, and lose material on top of that, making them worthless... Our depths are so incredible nowadays that the idea of extending checks is not particularly useful, unless you decide to not extend lemons. And for reductions, the same logic applies to captures. For a few years the rule has been to not reduce captures. A lot of testing showed that reducing captures with SEE < 0 is a +Elo change... When I found that, I applied the same logic to checks and found again that treating losing checks the same as losing moves was a +Elo change...

BTW I am not doing any wildly dynamic reduction stuff yet. I am currently testing several ideas along that line, and there it might be that checks get reduced, but not as severely as very late non-checks. That is YTBD. First step is to find a workable dynamic reduction amount over my current 2-tier approach, if I can.

[lkaufman]

I think I remember reading that you currently just reduce the second move a full ply and the third and remaining moves two full plies, with the usual check/capture exceptions. If that is correct, I would bet that you would get an Elo gain by only allowing a single ply reduction for SEE-losing captures and checks. I agree that stupid-looking captures and checks are worse than plausible ordinary moves, but they are surely more worthy of search than equally stupid-looking ordinary moves. Have you tested that yet?

[F. Bluemers]

Fascinating site! Thanks for the link. Anyways, Im interested in this idea of using q-search to decide if to use LMR or not. What would I do to test the idea, set a flag in q_search (q_high = TRUE) for a fail high (q_score > alpha) and make it a LMR condition?
Ive read the other posts, but its still not exactly clear since most are using SEE, which I do not have.

Qsearch will be too expensive.
Fritz Reul describes a nice non-recursive SEE on his homepage
http://www.loopchess.com/Static-Exchange-Evaluation.pdf

[bob]

I think I remember reading that you currently just reduce the second move a full ply and the third and remaining moves two full plies, with the usual check/capture exceptions. If that is correct, I would bet that you would get an Elo gain by only allowing a single ply reduction for SEE-losing captures and checks. I agree that stupid-looking captures and checks are worse than plausible ordinary moves, but they are surely more worthy of search than equally stupid-looking ordinary moves. Have you tested that yet?

Close. I reduce the first move searched by 1 1 ply, but only if it is not a hash move, a good capture nor a killer. Any other move gets reduced by 2 plies (currently, but I am working on this as I write this). The idea is that in a lot of positions, the first move tried (particularly in a position like fine 70) is not a capture nor a killer. Reducing every move just makes the total depth 2 plies shallower which hides too much....

As far as the single ply reduction, it did not work for me. I had already tested that idea as one of dozens when I was playing with this...

[lkaufman]

[quote="bob"][quote I reduce the first move searched by 1 ply, but only if it is not a hash move, a good capture nor a killer. "

I don't know of any other program that will reduce the very first move other than at cut nodes. Did you also test reducing starting at the second move, and if so how much better was it to reduce the first move? Do you do this even at PV nodes, and if so do you ever get PVs shorter than nominal depth? If not why not?