how much open source code did you read and understand?

[Ross Boyd]

Hi Fabien,

Congratulations with 2.1 and well done! I'm amazed.

I plead guilty for the pawn eval.

Okay then, you're forgiven.

It's the same as before, but I switched to a branchless design. It leads to table-based programming, which is very hard to read I agree.

The positive side is that I can quickly calculate on-the-fly pawn-only features at evaluation time for instance regarding king safety but also say outposts in the future.

Outposts should improve Fruit, if improvement is possible.

Another area to look at is R+P endings. Dumb egtb engines like mine can swindle Fruit 2.1 in these types of endings. (You should have been there, I almost died and went to heaven when TRACE scored her first full point against your wretched program. In the end Fruit struggled to win the 50 game blitz match by the narrowest of margins... erm... well it scored about 84%... )

cheers!

Ross

[Fabien Letouzey]

My understanding is that the content of BitGE is constant during all the run of Fruit2.1 so I wonder why not to write it as const but to have a function to calculate it.

Cannot fruit be faster in case that BitGE and other arrays in pawn.cpp defined to be const?

Hi Uri,

No. Because indices (like i in a[i]) are not known at compile time, no benefit should be expected. Constants are useful mostly for scalars.

I prefer initialising "large" tables by code, because:
- it is more flexible (tunable)
- it is less error prone
- it makes it possible to know where the values come from

Fabien.

[Uri Blass]

My understanding is that the content of BitGE is constant during all the run of Fruit2.1 so I wonder why not to write it as const but to have a function to calculate it.

Cannot fruit be faster in case that BitGE and other arrays in pawn.cpp defined to be const?

Hi Uri,

No. Because indices (like i in a[i]) are not known at compile time, no benefit should be expected. Constants are useful mostly for scalars.

I prefer initialising "large" tables by code, because:
- it is more flexible (tunable)
- it is less error prone
- it makes it possible to know where the values come from

Fabien.

Hi Fabien,
1)Why indices cannot be known at compile time?

My common sense tells me that if big tables are not changed during the program the compiler should be able maybe to take advantage of that knowledge but I understand nothing about compilers.

2)Based on my understanding BitGE is a table that does not give evaluations and is only used for evaluation so I do not understand the point of flexible.

The first thing that I plan to do when I read code like your code is simply to translate it to numbers.
I already did it for BitGE and if I understand correctly.

BitGE[16]={0,0,0,0,255,254,252,248,240,224,192,128,0,0,0,0}
These numbers do not seem to me numbers that can be tunable.

Later steps are simply to read the code that fruit does in it's evaluation to understand based on looking in examples what is the meaning of the numbers.

I see no other way to understand the numbers and not having const arrays only make me work harder because I need to figure out the numbers and I need to look at the code to make sure that they are const(I searched for bitGE to see that it is not changed during the program).

Uri

[Uri Blass]

Now I read and I understand better(at least I understand bitGE) but I still do not understand Fruit'sking safety code at this moment.

I understand that bitGE[] is a function that fit to every rank the ranks(4-11) a number that represents set of ranks when GE is for greater or equal.

bitGE[4]=255 because 4 is the smallest rank(a1-h1 on the board) and the ranks that are bigger or equal than it are ranks 4-11 or 255 when you translate set of ranks to number(rank4 to 2^0 and rank11 to 2^7 and generally rank i to 2^(i-4))

I think that the name bitGE is not a good name for that array and a better name could be setGE.

If I understand correctly

board->pawn_file[colour][file] is another set of ranks
namely ranks of pawns of one side in the same file.

