The problem is that writing a strong engine is an open-ended project, that you can easily spend all your time on for the rest of your life. No matter what you have, it can always be made stronger with more effort. But unfortunately I have only one life, and cloning has not yet be perfected.
Besides, if you want to have a really strong engine, JavaScript is a bad idea. The same algorithm implemented in C would always be significantly faster, and thus stronger.
So any effort spent in this area would be more fruitful when spent on a conventional C program like ChessV or Fairy-Max, than on a JavaScript web Applet. You can argue that the diagram is more versatile than existing multi-variant engines w.r.t. the range of CVs it can handle, but that is exactly because more effort went into expanding its possibilities, rather than increasing its playing strength. I still believe that it will be more useful to add features that would allow it to do CVs it cannot yet do (e.g. with piece drops) than to make it stronger for those it can already do.
That being said, there are many standard techniques in engine building that the diagram's AI doesn't implement yet. Such as a transposition table, move-sorting heuristics such as killer and history, check detection, null-move pruning.Perhaps at some point I will add the check detection, because it seems really a bit unbalanced that (at 2 ply) it doesn't see mate-in-1 threats against it. It would add a lot of code to do that in a way that doesn't enormously slow it down. (And if it did, it would probably be better to keep the speed and just set it for 3 ply.)
The problem is that writing a strong engine is an open-ended project, that you can easily spend all your time on for the rest of your life. No matter what you have, it can always be made stronger with more effort. But unfortunately I have only one life, and cloning has not yet be perfected.
Besides, if you want to have a really strong engine, JavaScript is a bad idea. The same algorithm implemented in C would always be significantly faster, and thus stronger.
So any effort spent in this area would be more fruitful when spent on a conventional C program like ChessV or Fairy-Max, than on a JavaScript web Applet. You can argue that the diagram is more versatile than existing multi-variant engines w.r.t. the range of CVs it can handle, but that is exactly because more effort went into expanding its possibilities, rather than increasing its playing strength. I still believe that it will be more useful to add features that would allow it to do CVs it cannot yet do (e.g. with piece drops) than to make it stronger for those it can already do.
That being said, there are many standard techniques in engine building that the diagram's AI doesn't implement yet. Such as a transposition table, move-sorting heuristics such as killer and history, check detection, null-move pruning.Perhaps at some point I will add the check detection, because it seems really a bit unbalanced that (at 2 ply) it doesn't see mate-in-1 threats against it. It would add a lot of code to do that in a way that doesn't enormously slow it down. (And if it did, it would probably be better to keep the speed and just set it for 3 ply.)