Check out Symmetric Chess, our featured variant for March, 2024.


[ Help | Earliest Comments | Latest Comments ]
[ List All Subjects of Discussion | Create New Subject of Discussion ]
[ List Earliest Comments Only For Pages | Games | Rated Pages | Rated Games | Subjects of Discussion ]

Comments/Ratings for a Single Item

EarliestEarlier Reverse Order Later
@ H. G. Muller[All Comments] [Add Comment or Rating]
H. G. Muller wrote on Tue, Dec 12, 2023 06:29 PM UTC in reply to Aurelian Florea from 06:07 PM:

I guess Bob was triggered by the word 'actors' in the slide. The picture is a screenshot from this years lecture on this year's Nobel prize for physics, last Friday, at 1:08:48 into the video.


Bob Greenwade wrote on Tue, Dec 12, 2023 07:37 PM UTC in reply to H. G. Muller from 06:29 PM:

I guess Bob was triggered by the word 'actors' in the slide.

Yes, quite so. I'm aware of how that has a very different meaning in your context, but at first glance I thought you'd been in a short film or something.

Words having different meaning in different contexts can lead to a lot of humor. I once wrote a six-minute skit around the word "check," and the chess context was about the only one I couldn't fit in. Then there's when I was learning to sew, and saw instructions to baste the edge of a piece (meaning, in that context, to sew some stitches in that piece of fabric by itself to keep its curved edge from warping while it's being sewn to another piece -- and not to brush it down with gravy).


Jean-Louis Cazaux wrote on Tue, Dec 12, 2023 08:09 PM UTC in reply to H. G. Muller from 04:51 PM:

VERY IMPRESSIVE! Congratulations H.G., you should be very proud to have participated to this adventure. I am also "connected" to physics, although much less fundamental and more applied, but still stories of electrons and photons. I am fascinated by modern physics, both the infinite small and the infinite big.

This presentation should have been a great moment for you. And it lasted many many attoseconds. I was amazed to realized that they are more attoseconds in 1 second than the number of seconds since the birth of the universe.

Well. Listening to part of Prof. Agostini, I understand that you MUST create a new fairy piece: the RABBITT. Bravo, again.


Bob Greenwade wrote on Tue, Dec 12, 2023 09:02 PM UTC in reply to Jean-Louis Cazaux from 08:09 PM:

Well. Listening to part of Prof. Agostini, I understand that you MUST create a new fairy piece: the RABBITT. Bravo, again.

I already did a Rabbit. :)


Jean-Louis Cazaux wrote on Tue, Dec 12, 2023 09:32 PM UTC in reply to Bob Greenwade from 09:02 PM:

It doesn't count


Max Koval wrote on Tue, Dec 12, 2023 09:43 PM UTC in reply to H. G. Muller from 04:51 PM:

I just watched the first half of the lecture. This is exactly something that can be characterised as being beyond cool.


Aurelian Florea wrote on Wed, Dec 13, 2023 09:41 AM UTC in reply to H. G. Muller from Tue Dec 12 06:29 PM:

Congratulations HG!


Bn Em wrote on Wed, Dec 13, 2023 04:06 PM UTC in reply to H. G. Muller from Tue Dec 12 04:51 PM:

Congratulations indeed!


Aurelian Florea wrote on Wed, Dec 20, 2023 05:23 PM UTC:

Hello HG, I am trying to contact you privately, on any email. I tried finding an address on hgm.nubati.net, but I'm told that the connection is not secure. How do I send you an email?


Aurelian Florea wrote on Sat, Dec 23, 2023 07:56 AM UTC:

Hello!

I require a bit of help. I have sent you an email on a private address. I'm not sure if you noticed it.


Aurelian Florea wrote on Tue, Dec 26, 2023 11:52 AM UTC in reply to Aurelian Florea from Sat Dec 23 07:56 AM:

Hello, HG!

As I have said earlier I require a bit of help. I have sent you an email on a private address. I'm not sure if you noticed it.


H. G. Muller wrote on Wed, Jan 3 05:48 PM UTC in reply to Aurelian Florea from Tue Dec 26 2023 11:52 AM:

As I have said earlier I require a bit of help. I have sent you an email on a private address. I'm not sure if you noticed it.