I hope it will help me to understand
shelter_file( of fruit

Uri

[diepeveen]

I find it very odd that Uri complains about Fruit. Crafty i can imagine he complains.

When i saw source code of Fruit first time, i understood it 100%.

It's real nice generic programmed. An example everyone should follow if you ask me.

Crafty is of course bitboards. That limits the options already to write generic code that is fast. bitboards by definition means non-generic code.

Like programming out everything for black & white. Not having like i have in diep : pawns[2], but crafty has a whitepawns and a blackpawns.

Yet even then the code is easily readable.

Not a single problem there.

But the comment regarding fruit really amazes me. Seldom i have seen GNU code that is that generic nice programmed.

I completely disagree with the scharnagel statement that open source is poisening. Without publication in some form of source code, fields like computerchess would not advance as quickly as it has done last so many years.

It is the open internet and open availability at that internet from open source programs that has boosted computerchess a lot.

Vincent

[Peter Fendrich]

Hi Vincent,

When i saw source code of Fruit first time, i understood it 100%.

Yes it's not very hard to understand but what is hard to see is why it is so very strong. It is quite simple and still beats most of its opponents. The balance between search and evaluation is not really visible (for me).

Crafty is of course bitboards. That limits the options already to write generic code that is fast. bitboards by definition means non-generic code.

This is nonsens Vincent and you know it. It's just about your "war" agains Bob! You can of course make bitboard programs as generic as any other program.

But the comment regarding fruit really amazes me. Seldom i have seen GNU code that is that generic nice programmed.

Agree.

It is the open internet and open availability at that internet from open source programs that has boosted computerchess a lot.

Absolutely.

/Peter

[Reinhard Scharnagl]

Hi Vincent,

I completely disagree with the scharnagel statement that open source is poisening.

I never have said that. I addressed merely OpenSource projects, whose results are participating in tournaments, thus of course computer chess engine projects, which also are able to kill peoples ideas just in status nascendi.

Reinhard.

[diepeveen]

[quote="Reinhard Scharnagl"]Hi Uri,

a long time ago had I taken a short look into the GNU project and then nearly immediately deleted all of it. It has made me very sure, that foreign source code would corrupt my own ideas. Accepting and using data structures not related to my own way of thinking and organizing entities of the chess world hardly could help me to develop my own thoughts and approaches. It is like being infected with a lethal virus which will conquer your whole body and would leave it without any life.

Open Source / GPL chessprogram projects may be a crutch for small-minded people, but they for sure are poisoning the creative.

Reinhard.[/quote]

Then Reinhard how must i interpret the last sentence?

Write in german otherwise, my english like yours is limited in terms of expression. I read this as that you find open source people 'small minded'. The utmost insult i would imagine towards the open source people. And that it is bad for creativity.

However on other hand, 99% of all programmers is complete idiots in programming respects. If they have the simple to read Fruit source code, they can simplistic experiment with algorithms and get better feedback back than when they would write some 1200 elo engine. At some 1200 rated engine of course any random change and any random algorithm works. Especiallyw hen not statistically tested very well, but even with statistical significant testing it will work as *any* change improves it.

So from experimenting viewpoint starting with Fruit source code is good for scientists.

What you see then is special fruit tunings like toga II, which is fruit with 50 lines modified and it plays 50 elopoints stronger than the equivalent fruit version according to Fabien.

[diepeveen]

[quote="Peter Fendrich"]Hi Vincent,
[quote="diepeveen"]When i saw source code of Fruit first time, i understood it 100%.[/quote]
Yes it's not very hard to understand but what is hard to see is why it is so very strong. It is quite simple and still beats most of its opponents. The balance between search and evaluation is not really visible (for me).

Some people are good in tuning. Fabien is one of them. Fruit is super tuned. It is hyper agressive. So the forward pruning gets compensated by hyper agression. I have many positions here where diep says white up 1.0 and fruit already with 1 passer sees big compensation and says black up 1.0 (who has right is not relevant in this context). Both say that more or less staticaly and only after many moves you see who was on the right side of the evaluation.

So obviously it is very hyper agressive tuned with passed pawns and mobility.

The king safety is very solid tuned, though it lacks massive chessknowledge there. It may be its only real weakness.

The hyper agression means that a reduced search depth will still see compensation and therefore pruning with the history method is easier for it than for other engines.

[quote]Crafty is of course bitboards. That limits the options already to write generic code that is fast. bitboards by definition means non-generic code.[/quote] This is nonsens Vincent and you know it. It's just about your "war" agains Bob! You can of course make bitboard programs as generic as any other program.

No you cannot. The C compilers under linux where bob runs under need inline assembly and all that kind of junk to be fast.

Without inline assembly bitboards is not possible.

Secondly bitboards has severe limits to improve your evaluation function and bitboards has serious drawbacks when you start making them generic.

Please write a generic bitboard program and try to make a better mobility for it than crafty have and then see its speed and tactical weakness last few plies.

Bottomline is that you need inline assembly simply for bitboards. Without it, forget it.

So what happens as a result of that is also massive type mixing (bad bad) and i recently had to help another guy who messes up with bitboards.

Like they all do things like

a <<= 45;

under ansi-c regulations that might go wrong of course.

and integers get mixed with 'unsigned long long' bitboards.

All asking for problems.

Very cruel and buggy ways to program.

If you keep your engine as 'dumb' in evaluation like crafty you still can get away with it, but when things start become more complex and nowadays of course ALL the engines have increased its knowledge and this is a tendency that just goes on and on.

My eval just slows down and down. For world champs 2005 there is a massive king safety rewrite going on here. Basically it means old code gets bugfixed and expanded and new loops and scans are there.

Dragon, attack attack and Diep scores, as long as i don't need to play SOS of course, my nightmare opponent, he beats me every other game! .

Juniors agression is nothing compared to the agression of diep at kingside nowadays.

It is here where Fruit scores points of course in the games you see now online. It just says: "just come attack my king and when your attack doesn't work i kill you".

But objectively of course, more knowledge is what is happening in all engines. Junior9 and 8 both progressed a lot there. Does anyone train against junior for world champs 2005?

I get impression they won several world titles because no one tests against them and only tests against shredder or fritz.

I feel Fruit 2.1 is stronger than Fritz now when running at a single cpu, despite that Fritz has more chessknowledge.

Yet many are that. Fruit against a quad dual core opteron 1.8Ghz is no chance of course at world champs at 60 in 2.

All cpu's soon are dual core of course or faster. 2006 will be quad core.

[quote]But the comment regarding fruit really amazes me. Seldom i have seen GNU code that is that generic nice programmed.[/quote] Agree.

[quote]It is the open internet and open availability at that internet from open source programs that has boosted computerchess a lot.[/quote]Absolutely.

/Peter[/quote]

[diepeveen]

Please note that my OPEN SOURCE (GNU GPL) move generator in simple ansi-c is beating the hell out of 64 bits generic bitboards move generator without inline assembly.

Factor 1.5+ or so.

Vincent

[Uri Blass]

Hi Vincent,

When i saw source code of Fruit first time, i understood it 100%.

Yes it's not very hard to understand but what is hard to see is why it is so very strong. It is quite simple and still beats most of its opponents. The balance between search and evaluation is not really visible (for me).

/Peter

I disagree.

It is not hard to understand parts of it but understanding everything is not easy.

For the question why it is so strong I can say that I believe that it has more knowledge than most of the engines (both better tricks in the search and better evaluation).

Movei does not have a lot of knowledge that fruit has in evaluation and also does not use some search tricks of fruit.

I think that understanding fruit may help me to make big improvement in Movei (understanding means knowing the meaning of every variable and not only having some idea about what they are doing).

Only the structure of fruit is something that I already learned from it and having many .h files is simply better than having one file of global variables.

Uri

[diepeveen]

[quote="Uri Blass"][quote="Peter Fendrich"]Hi Vincent,
[quote="diepeveen"]When i saw source code of Fruit first time, i understood it 100%.[/quote]
Yes it's not very hard to understand but what is hard to see is why it is so very strong. It is quite simple and still beats most of its opponents. The balance between search and evaluation is not really visible (for me).

/Peter[/quote]

I disagree.

It is not hard to understand parts of it but understanding everything is not easy.

For the question why it is so strong I can say that I believe that it has more knowledge than most of the engines (both better tricks in the search and better evaluation).

Movei does not have a lot of knowledge that fruit has in evaluation and also does not use some search tricks of fruit.

I think that understanding fruit may help me to make big improvement in Movei (understanding means knowing the meaning of every variable and not only having some idea about what they are doing).

Only the structure of fruit is something that I already learned from it and having many .h files is simply better than having one file of global variables.

Uri[/quote]

I DISAGREE.

All strong amateurs and especially commercials have way way way more knowledge than Fruit. So you hit the ball wrong again and scored in own goal.

Vincent

[Jaime Benito de Valle]

Some people are good in tuning. Fabien is one of them. Fruit is super tuned. It is hyper agressive. So the forward pruning gets compensated by hyper agression.
So obviously it is very hyper agressive tuned with passed pawns and mobility.
The king safety is very solid tuned, though it lacks massive chessknowledge there. It may be its only real weakness.
The hyper agression means that a reduced search depth will still see compensation and therefore pruning with the history method is easier for it than for other engines.
It is here where Fruit scores points of course in the games you see now online. It just says: "just come attack my king and when your attack doesn't work i kill you".

This is exactly what I believe. I could have not put it in words any better.

[Peter Fendrich]

I disagree.

It is not hard to understand parts of it but understanding everything is not easy.

I'm not sure what you disagree about. You repeat the same thing I said earlier in the thread and that doesn't contradict what I said here, I think.
/Peter

[Alessandro Scotti]

No you cannot. The C compilers under linux where bob runs under need inline assembly and all that kind of junk to be fast.

Without inline assembly bitboards is not possible.

Secondly bitboards has severe limits to improve your evaluation function and bitboards has serious drawbacks when you start making them generic.

Please write a generic bitboard program and try to make a better mobility for it than crafty have and then see its speed and tactical weakness last few plies.

Hi Vincent,
in my program I have a Bitboard class that contains all the required methods (like bitScan and so on) so type safety is preserved. Also, a version without inline assembly ran only slightly slower and it's now how the program is compiled for all platforms but Windows, where assembly still grants a small advantage.
However, I'm considering writing a new engine and choosing whether to use bitboards or not is an important decision so I would like to understand more on this matter. What problems do you see for mobility? At present, evaluating mobility for say a bishop requires generating the bishop moves bitboard (which isn't too slow) and counting the bits. I was also considering weighting some board areas (e.g. the center or the squares around the king) and for that I would need an extra "and" and bit count for each weight... is this one of the problems you are thinking of? Otherwise, the method shouldn't be much slower than looping on the board itself.
Also on move generation... what data structure are you using in your GPL code? I mean, is it geared towards plain move generation or does it also update info that could be useful elsewhere (e.g. attack tables)?
Currently the things I don't like about bitboards are the large lookup tables and their being useful only on a 8x8 board, so I would like to try something else in the future. On the other hand, there's a lot of nice things that can be done playing with bit-oriented operators, provided you enjoy working with this stuff (which I do!)...

