Just read what I wrote. I don't use Board(x) in the evaluation. But I could, because it is there and it is incrementally updated as the moves are made. So one could quite easily graft the fruit evaluation onto Crafty without having to rewrite all the code. Without having to rewrite any of the code, except to change the square numbers to convert from fruit numbering to Crafty numbering...SuneF wrote:"Could", "might", "is possible". I don't know what you're seeing but I don't see a whole lot of Board(from) going on.bob wrote:Not so fast. Is Crafty bitboard? Yet it _still_ has board. So Fruits eval could be made to work in the crafty framework with not a lot of effort, mainly just dealing with renumbered squares since my board is only 64 elements. It would be a decidedly "unbitboard" approach, but it would work just fine since tree->board[from] would work. Or you could use Board(from) which is a macro I use to make the code easier to read... Move generation shouldn't be done using that array, but it could.SuneF wrote:You can hide everything with macros if you create enough of them, but that's "in theory". Let's stick to the actual relevant case.bob wrote: NO it isn't "a fact". There are parts of my eval that are not "bitboard-centric". Low-level stuff is, but not all. Ditto for move generation. One can hide much with macros.
1) Fruit uses board->square[from] a lot, it doesn't translate to bitboard. Fruit is also full of magic numbers (offsets) that doesn't translate. It's a totally different approach to doing move generation with bitboards where you work with bitwise operators and mask out bits."Should" look completely different. See above. You can use Board(from) in Crafty anywhere you want to get the piece on square "from". No bitboard accesses and MSB/LSB operations required. Not how bitboards are intended to work, but they _can_ be used like that...
2) Evaluation has the same issues. Lots of board->square[to], piece lists and pattern matching that looks completely different in bitboards.
That is simply nonsense. How can you _possibly_ write an eval from scratch and do it it less than a day or two? And that is all it would take to stuff the fruit eval into Crafty. I renumbered the bits in Crafty, and got rid of the black/white duplication, and it took a couple of months of rewriting."Could, would, should"... I've never said "impossible". I said _unlikely_, as it would be faster in more ways than one to write it from scratch with bitboards.Simple. The difference between "should" and "could". It is clearly possible to stuff the fruit eval right into Crafty. Deal with the re-numbered squares since the two programs use two different array sizes for the mailbox board, and you are ready to go. It would not be as fast, it would not be a "clean bitboard" program. But you can't say "impossible"... That was my point.
3) You've stated yourself for years that coding bitboards requires a different way of thinking. Why the sudden change of mind?
I am saying that the pre-fruit versions of Rybka were Crafty. The post-fruit versions are _completely_ different from Crafty with respect to overall structure, search, eval, etc. So we have two completely separate cases of "copy and claim".
Ah no reallyAre you following the discussion? We now know that the pre-fruit version of Rybka copied a lot of crafty source. So now the issue becomes taking the fruit eval, plugging it into Crafty. Slowly getting rid of the array references and use bitboard operations. But at each step along the way, you have a working version to compare the new bitboard version to, to simplify testing/debugging.
4) This is not about Crafty. I could state that you cannot easily convert Frenzee to mailbox by changing a few macros, but this is not about Frenzee either.
So this is about Crafty _and_ Fruit...
But you're saying that Crafty was actually the starting point, so Rybka was derived from Crafty and not Fruit, only parts of Fruit was converted? Basicly you're now telling me I was right all along!!
I had little trouble converting Cray Blitz to C and to bitboards, at the same time. Lots of code remained unchanged, until I hit move generation which was quite a bit different at the low-level end. The eval was a direct port, but using bitboard approaches to implement the same features found in the non-bitboard CB code.I _knew_ it wouldn't make any sense to convert Fruit into bitboards, it would have to come from somewhere else or be written from scratch.
Right I agree with you there. Identical and very obscure bugs are a pretty tell tail sign that something is not as it should be.Which is exactly what we have been reporting for a couple of years now? Exact matches. And now some examples with oddball bugs that make no sense, yet which appear in both programs? One has to copy these kinds of bugs, or else believe in miracles to think two different programmers compare the return value of a function to a constant that the function has not produced in 10+ years. In Crafty, that code was left in quite by accident. How did it get into _another_ program? Comparing to the exact same constant??? Coincidence??Anyone could. You'd expect hash move, winning captures, killers and so forth. It's all pretty standard stuff as is nullmove and LMR. You'd need to see something very unsual being used, something identifiable as comming from Fruit. And again ideas can be copied so it would have to be something rather copy-paste like.bob wrote: And then we get to critical things like search, move ordering, pruning, reductions, extensions. He could have copied significant parts.
Perhaps you were actually willing to write your own code, rather than copy?So let me get up to speed, the current theory is the following:bob wrote: And you are overlooking the issue that we now know that he copied parts of Crafty, which _is_ a bitboard program. Suddenly the changes to Fruit's eval don't appear to be so difficult since all the support code may well have been copied (we are quantifying this as I write.)
Rybka came from a 10 year old buggy version of Crafty, then a Fruit eval was easily plugged into it by using macros. Later all previous references were removed meanwhile maintaining a fully functioning engine. Crafty was the starting base but today Rybka is nothing like Crafty but very Fruitish everywhere as the engine has morphed into Fruit.
Sure very logical, exactly how I would have done it....
Apparently. It would be very easy to take the fruit search and replace Crafty's. No significant bitboard code there. But there is a lot of support code needed to use bitboards. move input/output. Move generation. SEE. Debugging code to display bitboards in a readable form. Initialization of the rotated stuff that Vas claimed to have used until switching to Magic.So the bitboard structures of Rybka is more like the list structures of Fruit than the bitboard structures of Crafty? I'm having some trouble following the logic here...First, the structure of Strelka is _nothing_ like the structure of Crafty. Simple to evaluate if you want to lets take procedure by procedure starting at Iterate(). Wait, Strelka doesn't even have an Iterate() function...
Strelka looks fruity. Rybka looks fruity. The pre-fruity version of rybka looks like Crafty. You can ignore the evidence if you want, but none of your comments addresses the specific issues being exposed daily.
If I wanted a bitboard fruit, I would start with a bitboard program that worked and was strong. Crafty certainly fit that. I would then excise the "personality" of Fruit, which would be the eval and search, and transplant that into Crafty, rewriting as I went. Leaving a lot of Crafty intact. A lot of fruit intact. And changing the code at the points where the two distinct approaches are juxtaposed, necessarily. You end up with a lot of Crafty, a lot of Fruit, and some original code. But not a lot of original code.
You could do it to hide details. Or you could do it to hide origin. Either is equally probable.Why would an open-source engine want to do obfuscation? That would make no sense. However many closed source coders whats to keep their secrets and obfuscation is certain a tool to do that. I'm actually surprised not more people are doing it. Why show any output that could reveal how your engine operates?I'm not the "thought police". But I don't do this sort of obfuscation... And I have not seen an open source program that does.