I think I found the problem. As you pointed out, it was imitating his own moves rather than those of the user. This used to work correctly before, but with the addition of the function newClick to get a more powerful move-entry interface, this was broken. Because the type to imitates was set in a MakeMove function that was replaced by newClick; and I had not thought of doing this in newClick. (Because that used the AI's function for making moves, which does keep track of the imitated type already. But it tracked this in another variable, 'imi' instead of 'imitatedType', and for a new move the latter is used to initialize imi.

It should work now both in betza.js and betzaNew.js. (Flush browser cache!)


Aurelian Florea wrote on Thu, Jan 4 07:02 AM UTC in reply to H. G. Muller from Wed Jan 3 05:48 PM:

This is great news. Thank you HG!


François Houdebert wrote on Wed, Jan 10 11:42 AM UTC:

I copied the 3d files from the tiger, I thought they might be useful for the chu shogi.

How do you see the next step for jocly?

Do you think a first pull request could be made on Saturday even if some of some variants are commented in the index.js file?

That would give Michel a chance to have a look before he leaves and have a lot of your worked integrated in the master.

We could explain to them that a 2nd pull request will follow and that they need to wait for it before making a new jocly release. Tell me how you want to proceed.


H. G. Muller wrote on Wed, Jan 10 05:46 PM UTC in reply to François Houdebert from 11:42 AM:

How do you see the next step for jocly?

Do you think a first pull request could be made on Saturday even if some of some variants are commented in the index.js file?

I am working on reordering everything we have in a new branch 'pullreq', which I already pushed to my repository. (Don't start adding to it! I am still not finished re-organizing, and when I make more progress I will overwrite what is there now with a forced push.) Here I moved all commits that worked on the same issue next to each other, and squashed them into a single commit, basically deleting all incomplete and often buggy intermediates out of git. I also try to order it such that lowest-level changes come first, so that there is more freedom to move higher-level changes that rely on them around. So first come changes to the Jocly core, then base-model & view, then the sub-models, then fairy-set-view and piece images, then game definitions. Up to the sub-models (multi-leg-view, fairy-move-model, drop-model & view) this now seems completed, and I think that anything up to where we start moving things in sub-directories everything would be fit for pushing. (I might still want to refactor Elven Chess and Werewolf Chess to use fairy-move-model, though.) The moving itself still seems a bit chaotic, so perhaps we should leave that for later. I am still working on it, so I don't know how much I can still achieve before Saturday.

There should be no need to comment out things in index; what is there in principle grows synchronously with the addition of new game models and views, and we just make a pull request for the branch up to a certain point. I think the most important thing is to get all infra-structure that new games want to draw on pushed now.


François Houdebert wrote on Wed, Jan 10 06:18 PM UTC in reply to H. G. Muller from 05:46 PM:

OK I wait for your branch.

I made a branch shogivars on my side on which I squashed branch trial, Because you are right some conflicts were not properly marqued as resolved. In case it helps :

https://github.com/fhoudebert/jocly/tree/shogivars/

Note that on github you can squash everything during the pull request resulting in one commit compliant with the master.


H. G. Muller wrote on Wed, Jan 10 06:35 PM UTC in reply to François Houdebert from 06:18 PM:

Note that on github you can squash everything during the pull request resulting in one commit compliant with the master.

I did not know that. But I think for importing a branch with changes in so many completely different areas this would be a bad idea. For committing a single game that took many iterations it would be great.


H. G. Muller wrote on Thu, Jan 11 10:46 AM UTC:

It is a pity I did not think of this before:

I now wrote a function cbSymmetricGraph(geometry,specs,confine), which seems very generally useful. It  generates moves for a totally symmetric piece (on a grid board), according to an array 'specs'. In principle everything it does can be done with the aid of the existing functions cbShort/LongRangeGraph. Which even can do asymmetric pieces. (Which outside of Shogi virtually never occur...) But the price for that is that you often have to call it with long lists of 'deltas'. This is not only annoying and makes the source code look cluttered, but also a frequent source of bugs. And then you have to use cbMergeGraphs to combine moves that could not be generated at once, because they had different range or flags.

This cbSymmetricGraph takes an array of numbers, where each number represents either a new flags setting to be applied to the moves that follow, or code for direction and range of a move. (Because all flags are > 65000 it can easily spot the difference.) Each symmetric move set is indicated by a single integer: the units indicate the y-step, the decades the x-step, and any higher digits (optionally) the range (which by default is 1, for a leaper). So specs=[21] indicates all Knight moves. A preceding minus means unlimited range, so for a Queen we pass [-10,-11]. So sliders and leapers can be mixed; Archbishop results from [21,-11]. For a 'Short Rook' (Betza R4) we pass [410], but there we already enter the realm of things that are almost never needed.

Divergent pieces are also easy; mRcB would require [FLAG_MOVE,10,FLAG_CAPTURE,11]. This is potentially easier than having dedicated functions like cbCardinalGraph, where you would have to know that it is Cardinal, and not Archbishop or Palladin. And for the rarer pieces you would have to know whether a function exists for it in the first place. So I regret now that I have added so many named graph functions in fairy-move-model, which almost all could have been replaced by this cbSymmetricGraph. (For pieces like Pawn, Griffon and Unicorn dedicated functions still make sense.)


François Houdebert wrote on Thu, Jan 11 10:58 AM UTC in reply to H. G. Muller from 10:46 AM:

Is it really too late? If it's the right solution, maybe we should take it now or in the next pull request.


François Houdebert wrote on Tue, Jan 30 01:19 PM UTC:

I don't know if you have time to work on jocly at the moment, for my part I was looking at how chu shogi works.
I was wondering:
Would it be possible to combine the fairy move model with the drop model to make locust captures on shogis with drops?
For example, could the lion, falcon and eagle locust move from chu seireigi work with jocly?
 

 


Aurelian Florea wrote on Sat, Feb 24 11:33 AM UTC:

Hello HG, A few weeks ago I noticed you contemplated writing a C++ code for the AI of the interactive diagram. Anything from this contemplation?


H. G. Muller wrote on Sat, Feb 24 01:40 PM UTC in reply to Aurelian Florea from 11:33 AM:

This is not something that can be achieved in just a few weeks. But yes, I have been working on it. (Sadly interrupted by an emergency that we have to move the TalkChess server before the end of the month, because the current one will get off line then.) I have started a kind of blog on it on takchess.com, to report the progress, and occasionally receive feedback.

The plan is to write a compiled C program that, when started by the user, installs itself as a HTTP server, so that you can surve to it through the browser. The Interactive Diagram on a page you view on this server could then request moves from it, instead of using the JavaScript that is running in the browser. I have already tested out this setup, by using the MicroSoft model program for a TCP/IP server, and adding the code needed to serve ordinary files from the directory it was started in. The idea is to define one filename (say "engine") as special, and not treat it as a file, but as a command to run the engine code, and output a move.

I am still busy designing a sufficiently powerful engine. I could have just translated the existing JavaScript code to C, counting on the larger speed, but the JavaScript AI has many design characteristics that would also slow down a C program. For that reason, as well as to make the project interesting, I wanted to try a completely different design:

Every piece would get all its potential moves tabulated. That is, every leg of a move would get the squares it visits (indicated relative to the piece) put in a table when the variant is initialized, with the maximum length it could have on a board of the given size. (So on 8x8 a Rook would get 4 moves, each consisting of 7 squares.) During play these tabulated moves will get associated with a board square, depending on where the piece stands, or, for a continuation leg, on where that leg starts.

This data structure takes the place of a conventional move list; retrieving captures from it will be done via the square they are associated with. This way you only have to change the moves of the pieces that were involved in a move (re-associating or deleting their moves, and those of pieces that were discovered / blocked), while most pieces will keep the same moves. That becomes particularly advantageous in large variants.


Aurelian Florea wrote on Sat, Feb 24 02:38 PM UTC in reply to H. G. Muller from 01:40 PM:

Cool!


Bob Greenwade wrote on Sat, Feb 24 02:48 PM UTC in reply to H. G. Muller from 01:40 PM:

I agree with Aurelian: Cool!

It sounds like, once it's done, it may make the ID capable of some things that it can't do right now.


Aurelian Florea wrote on Sat, Feb 24 02:58 PM UTC in reply to Bob Greenwade from 02:48 PM:

Actually I expect something along the same lines but better, meaning a stronger engine! I am aware of the fact that it can take many months, though!


25 comments displayed

EarliestEarlier Reverse Order Later

Permalink to the exact comments currently displayed.