[Peter Fendrich]

Without inline assembly bitboards is not possible.

The last time I looked at Crafty code, some years ago, there were only a few assembly functions and changing them to c-code wouldn't hurt much. Less than 5% in speed, I would say as a rough estimate. Crafty haven't been so much better since then so assembley isn't an issue here.
You may be right or wrong about your bitboard critisism but generic code isn't the problem.
/Peter

[Uri Blass]

Hi Vincent,

When i saw source code of Fruit first time, i understood it 100%.

Yes it's not very hard to understand but what is hard to see is why it is so very strong. It is quite simple and still beats most of its opponents. The balance between search and evaluation is not really visible (for me).

/Peter

I disagree.

It is not hard to understand parts of it but understanding everything is not easy.

For the question why it is so strong I can say that I believe that it has more knowledge than most of the engines (both better tricks in the search and better evaluation).

Movei does not have a lot of knowledge that fruit has in evaluation and also does not use some search tricks of fruit.

I think that understanding fruit may help me to make big improvement in Movei (understanding means knowing the meaning of every variable and not only having some idea about what they are doing).

Only the structure of fruit is something that I already learned from it and having many .h files is simply better than having one file of global variables.

Uri

I DISAGREE.

All strong amateurs and especially commercials have way way way more knowledge than Fruit. So you hit the ball wrong again and scored in own goal.

Vincent

My opinion is that knowledge need to be productive and I do not think that it is a good idea to implement a lot of things without testing.
I believe that at least a lot of amateur programmers do not hurry to implement as much as possible and prefer to add one thing and test.

I know that at least Movei has less knowledge than fruit in many things.
If we discuss about evaluation here is a position that fruit evaluate as close to equal even at depth 1.

It probably has some better knowledge than both Movei and myself because I evaluate the position after 16.Bxf8 Rxf8 as advantage for white
of about half a pawn.

White has exchange for a pawn and pair of bishop but pair of bishops is not big enough to compensate for the material advantage.

Movei evaluates it as +0.38 for white.

White rook at a1 is evaluated as 1.6 pawns more than black bishop at d5
pair of bishop gives only 0.2 pawns compensation for black so it is 0.4 pawns based on fast calculation.

black has slightly better mobility after 16.Bxf8 Rxf8 but king at h7 is not good in the middle game like king at g1 so the total score for other things is near 0)

Movei evaluates it as bigger advantage for white at bigger depthes.
Note that Yace shows similiar behaviour and I am not surprised because Yace is the most materialistic engine out of the engines that I tried(Yace in most cases is more materialistic than Movei and I guess that Yace's king safety knowledge is even worse than Movei when Fruit's king safety evaluation is probably superior to Movei).



New game - Fruit 2.1, 10'/40+10'/40+10'/40
r4r2/pppq1pbk/2n3pp/2Bbp3/8/1P3NP1/P3PPBP/R1Q2RK1 w - - 0 1

Analysis by Fruit 2.1:

16.Bxf8 Rxf8
= (0.02) Depth: 1/2 00:00:00
16.Bxf8 Rxf8 17.Rd1
? (0.37) Depth: 2/12 00:00:00
16.Bxf8 Bxf8 17.Rd1 Bb4
= (0.09) Depth: 3/12 00:00:00
16.Rd1 e4 17.Bxf8 Rxf8
? (0.26) Depth: 3/13 00:00:00
16.Rd1 e4 17.Bxf8 Rxf8 18.Qc5 Bxa1 19.Rxd5
? (-0.51) Depth: 4/14 00:00:00
16.Bxf8 Rxf8 17.Qc5 Rd8 18.Rfd1
? (0.34) Depth: 4/14 00:00:00
16.Bxf8 Rxf8 17.Qc5 Rd8 18.Rfd1 f5
= (0.18) Depth: 5/15 00:00:00
16.e4 Bxe4 17.Ng5+ hxg5 18.Bxe4 g4 19.Bxf8 Rxf8 20.Bxc6 bxc6
= (0.22) Depth: 5/15 00:00:00
16.e4 Bxe4 17.Ng5+ hxg5 18.Bxe4 g4 19.Bxf8 Rxf8 20.Bxc6 bxc6
= (0.22) Depth: 6/15 00:00:00 56kN
16.e4 Bxe4 17.Bxf8 Rxf8 18.Ng5+ hxg5 19.Bxe4 Bf6 20.Bxc6 Qxc6 21.Qxc6 bxc6
? (0.42) Depth: 7/18 00:00:00 128kN
16.e4 Be6 17.Rd1 Nd4 18.Bxf8 Rxf8 19.Qa3 Ra8 20.Rac1
? (0.60) Depth: 8/21 00:00:00 260kN
16.e4 Be6 17.Rd1 Nd4 18.Bxf8 Rxf8 19.Qa3 Ra8 20.Rac1 Bf6
? (0.41) Depth: 9/21 00:00:01 492kN
16.e4 Be6 17.Rd1 Nd4 18.Bxf8 Rxf8 19.Qa3 Ra8 20.Rac1 Bf6 21.Qb4
? (0.49) Depth: 10/23 00:00:01 1209kN
16.e4 Be6 17.Rd1 Nd4 18.Bxf8 Rxf8 19.Qa3 Ra8 20.Rac1 Bg4 21.Kh1 Bf6
? (0.39) Depth: 11/25 00:00:03 2290kN
16.e4 Be6 17.Rd1 Nd4 18.Bxf8 Rxf8 19.Qe3 Rd8 20.Rac1 Qe7 21.Rd2 Kg8 22.Nxd4 exd4
? (0.26) Depth: 12/28 00:00:06 5630kN
16.e4 Be6 17.Rd1 Nd4 18.Bxf8 Rxf8 19.Qe3 Bf6 20.Rac1 Qd6 21.Bf1 Bg4 22.Be2 Kg8
? (0.26) Depth: 13/29 00:00:14 12981kN
16.e4 Be6 17.Rd1 Nd4 18.Bxf8 Rxf8 19.Nxd4 exd4 20.Qc2 Bg4 21.Rd3 f5 22.e5 f4 23.Qc5 fxg3 24.hxg3
= (0.21) Depth: 14/29 00:00:29 27365kN
16.e4 Bxe4 17.Bxf8 Rxf8 18.Ng5+ hxg5 19.Bxe4 Nd4 20.Qxg5 f5 21.Bg2 e4 22.Rad1 Rd8 23.Kh1 Bh6 24.Qf6
= (0.21) Depth: 15/37 00:01:18 75351kN
16.e4 Bxe4 17.Bxf8 Rxf8 18.Ng5+ hxg5 19.Bxe4 Nd4 20.Qxg5 f5 21.Bg2 e4 22.Qh4+ Kg8 23.Rad1 Rd8 24.Kh1 Be5 25.Rfe1
= (0.12) Depth: 16/40 00:02:19 136859kN
16.e4 Bxe4 17.Bxf8 Rxf8 18.Ng5+ hxg5 19.Bxe4 Nd4 20.Qxg5 f5 21.Bg2 e4 22.Rad1 Rd8 23.Kh1 Qd6 24.Rfe1 Bf6 25.Qe3
= (0.19) Depth: 17/45 00:05:02 298538kN
16.e4 Bxe4 17.Bxf8 Rxf8 18.Ng5+ hxg5 19.Bxe4 Nd4 20.Qxg5 f5 21.Bg2 e4 22.Rad1 Rd8 23.Kh1 Qd6 24.Qh4+ Kg8 25.Rfe1 Bf6 26.Qh6
= (0.10) Depth: 18/45 00:08:49 522677kN

(, 29.06.2005)

[diepeveen]

[quote="Peter Fendrich"][quote="diepeveen"]
Without inline assembly bitboards is not possible.
[/quote]
The last time I looked at Crafty code, some years ago, there were only a few assembly functions and changing them to c-code wouldn't hurt much. Less than 5% in speed, I would say as a rough estimate. Crafty haven't been so much better since then so assembley isn't an issue here.
You may be right or wrong about your bitboard critisism but generic code isn't the problem.
/Peter[/quote]

Still you didn't touch the subject SPEED.

My code when NOT using inline assembly is even at 64 bits A64 about factor 1.5 faster (2.0-2.2 times faster at 32 bits K7).

Also you didn't touch the subject GENERIC code.

Crafty is *not* generic code.

If he gets a bunch of hits from indirection, how much more will it slow down?

Like he's having
BITBOARD whitepawns;
BITBOARD blackpawns;

that's always faster than
BITBOARD pawns[2];

and working with arrays,
also the latter one is more generic and crafty is *not* doing that.

In the makemove, crafty has code for each piece.

How can you defend *that* as generic code?

Generic code is like what i have in diep:
int piecelist[2][18]; // each list terminated with -1 so can have 17 elements

that's far more generic than what crafty has IMHO.

IMHO crafty is completely non-generic code where 64 bits unsigned gets mixed with 32 bits signed code.

Asking for bugs if you regurarly work at your program. If you just change a few bytes of course, after a year or 10 you'll have it bugfree, which is exactly what happened with crafty.

Vincent

[Peter Fendrich]

Without inline assembly bitboards is not possible.

The last time I looked at Crafty code, some years ago, there were only a few assembly functions and changing them to c-code wouldn't hurt much. Less than 5% in speed, I would say as a rough estimate. Crafty haven't been so much better since then so assembley isn't an issue here.
You may be right or wrong about your bitboard critisism but generic code isn't the problem.
/Peter

Still you didn't touch the subject SPEED.

My code when NOT using inline assembly is even at 64 bits A64 about factor 1.5 faster (2.0-2.2 times faster at 32 bits K7).

Also you didn't touch the subject GENERIC code.

I did touch them didn't I...

In the makemove, crafty has code for each piece.
How can you defend *that* as generic code?

I don't defend crafty at all. Actually I don't give a damn if crafty is this or that. I just said that bitboard programs can be designed and coded in a generic fashion.

Code: Select all

Generic code is like what i have in diep


I'm sure you have and I'm sure it's fast but that wasn't the issue here.
/Peter

[Pallav Nawani]

Also, a version without inline assembly ran only slightly slower and it's now how the program is compiled for all platforms but Windows, where assembly still grants a small advantage.

About how much is the advantage (say in %) you get when you use inline assembly?

However, I'm considering writing a new engine and choosing whether to use bitboards or not is an important decision so I would like to understand more on this matter.

Funny you'd say that, because I have started to slowly switch Natwarlal from 0x88 based board representation to bitboards. Since you have experience in making a bitboard based program, perhaps you can tell me some tricks and gotchas about bitboards?

As far as I can see, these are the advantages for Array based representations:
(a) Faster move generation.
(b) Flexibility. Bitboards can only be used to make chess programs with 8x8 board. If you want hexagonal chess, or 10x12 (whatever it is) etc, bitboards are not an option.
(c) Lower memory footprint (?). I saw that beowulf had 2 tables of size 64K on stack for a bitcount function!

And now the advantages for bitboards that I can see:
(a) Faster evaluation. Calculating whether a pawn is passed or not requires just one and.
(b) No need to mess around with piece lists and such, bitboards already do the job well.
(c) No need to scan the empty square when generating captures.
(d) No need to test for the end of the board.
(e) Future proof: Bitboards will have a great speed advantage when all the PCs become 64 bit!
Also see this paper (In case you haven't already).
http://www.cis.uab.edu/info/faculty/hyatt/boardrep.html

What problems do you see for mobility? At present, evaluating mobility for say a bishop requires generating the bishop moves bitboard (which isn't too slow) and counting the bits.

I don't think that there are any problems at all.. In an array based representation, evaluating mobility requires generating the bishop moves, and counting them. Same thing.

Pallav