Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #38880 > unrolled thread

Reading in PGN file

Back to article view | Back to comp.lang.javascript

Contents

  Reading in PGN file Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-09-26 17:14 -0700
    Re: Reading in PGN file Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-09-26 17:29 -0700
    Re: Reading in PGN file luserdroog <luser.droog@gmail.com> - 2020-09-26 19:01 -0700
      Re: Reading in PGN file Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-09-26 19:17 -0700
        Re: Reading in PGN file Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-09-27 06:11 -0700
      Re: Reading in PGN file Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-09-27 05:10 -0700
        Re: Reading in PGN file Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-09-27 05:54 -0700
    Re: Reading in PGN file Scott Sauyet <scott.sauyet@gmail.com> - 2020-09-27 09:41 -0700
      Re: Reading in PGN file Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-09-27 10:57 -0700
        Re: Reading in PGN file Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-09-27 11:02 -0700
        Re: Reading in PGN file Scott Sauyet <scott@sauyet.com> - 2020-09-28 14:11 -0700
      Re: Reading in PGN file Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-09-27 11:00 -0700
        Re: Reading in PGN file Scott Sauyet <scott@sauyet.com> - 2020-09-28 14:14 -0700
      Re: Reading in PGN file Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-09-27 11:45 -0700
        Re: Reading in PGN file Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-09-27 13:29 -0700
          Re: Reading in PGN file Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-09-27 19:38 -0700
    Re: Reading in PGN file Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-09-28 04:30 -0700
      Re: Reading in PGN file Scott Sauyet <scott@sauyet.com> - 2020-09-28 14:25 -0700
        Re: Reading in PGN file Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-09-28 14:42 -0700
          Re: Reading in PGN file Scott Sauyet <scott@sauyet.com> - 2020-09-30 14:00 -0700
            Re: Reading in PGN file Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-10-07 00:59 -0700

Page 1 of 2  [1] 2  Next page →

#38880 — Reading in PGN file

In practice it should be simple in reality to many monkeys at work.
Any sain person would for the gameplay either use a "linebreak" always.

Or simply use space between the   ev - to - from, but the monkey just can't help themself.

Some think that randomly glue together moves a good idea. If you try to exchange the "most usual banana" the space to a linebreak. They present you with this. Is this kind of encoding really built in to the format or is the programmers that try to trip eachother, it seem random to me?

Since i am not clairvoyant enough to know where they put in the linebreaks, i simply tried to replace every space with a line break thinking i could read them in three by three. But since they work in mysterious ways i am not able...Event->From->To

Anyone have a better idea to group them 3 by 3 for easy use?
gameString = gameString.split(" ").join('\r\n');
One just wonder why they could not done something like
1. To From
2. To From
3....
Or skipped the fucking linebreaks altogheter, gone for just spaces? But not randomly together with the three properties, its absurd at best but more probably programmer humor...

1.
e4
c5
2.
Nf3
e6
3.
d4
cxd4
4.
Nxd4
Nf6
5.
Nc3
d6
6.
Be2
Be77.
O-O
O-O
8.
f4
Nc6
9.
Be3
Bd7
10.
Nb3
a5
11.
a4
Nb4
12.
Bf3Bc6
13.
Nd4
g6
14.
Rf2
e5
15.
Nxc6
bxc6
16.
fxe5
dxe5
17.
Qf1Qc8
18.
h3
Nd7
19.
Bg4
h5
20.
Bxd7
Qxd7
21.
Qc4
Bh4
22.
Rd2Qe7
23.
Rf1
Rfd8
24.
Nb1
Qb7
25.
Kh2
Kg7
26.
c3
Na6
27.
Re2Rf8
28.
Nd2
Bd8
29.
Nf3
f6
30.
Rd2
Be7
31.
Qe6
Rad8
32.
Rxd8Bxd8
33.
Rd1
Nb8
34.
Bc5
Rh8
35.
Rxd8

[toc] | [next] | [standalone]

#38881

Den söndag 27 september 2020 kl. 02:14:37 UTC+2 skrev Jonas Thörnvall:
> In practice it should be simple in reality to many monkeys at work.
> Any sain person would for the gameplay either use a "linebreak" always.
> 
> Or simply use space between the   ev - to - from, but the monkey just can't help themself.
> 
> Some think that randomly glue together moves a good idea. If you try to exchange the "most usual banana" the space to a linebreak. They present you with this. Is this kind of encoding really built in to the format or is the programmers that try to trip eachother, it seem random to me?
> 
> Since i am not clairvoyant enough to know where they put in the linebreaks, i simply tried to replace every space with a line break thinking i could read them in three by three. But since they work in mysterious ways i am not able...Event->From->To
> 
> Anyone have a better idea to group them 3 by 3 for easy use?
> gameString = gameString.split(" ").join('\r\n');
> One just wonder why they could not done something like
> 1. To From
> 2. To From
> 3....
> Or skipped the fucking linebreaks altogheter, gone for just spaces? But not randomly together with the three properties, its absurd at best but more probably programmer humor...
> 
> 1.
> e4
> c5
> 2.
> Nf3
> e6
> 3.
> d4
> cxd4
> 4.
> Nxd4
> Nf6
> 5.
> Nc3
> d6
> 6.
> Be2
> Be77.
> O-O
> O-O
> 8.
> f4
> Nc6
> 9.
> Be3
> Bd7
> 10.
> Nb3
> a5
> 11.
> a4
> Nb4
> 12.
> Bf3Bc6
> 13.
> Nd4
> g6
> 14.
> Rf2
> e5
> 15.
> Nxc6
> bxc6
> 16.
> fxe5
> dxe5
> 17.
> Qf1Qc8
> 18.
> h3
> Nd7
> 19.
> Bg4
> h5
> 20.
> Bxd7
> Qxd7
> 21.
> Qc4
> Bh4
> 22.
> Rd2Qe7
> 23.
> Rf1
> Rfd8
> 24.
> Nb1
> Qb7
> 25.
> Kh2
> Kg7
> 26.
> c3
> Na6
> 27.
> Re2Rf8
> 28.
> Nd2
> Bd8
> 29.
> Nf3
> f6
> 30.
> Rd2
> Be7
> 31.
> Qe6
> Rad8
> 32.
> Rxd8Bxd8
> 33.
> Rd1
> Nb8
> 34.
> Bc5
> Rh8
> 35.
> Rxd8

Well if it were me i would just think it is just a clumsy bad programmer, but these kind of errors at sites like chess.com and chess365 just can't occure naturally they must be planted to make file harder to read in?

[toc] | [prev] | [next] | [standalone]

#38882

On Saturday, September 26, 2020 at 7:14:37 PM UTC-5, Jonas Thörnvall wrote:
> In practice it should be simple in reality to many monkeys at work.
> Any sain person would for the gameplay either use a "linebreak" always.
> 
> Or simply use space between the   ev - to - from, but the monkey just can't help themself.
> 
> Some think that randomly glue together moves a good idea. If you try to exchange the "most usual banana" the space to a linebreak. They present you with this. Is this kind of encoding really built in to the format or is the programmers that try to trip eachother, it seem random to me?
> 
> Since i am not clairvoyant enough to know where they put in the linebreaks, i simply tried to replace every space with a line break thinking i could read them in three by three. But since they work in mysterious ways i am not able...Event->From->To
> 
> Anyone have a better idea to group them 3 by 3 for easy use?
> gameString = gameString.split(" ").join('\r\n');
> One just wonder why they could not done something like
> 1. To From
> 2. To From
> 3....
> Or skipped the fucking linebreaks altogheter, gone for just spaces? But not randomly together with the three properties, its absurd at best but more probably programmer humor...
> 
> 1.
> e4
> c5
> 2.
> Nf3
> e6

I would start by replacing all linebreaks with spaces. Then go through
and add a linebreak just before any number followed by a digit (/[0-9]+\./).
Then maybe add a 'p' to all pawn moves. Adding the origin for each move
probably cannot be done automatically from the start. It depends on
where the relevant pieces are at any given time.

[toc] | [prev] | [next] | [standalone]

#38883

Den söndag 27 september 2020 kl. 04:01:36 UTC+2 skrev luserdroog:
> On Saturday, September 26, 2020 at 7:14:37 PM UTC-5, Jonas Thörnvall wrote:
> > In practice it should be simple in reality to many monkeys at work.
> > Any sain person would for the gameplay either use a "linebreak" always.
> > 
> > Or simply use space between the   ev - to - from, but the monkey just can't help themself.
> > 
> > Some think that randomly glue together moves a good idea. If you try to exchange the "most usual banana" the space to a linebreak. They present you with this. Is this kind of encoding really built in to the format or is the programmers that try to trip eachother, it seem random to me?
> > 
> > Since i am not clairvoyant enough to know where they put in the linebreaks, i simply tried to replace every space with a line break thinking i could read them in three by three. But since they work in mysterious ways i am not able...Event->From->To
> > 
> > Anyone have a better idea to group them 3 by 3 for easy use?
> > gameString = gameString.split(" ").join('\r\n');
> > One just wonder why they could not done something like
> > 1. To From
> > 2. To From
> > 3....
> > Or skipped the fucking linebreaks altogheter, gone for just spaces? But not randomly together with the three properties, its absurd at best but more probably programmer humor...
> > 
> > 1.
> > e4
> > c5
> > 2.
> > Nf3
> > e6
> 
> I would start by replacing all linebreaks with spaces. Then go through
> and add a linebreak just before any number followed by a digit (/[0-9]+\./).
> Then maybe add a 'p' to all pawn moves. Adding the origin for each move
> probably cannot be done automatically from the start. It depends on
> where the relevant pieces are at any given time.

I had another idea but not tonight, i make a tile list. And if sign after "found tile" != space " " or linebreak. I insert a linebreak, i think that must work. But i am not keen on doing the tile list tonight.

[toc] | [prev] | [next] | [standalone]

#38886

Den söndag 27 september 2020 kl. 04:17:57 UTC+2 skrev Jonas Thörnvall:
> Den söndag 27 september 2020 kl. 04:01:36 UTC+2 skrev luserdroog:
> > On Saturday, September 26, 2020 at 7:14:37 PM UTC-5, Jonas Thörnvall wrote:
> > > In practice it should be simple in reality to many monkeys at work.
> > > Any sain person would for the gameplay either use a "linebreak" always.
> > > 
> > > Or simply use space between the   ev - to - from, but the monkey just can't help themself.
> > > 
> > > Some think that randomly glue together moves a good idea. If you try to exchange the "most usual banana" the space to a linebreak. They present you with this. Is this kind of encoding really built in to the format or is the programmers that try to trip eachother, it seem random to me?
> > > 
> > > Since i am not clairvoyant enough to know where they put in the linebreaks, i simply tried to replace every space with a line break thinking i could read them in three by three. But since they work in mysterious ways i am not able...Event->From->To
> > > 
> > > Anyone have a better idea to group them 3 by 3 for easy use?
> > > gameString = gameString.split(" ").join('\r\n');
> > > One just wonder why they could not done something like
> > > 1. To From
> > > 2. To From
> > > 3....
> > > Or skipped the fucking linebreaks altogheter, gone for just spaces? But not randomly together with the three properties, its absurd at best but more probably programmer humor...
> > > 
> > > 1.
> > > e4
> > > c5
> > > 2.
> > > Nf3
> > > e6
> > 
> > I would start by replacing all linebreaks with spaces. Then go through
> > and add a linebreak just before any number followed by a digit (/[0-9]+\./).
> > Then maybe add a 'p' to all pawn moves. Adding the origin for each move
> > probably cannot be done automatically from the start. It depends on
> > where the relevant pieces are at any given time.
> 
> I had another idea but not tonight, i make a tile list. And if sign after "found tile" != space " " or linebreak. I insert a linebreak, i think that must work. But i am not keen on doing the tile list tonight.

Possibly a string array created from two loops.

[toc] | [prev] | [next] | [standalone]

#38884

Den söndag 27 september 2020 kl. 04:01:36 UTC+2 skrev luserdroog:
> On Saturday, September 26, 2020 at 7:14:37 PM UTC-5, Jonas Thörnvall wrote:
> > In practice it should be simple in reality to many monkeys at work.
> > Any sain person would for the gameplay either use a "linebreak" always.
> > 
> > Or simply use space between the   ev - to - from, but the monkey just can't help themself.
> > 
> > Some think that randomly glue together moves a good idea. If you try to exchange the "most usual banana" the space to a linebreak. They present you with this. Is this kind of encoding really built in to the format or is the programmers that try to trip eachother, it seem random to me?
> > 
> > Since i am not clairvoyant enough to know where they put in the linebreaks, i simply tried to replace every space with a line break thinking i could read them in three by three. But since they work in mysterious ways i am not able...Event->From->To
> > 
> > Anyone have a better idea to group them 3 by 3 for easy use?
> > gameString = gameString.split(" ").join('\r\n');
> > One just wonder why they could not done something like
> > 1. To From
> > 2. To From
> > 3....
> > Or skipped the fucking linebreaks altogheter, gone for just spaces? But not randomly together with the three properties, its absurd at best but more probably programmer humor...
> > 
> > 1.
> > e4
> > c5
> > 2.
> > Nf3
> > e6
> 
> I would start by replacing all linebreaks with spaces. Then go through
> and add a linebreak just before any number followed by a digit (/[0-9]+\./).
> Then maybe add a 'p' to all pawn moves. Adding the origin for each move
> probably cannot be done automatically from the start. It depends on
> where the relevant pieces are at any given time.

Since you have from -> to i rather would see the "piece" attribute removed.
In the end my engine just encode the moves as integers ranging from 0-63 after import.

[toc] | [prev] | [next] | [standalone]

#38885

Den söndag 27 september 2020 kl. 14:10:57 UTC+2 skrev Jonas Thörnvall:
> Den söndag 27 september 2020 kl. 04:01:36 UTC+2 skrev luserdroog:
> > On Saturday, September 26, 2020 at 7:14:37 PM UTC-5, Jonas Thörnvall wrote:
> > > In practice it should be simple in reality to many monkeys at work.
> > > Any sain person would for the gameplay either use a "linebreak" always.
> > > 
> > > Or simply use space between the   ev - to - from, but the monkey just can't help themself.
> > > 
> > > Some think that randomly glue together moves a good idea. If you try to exchange the "most usual banana" the space to a linebreak. They present you with this. Is this kind of encoding really built in to the format or is the programmers that try to trip eachother, it seem random to me?
> > > 
> > > Since i am not clairvoyant enough to know where they put in the linebreaks, i simply tried to replace every space with a line break thinking i could read them in three by three. But since they work in mysterious ways i am not able...Event->From->To
> > > 
> > > Anyone have a better idea to group them 3 by 3 for easy use?
> > > gameString = gameString.split(" ").join('\r\n');
> > > One just wonder why they could not done something like
> > > 1. To From
> > > 2. To From
> > > 3....
> > > Or skipped the fucking linebreaks altogheter, gone for just spaces? But not randomly together with the three properties, its absurd at best but more probably programmer humor...
> > > 
> > > 1.
> > > e4
> > > c5
> > > 2.
> > > Nf3
> > > e6
> > 
> > I would start by replacing all linebreaks with spaces. Then go through
> > and add a linebreak just before any number followed by a digit (/[0-9]+\./).
> > Then maybe add a 'p' to all pawn moves. Adding the origin for each move
> > probably cannot be done automatically from the start. It depends on
> > where the relevant pieces are at any given time.
> 
> Since you have from -> to i rather would see the "piece" attribute removed.
> In the end my engine just encode the moves as integers ranging from 0-63 after import.

Yeah i realise it is not really an engine more of a UI with ruleset. But it might develop to one if it get ELO around 1400-1500 it surely beats me and that is what i strive for.

[toc] | [prev] | [next] | [standalone]

#38887

jonas.thornvall@gmail.com wrote:

> In practice it should be simple in reality to many monkeys at work. 
> Any sain person would for the gameplay either use a "linebreak" 
> always. 
> 
> Or simply use space between the ev - to - from, but the monkey just 
> can't help themself. 

I am so sorry that the world hasn't arranged itself for your
convenience. It was a very petty decision by the world to make your
parsing task so extraordinarily difficult.

Maybe you're right.

Perhaps
we
should
use
linebreaks
between
all
symbols
.

Or maybe you could just accept that people have been successfully using
the PGN format to describe chess games for a good long time, and even 
if the format has its warts, it's simply not *that* difficult to use.

Honestly, the whitespace is not one of its warts, no more than is the
mostly free use of whitespace in modern programming languages.  To my
mind the biggest warts have to do with all the variations required to
properly use algebraic notation.

Rather than this:

    1. f4 e6  2. g4 Qh4 #

I would really prefer something like

    1. Pf2-f4 Pe7-e6  2. Pg2-g4 Qd8-h4 #

But I'm not going to get my way on this any more than you are.  PGN,
built around existing algebraic chess notation, is already well
established.  Whining about it won't fix it.

You, of course, are free not to use it.  You can invent whatever
notation fits your needs.  But if you are ever going to want to
interoperate with other systems, it's highly recommended.

If you are interested in writing your own parser, it's an interesting
challenge.  But if not, there are several easily found by searching the
Web.

  -- Scott

[toc] | [prev] | [next] | [standalone]

#38888

Den söndag 27 september 2020 kl. 18:41:41 UTC+2 skrev Scott Sauyet:
> jonas.thornvall@gmail.com wrote:
> 
> > In practice it should be simple in reality to many monkeys at work. 
> > Any sain person would for the gameplay either use a "linebreak" 
> > always. 
> > 
> > Or simply use space between the ev - to - from, but the monkey just 
> > can't help themself. 
> 
> I am so sorry that the world hasn't arranged itself for your
> convenience. It was a very petty decision by the world to make your
> parsing task so extraordinarily difficult.
> 
> Maybe you're right.
> 
> Perhaps
> we
> should
> use
> linebreaks
> between
> all
> symbols
> .
I think you missunderstand me i am perfectly fine with using just spaces, but *not* when they throw in linebreaks also randomly. And when you remove those the  string separated glues.....


> Or maybe you could just accept that people have been successfully using
> the PGN format to describe chess games for a good long time, and even 
> if the format has its warts, it's simply not *that* difficult to use.

No i just want a consistent use of rules, when they throw in linebreaks randomly instead of space, one could get the idea that they are up to no good. Because i suspect it is not part of the format.


> Honestly, the whitespace is not one of its warts, 

Whitespace???? what is that?
no more than is the
> mostly free use of whitespace in modern programming languages.  To my
> mind the biggest warts have to do with all the variations required to
> properly use algebraic notation.
> 
> Rather than this:
> 
>     1. f4 e6  2. g4 Qh4 #
> 
> I would really prefer something like
> 
>     1. Pf2-f4 Pe7-e6  2. Pg2-g4 Qd8-h4 #

Well my game do not need any of that just integer to from, and i will take care of pawn promotion and castling. I simply got tired i read out just the tiles and the castlings and promotions. The rest the engine translate.

> But I'm not going to get my way on this any more than you are.  PGN,
> built around existing algebraic chess notation, is already well
> established.  Whining about it won't fix it.
> 
> You, of course, are free not to use it.  You can invent whatever
> notation fits your needs.  But if you are ever going to want to
> interoperate with other systems, it's highly recommended.

Done! And it will import PGN and write PGN, but the engine do not use it, until i strip to tiles and convert to integers.

However i will create sort of database it probably will use 6 bit form 7 bit to format.
 
> If you are interested in writing your own parser, it's an interesting
> challenge.  But if not, there are several easily found by searching the
> Web.
It is done.
Just had to remove the unnecessary information.
I tried to parse something sensible but...
Now i just take care of what the ruleengine need.
>   -- Scott

[toc] | [prev] | [next] | [standalone]

#38890

Den söndag 27 september 2020 kl. 19:58:03 UTC+2 skrev Jonas Thörnvall:
> Den söndag 27 september 2020 kl. 18:41:41 UTC+2 skrev Scott Sauyet:
> > jonas.thornvall@gmail.com wrote:
> > 
> > > In practice it should be simple in reality to many monkeys at work. 
> > > Any sain person would for the gameplay either use a "linebreak" 
> > > always. 
> > > 
> > > Or simply use space between the ev - to - from, but the monkey just 
> > > can't help themself. 
> > 
> > I am so sorry that the world hasn't arranged itself for your
> > convenience. It was a very petty decision by the world to make your
> > parsing task so extraordinarily difficult.
> > 
> > Maybe you're right.
> > 
> > Perhaps
> > we
> > should
> > use
> > linebreaks
> > between
> > all
> > symbols
> > .
> I think you missunderstand me i am perfectly fine with using just spaces, but *not* when they throw in linebreaks also randomly. And when you remove those the  string separated glues.....
> 
> 
> > Or maybe you could just accept that people have been successfully using
> > the PGN format to describe chess games for a good long time, and even 
> > if the format has its warts, it's simply not *that* difficult to use.
> 
> No i just want a consistent use of rules, when they throw in linebreaks randomly instead of space, one could get the idea that they are up to no good. Because i suspect it is not part of the format.
> 
> 
> > Honestly, the whitespace is not one of its warts, 
> 
> Whitespace???? what is that?
> no more than is the
> > mostly free use of whitespace in modern programming languages.  To my
> > mind the biggest warts have to do with all the variations required to
> > properly use algebraic notation.
> > 
> > Rather than this:
> > 
> >     1. f4 e6  2. g4 Qh4 #
> > 
> > I would really prefer something like
> > 
> >     1. Pf2-f4 Pe7-e6  2. Pg2-g4 Qd8-h4 #
> 
> Well my game do not need any of that just integer to from, and i will take care of pawn promotion and castling. I simply got tired i read out just the tiles and the castlings and promotions. The rest the engine translate.
> 
> > But I'm not going to get my way on this any more than you are.  PGN,
> > built around existing algebraic chess notation, is already well
> > established.  Whining about it won't fix it.
> > 
> > You, of course, are free not to use it.  You can invent whatever
> > notation fits your needs.  But if you are ever going to want to
> > interoperate with other systems, it's highly recommended.
> 
> Done! And it will import PGN and write PGN, but the engine do not use it, until i strip to tiles and convert to integers.
> 
> However i will create sort of database it probably will use 6 bit form 7 bit to format.
>  
> > If you are interested in writing your own parser, it's an interesting
> > challenge.  But if not, there are several easily found by searching the
> > Web.
> It is done.
> Just had to remove the unnecessary information.
> I tried to parse something sensible but...
> Now i just take care of what the ruleengine need.
> >   -- Scott

I do see the use of the piece information, for example if you want to store just a setup. So i will use PGN as storage.

[toc] | [prev] | [next] | [standalone]

#38895

Jonas Thörnvall <jonas.thornvall@gmail.com> wrote:
> Scott Sauyet <scott@sauyet.com> wrote: 

>> jonas.t...@gmail.com wrote: 
>> 
>>> [... complaints about the PGN Chess Notation format...] 
>> 
>> I am so sorry that the world hasn't arranged itself for your 
>> convenience. It was a very petty decision by the world to make your 
>> parsing task so extraordinarily difficult. 
>> 
>> Maybe you're right. 
>> [ ... wisecrack about always using linebreaks ...] 

> I think you missunderstand me i am perfectly fine with using just 
> spaces, but *not* when they throw in linebreaks also randomly. And
> when you remove those the string separated glues.....

The point I was trying to make (sorry, sarcastically) is that the
format is designed so that it is easy for people to read and write and
simple enough for computers to parse and generate.  It grew out (I
assume) of the common algebraic annotation found in chess magazines. 

One important feature of being easy for people to read and write is
that line lengths should not be too long.  There is a hard maximum in
the format of 255-character lines, but a strong suggestion to restrict
lines to no more than 80 characters.  (A USENET lesson you might want
to learn as well.)  So PGN allows its tokens to be separated by 
whitespace characters such as space, tab, and newline.  It simply
doesn't care which one you use.  This is fairly trivial to handle in 
Javascript, since the regular expression component `\s` matches this
exactly (at least for the requisite ASCII text.)


>> Or maybe you could just accept that people have been successfully using 
>> the PGN format to describe chess games for a good long time, and even 
>> if the format has its warts, it's simply not *that* difficult to use.


> No i just want a consistent use of rules, when they throw in 
> linebreaks randomly instead of space, one could get the idea that they
> are up to no good. Because i suspect it is not part of the format.

PGN has two formats: your parser should be able to handle the more lax
import format, but your generation should generate the much more
restricted export format, described in the specification [1]

| 8.2.1: Movetext line justification
| 
| In PGN import format, tokens in the movetext do not require any 
| specific line justification.
| 
| In PGN export format, tokens in the movetext are placed left 
| justified on successive text lines each of which has less than 80
| printing characters.  As many tokens as possible are placed on a line
| with the remainder appearing on successive lines.  A single space 
| character appears between any two adjacent symbol tokens on the same 
| line in the movetext.  As with the tag pair section, a single empty 
| line follows the last line of data to conclude the movetext section.
| 
| Neither the first or the last character on an export format PGN line
| is a space.


>> Honestly, the whitespace is not one of its warts,

> Whitespace???? what is that?

Characters that leave no mark on the output but occupy some space
or change the subsequent text location: spaces, tabs, newlines, etc.


> [ ... ]


>> Rather than this: 
>> 
>> 1. f4 e6 2. g4 Qh4 # 
>> 
>> I would really prefer something like 
>> 
>> 1. Pf2-f4 Pe7-e6 2. Pg2-g4 Qd8-h4 #

> Well my game do not need any of that just integer to from, and i will
> take care of pawn promotion and castling. I simply got tired i read 
> out just the tiles and the castlings and promotions. The rest the 
> engine translate.

I'm talking about the PGN specification, and how I would prefer it had
been written.  I would not expect your internal storage to use it; it
would be a horrible format for internal use.  Use whatever makes sense.

As discussed in another thread, I *would* suggest the use of FEN 
notation between your server and its clients, though.  That is a
compact, easy-to-read, easy-to-generate format.


>> [ ... ]

>> You, of course, are free not to use [PGN]. You can invent whatever
>> notation fits your needs. But if you are ever going to want to 
>> interoperate with other systems, it's highly recommended.

> Done! And it will import PGN and write PGN, but the engine do not use
> it, until i strip to tiles and convert to integers. 

I'd be curious to see it.  Does it parse arbitrary PGN import format
documents, or only a restricted subset of them?  Does it export strict
PGN output documents?


> However i will create sort of database it probably will use 6 bit form 
> 7 bit to format.

What would you store in 6 - 7 bit format?  Moves?  Because while PGN 
contains moves, the format is about more than the moves.  It also 
allows for game data/metadata and annotations.


>> If you are interested in writing your own parser, it's an interesting 
>> challenge. But if not, there are several easily found by searching the 
>> Web.

> It is done. 
> Just had to remove the unnecessary information. 
> I tried to parse something sensible but... 
> Now i just take care of what the ruleengine need. 

That's perfectly reasonable, especially for a first pass.  But if you
want to use this to interoperate with other systems, you should be
able to parse legal import formats and generate compliant export
formats.  If you only want it in order to get a list of moves, it
should be easier.


  [1]: <https://ia802908.us.archive.org/26/items/pgn-standard-1994-03-12/PGN_standard_1994-03-12.txt>

[toc] | [prev] | [next] | [standalone]

#38889

Den söndag 27 september 2020 kl. 18:41:41 UTC+2 skrev Scott Sauyet:
> jonas.thornvall@gmail.com wrote:
> 
> > In practice it should be simple in reality to many monkeys at work. 
> > Any sain person would for the gameplay either use a "linebreak" 
> > always. 
> > 
> > Or simply use space between the ev - to - from, but the monkey just 
> > can't help themself. 
> 
> I am so sorry that the world hasn't arranged itself for your
> convenience. It was a very petty decision by the world to make your
> parsing task so extraordinarily difficult.
> 
> Maybe you're right.
> 
> Perhaps
> we
> should
> use
> linebreaks
> between
> all
> symbols
> .
> 
> Or maybe you could just accept that people have been successfully using
> the PGN format to describe chess games for a good long time, and even 
> if the format has its warts, it's simply not *that* difficult to use.
> 
> Honestly, the whitespace is not one of its warts, no more than is the
> mostly free use of whitespace in modern programming languages.  To my
> mind the biggest warts have to do with all the variations required to
> properly use algebraic notation.
> 
> Rather than this:
> 
>     1. f4 e6  2. g4 Qh4 #
> 
> I would really prefer something like
> 
>     1. Pf2-f4 Pe7-e6  2. Pg2-g4 Qd8-h4 #
> 
> But I'm not going to get my way on this any more than you are.  PGN,
> built around existing algebraic chess notation, is already well
> established.  Whining about it won't fix it.
> 
> You, of course, are free not to use it.  You can invent whatever
> notation fits your needs.  But if you are ever going to want to
> interoperate with other systems, it's highly recommended.
> 
> If you are interested in writing your own parser, it's an interesting
> challenge.  But if not, there are several easily found by searching the
> Web.
> 
>   -- Scott

I bet my parser a bit easier to read and shorter. It is just three functions some 50 lines.

[toc] | [prev] | [next] | [standalone]

#38896

Jonas Thörnvall <jonas.thornvall@gmail.com> wrote:
> Scott Sauyet <scott@sauyet.com> wrote: 

>> If you are interested in writing your own parser, it's an interesting
>> challenge. But if not, there are several easily found by searching the
>> Web.

> I bet my parser a bit easier to read and shorter. It is just three 
> functions some 50 lines.

And I bet it doesn't come close to handling the full PGN specification.

  -- Scott

[toc] | [prev] | [next] | [standalone]

#38891

Den söndag 27 september 2020 kl. 18:41:41 UTC+2 skrev Scott Sauyet:
> jonas.thornvall@gmail.com wrote:
> 
> > In practice it should be simple in reality to many monkeys at work. 
> > Any sain person would for the gameplay either use a "linebreak" 
> > always. 
> > 
> > Or simply use space between the ev - to - from, but the monkey just 
> > can't help themself. 
> 
> I am so sorry that the world hasn't arranged itself for your
> convenience. It was a very petty decision by the world to make your
> parsing task so extraordinarily difficult.
> 
> Maybe you're right.
> 
> Perhaps
> we
> should
> use
> linebreaks
> between
> all
> symbols
> .
> 
> Or maybe you could just accept that people have been successfully using
> the PGN format to describe chess games for a good long time, and even 
> if the format has its warts, it's simply not *that* difficult to use.
> 
> Honestly, the whitespace is not one of its warts, no more than is the
> mostly free use of whitespace in modern programming languages.  To my
> mind the biggest warts have to do with all the variations required to
> properly use algebraic notation.
> 
> Rather than this:
> 
>     1. f4 e6  2. g4 Qh4 #
> 
> I would really prefer something like
> 
>     1. Pf2-f4 Pe7-e6  2. Pg2-g4 Qd8-h4 #
> 
> But I'm not going to get my way on this any more than you are.  PGN,
> built around existing algebraic chess notation, is already well
> established.  Whining about it won't fix it.
> 
> You, of course, are free not to use it.  You can invent whatever
> notation fits your needs.  But if you are ever going to want to
> interoperate with other systems, it's highly recommended.
> 
> If you are interested in writing your own parser, it's an interesting
> challenge.  But if not, there are several easily found by searching the
> Web.
> 
>   -- Scott

Ended up like this, for some reason i do not catch the castling though.
newChessArr=[];
function tileCompare(gameString){
	var k=0;
	for (var i=0;i<gameString.length;i++){
	gstr1=gameString.charAt(i);
	gstr2=gameString.charAt(i+1);
	gstr3=gameString.charAt(i+2);
	gstr4=gameString.charAt(i+3);
	gstr5=gameString.charAt(i+4);
	gstring=gstr1+gstr2;
	gstring4=gstr1+gstr2+gstr3+gstr4;
	gstring5=gstr1+gstr2+gstr3+gstr4+gstr5;
	alert(gstring5);
	   for (var j=0;j<tileArr.length;j++){
			if (gstring==tileArr[j]){
				newChessArr[k]=tileArr[j]+"\r\n";
				k++;
			} 
			if (gstring4=="O-O "){
			    newChessArr[k]=gstring4+"\r\n";
			}
			if (gstring5=="O-O-O"){
			    newChessArr[k]=gstring5+"\r\n";
			}
	   }
	}
	alert("jonas"+newChessArr);
}

[toc] | [prev] | [next] | [standalone]

#38892

Den söndag 27 september 2020 kl. 20:45:34 UTC+2 skrev Jonas Thörnvall:
> Den söndag 27 september 2020 kl. 18:41:41 UTC+2 skrev Scott Sauyet:
> > jonas.thornvall@gmail.com wrote:
> > 
> > > In practice it should be simple in reality to many monkeys at work. 
> > > Any sain person would for the gameplay either use a "linebreak" 
> > > always. 
> > > 
> > > Or simply use space between the ev - to - from, but the monkey just 
> > > can't help themself. 
> > 
> > I am so sorry that the world hasn't arranged itself for your
> > convenience. It was a very petty decision by the world to make your
> > parsing task so extraordinarily difficult.
> > 
> > Maybe you're right.
> > 
> > Perhaps
> > we
> > should
> > use
> > linebreaks
> > between
> > all
> > symbols
> > .
> > 
> > Or maybe you could just accept that people have been successfully using
> > the PGN format to describe chess games for a good long time, and even 
> > if the format has its warts, it's simply not *that* difficult to use.
> > 
> > Honestly, the whitespace is not one of its warts, no more than is the
> > mostly free use of whitespace in modern programming languages.  To my
> > mind the biggest warts have to do with all the variations required to
> > properly use algebraic notation.
> > 
> > Rather than this:
> > 
> >     1. f4 e6  2. g4 Qh4 #
> > 
> > I would really prefer something like
> > 
> >     1. Pf2-f4 Pe7-e6  2. Pg2-g4 Qd8-h4 #
> > 
> > But I'm not going to get my way on this any more than you are.  PGN,
> > built around existing algebraic chess notation, is already well
> > established.  Whining about it won't fix it.
> > 
> > You, of course, are free not to use it.  You can invent whatever
> > notation fits your needs.  But if you are ever going to want to
> > interoperate with other systems, it's highly recommended.
> > 
> > If you are interested in writing your own parser, it's an interesting
> > challenge.  But if not, there are several easily found by searching the
> > Web.
> > 
> >   -- Scott
> 
> Ended up like this, for some reason i do not catch the castling though.
> newChessArr=[];
> function tileCompare(gameString){
> 	var k=0;
> 	for (var i=0;i<gameString.length;i++){
> 	gstr1=gameString.charAt(i);
> 	gstr2=gameString.charAt(i+1);
> 	gstr3=gameString.charAt(i+2);
> 	gstr4=gameString.charAt(i+3);
> 	gstr5=gameString.charAt(i+4);
> 	gstring=gstr1+gstr2;
> 	gstring4=gstr1+gstr2+gstr3+gstr4;
> 	gstring5=gstr1+gstr2+gstr3+gstr4+gstr5;
> 	alert(gstring5);
> 	   for (var j=0;j<tileArr.length;j++){
> 			if (gstring==tileArr[j]){
> 				newChessArr[k]=tileArr[j]+"\r\n";
> 				k++;
> 			} 
> 			if (gstring4=="O-O "){
> 			    newChessArr[k]=gstring4+"\r\n";
> 			}
> 			if (gstring5=="O-O-O"){
> 			    newChessArr[k]=gstring5+"\r\n";
> 			}
> 	   }
> 	}
> 	alert("jonas"+newChessArr);
> }

Well those if did not sit right.
This should work but for some reason the short cast misses at least in below case i checked it should be a space but...
O-O O-O-O

function tileCompare(gameString){
	var k=0;
	for (var i=0;i<gameString.length;i++){
		gstr1=gameString.charAt(i);
		gstr2=gameString.charAt(i+1);
		gstr3=gameString.charAt(i+2);
		gstr4=gameString.charAt(i+3);
		gstr5=gameString.charAt(i+4);
		gstring2=gstr1+gstr2;
		gstring3=gstr1+gstr2+gstr3;
		gstring4=gstr1+gstr2+gstr3+gstr4;
		gstring5=gstr1+gstr2+gstr3+gstr4+gstr5;
		if (gstring4=="O-O "){
			alert(parseInt(gstring4));
			newChessArr[k]=gstring3+"\r\n";
			k++;
		} else if (gstring5=="O-O-O"){
		    newChessArr[k]="O-O-O"+"\r\n";
			console.log(gstring5);
			k++;
		} else {
			for (var j=0;j<tileArr.length;j++){
				if (gstring2==tileArr[j]){
					newChessArr[k]=tileArr[j]+"\r\n";
					k++;
				} 
			}
		}
	}
	console.log("Fin "+newChessArr);
}

[toc] | [prev] | [next] | [standalone]

#38893

Den söndag 27 september 2020 kl. 22:29:44 UTC+2 skrev Jonas Thörnvall:
> Den söndag 27 september 2020 kl. 20:45:34 UTC+2 skrev Jonas Thörnvall:
> > Den söndag 27 september 2020 kl. 18:41:41 UTC+2 skrev Scott Sauyet:
> > > jonas.thornvall@gmail.com wrote:
> > > 
> > > > In practice it should be simple in reality to many monkeys at work. 
> > > > Any sain person would for the gameplay either use a "linebreak" 
> > > > always. 
> > > > 
> > > > Or simply use space between the ev - to - from, but the monkey just 
> > > > can't help themself. 
> > > 
> > > I am so sorry that the world hasn't arranged itself for your
> > > convenience. It was a very petty decision by the world to make your
> > > parsing task so extraordinarily difficult.
> > > 
> > > Maybe you're right.
> > > 
> > > Perhaps
> > > we
> > > should
> > > use
> > > linebreaks
> > > between
> > > all
> > > symbols
> > > .
> > > 
> > > Or maybe you could just accept that people have been successfully using
> > > the PGN format to describe chess games for a good long time, and even 
> > > if the format has its warts, it's simply not *that* difficult to use.
> > > 
> > > Honestly, the whitespace is not one of its warts, no more than is the
> > > mostly free use of whitespace in modern programming languages.  To my
> > > mind the biggest warts have to do with all the variations required to
> > > properly use algebraic notation.
> > > 
> > > Rather than this:
> > > 
> > >     1. f4 e6  2. g4 Qh4 #
> > > 
> > > I would really prefer something like
> > > 
> > >     1. Pf2-f4 Pe7-e6  2. Pg2-g4 Qd8-h4 #
> > > 
> > > But I'm not going to get my way on this any more than you are.  PGN,
> > > built around existing algebraic chess notation, is already well
> > > established.  Whining about it won't fix it.
> > > 
> > > You, of course, are free not to use it.  You can invent whatever
> > > notation fits your needs.  But if you are ever going to want to
> > > interoperate with other systems, it's highly recommended.
> > > 
> > > If you are interested in writing your own parser, it's an interesting
> > > challenge.  But if not, there are several easily found by searching the
> > > Web.
> > > 
> > >   -- Scott
> > 
> > Ended up like this, for some reason i do not catch the castling though.
> > newChessArr=[];
> > function tileCompare(gameString){
> > 	var k=0;
> > 	for (var i=0;i<gameString.length;i++){
> > 	gstr1=gameString.charAt(i);
> > 	gstr2=gameString.charAt(i+1);
> > 	gstr3=gameString.charAt(i+2);
> > 	gstr4=gameString.charAt(i+3);
> > 	gstr5=gameString.charAt(i+4);
> > 	gstring=gstr1+gstr2;
> > 	gstring4=gstr1+gstr2+gstr3+gstr4;
> > 	gstring5=gstr1+gstr2+gstr3+gstr4+gstr5;
> > 	alert(gstring5);
> > 	   for (var j=0;j<tileArr.length;j++){
> > 			if (gstring==tileArr[j]){
> > 				newChessArr[k]=tileArr[j]+"\r\n";
> > 				k++;
> > 			} 
> > 			if (gstring4=="O-O "){
> > 			    newChessArr[k]=gstring4+"\r\n";
> > 			}
> > 			if (gstring5=="O-O-O"){
> > 			    newChessArr[k]=gstring5+"\r\n";
> > 			}
> > 	   }
> > 	}
> > 	alert("jonas"+newChessArr);
> > }
> 
> Well those if did not sit right.
> This should work but for some reason the short cast misses at least in below case i checked it should be a space but...
> O-O O-O-O
> 
> function tileCompare(gameString){
> 	var k=0;
> 	for (var i=0;i<gameString.length;i++){
> 		gstr1=gameString.charAt(i);
> 		gstr2=gameString.charAt(i+1);
> 		gstr3=gameString.charAt(i+2);
> 		gstr4=gameString.charAt(i+3);
> 		gstr5=gameString.charAt(i+4);
> 		gstring2=gstr1+gstr2;
> 		gstring3=gstr1+gstr2+gstr3;
> 		gstring4=gstr1+gstr2+gstr3+gstr4;
> 		gstring5=gstr1+gstr2+gstr3+gstr4+gstr5;
> 		if (gstring4=="O-O "){
> 			alert(parseInt(gstring4));
> 			newChessArr[k]=gstring3+"\r\n";
> 			k++;
> 		} else if (gstring5=="O-O-O"){
> 		    newChessArr[k]="O-O-O"+"\r\n";
> 			console.log(gstring5);
> 			k++;
> 		} else {
> 			for (var j=0;j<tileArr.length;j++){
> 				if (gstring2==tileArr[j]){
> 					newChessArr[k]=tileArr[j]+"\r\n";
> 					k++;
> 				} 
> 			}
> 		}
> 	}
> 	console.log("Fin "+newChessArr);
> }

Came up with a totally mad solution, because i have no idea whatsoever what whitespace actually used between the castlings, it's ain't space or linebreak \r\n for sure.

newChessArr=[];
function tileCompare(gameString){
	var k=0;
	for (var i=0;i<gameString.length;i++){
		gstr0=gameString.charAt(i-1);
		gstr1=gameString.charAt(i);
		gstr2=gameString.charAt(i+1);
		gstr3=gameString.charAt(i+2);
		gstr4=gameString.charAt(i+3);
		gstr5=gameString.charAt(i+4);
		gstring2=gstr1+gstr2;
		gstring3=gstr1+gstr2+gstr3;
		gstring4=gstr1+gstr2+gstr3+gstr4;
		gstring5=gstr1+gstr2+gstr3+gstr4+gstr5;
		
		if (gstring3=="O-O" && gstr4!="-" && gstr0!="-"){
			newChessArr[k]=gstring3+"\r\n";
			k++;
		} else if (gstring5=="O-O-O"){
		    newChessArr[k]="O-O-O"+"\r\n";
			k++;
		} else {
			for (var j=0;j<tileArr.length;j++){
				if (gstring2==tileArr[j]){
					newChessArr[k]=tileArr[j]+"\r\n";
					k++;
				} 
			}
		}
	}
	console.log("Fin "+newChessArr);
}

[toc] | [prev] | [next] | [standalone]

#38894

Den söndag 27 september 2020 kl. 02:14:37 UTC+2 skrev Jonas Thörnvall:
> In practice it should be simple in reality to many monkeys at work.
> Any sain person would for the gameplay either use a "linebreak" always.
> 
> Or simply use space between the   ev - to - from, but the monkey just can't help themself.
> 
> Some think that randomly glue together moves a good idea. If you try to exchange the "most usual banana" the space to a linebreak. They present you with this. Is this kind of encoding really built in to the format or is the programmers that try to trip eachother, it seem random to me?
> 
> Since i am not clairvoyant enough to know where they put in the linebreaks, i simply tried to replace every space with a line break thinking i could read them in three by three. But since they work in mysterious ways i am not able...Event->From->To
> 
> Anyone have a better idea to group them 3 by 3 for easy use?
> gameString = gameString.split(" ").join('\r\n');
> One just wonder why they could not done something like
> 1. To From
> 2. To From
> 3....
> Or skipped the fucking linebreaks altogheter, gone for just spaces? But not randomly together with the three properties, its absurd at best but more probably programmer humor...
> 
> 1.
> e4
> c5
> 2.
> Nf3
> e6
> 3.
> d4
> cxd4
> 4.
> Nxd4
> Nf6
> 5.
> Nc3
> d6
> 6.
> Be2
> Be77.
> O-O
> O-O
> 8.
> f4
> Nc6
> 9.
> Be3
> Bd7
> 10.
> Nb3
> a5
> 11.
> a4
> Nb4
> 12.
> Bf3Bc6
> 13.
> Nd4
> g6
> 14.
> Rf2
> e5
> 15.
> Nxc6
> bxc6
> 16.
> fxe5
> dxe5
> 17.
> Qf1Qc8
> 18.
> h3
> Nd7
> 19.
> Bg4
> h5
> 20.
> Bxd7
> Qxd7
> 21.
> Qc4
> Bh4
> 22.
> Rd2Qe7
> 23.
> Rf1
> Rfd8
> 24.
> Nb1
> Qb7
> 25.
> Kh2
> Kg7
> 26.
> c3
> Na6
> 27.
> Re2Rf8
> 28.
> Nd2
> Bd8
> 29.
> Nf3
> f6
> 30.
> Rd2
> Be7
> 31.
> Qe6
> Rad8
> 32.
> Rxd8Bxd8
> 33.
> Rd1
> Nb8
> 34.
> Bc5
> Rh8
> 35.
> Rxd8

Retract most said in thread i realised now that what i thought PGN was a from tile to tile format, is just a positional format with both white and black.

Even more troublesome the format not consistent when pawn,rook, knight  grab a piece you must provide (in some cases) because of ambivalence can occure.

One can wonder why they did chose such a case based system interpretation, and not a tile to tile consistent one. Probably historical reasons.

[toc] | [prev] | [next] | [standalone]

#38897

Jonas Thörnvall <jonas.thornvall@gmail.com> wrote:

> Retract most said in thread i realised now that what i thought PGN was
> a from tile to tile format, is just a positional format with both 
> white and black. 

It is a *game* format.  It describes a game: the players, the event, 
the date, the location, the final result, plus other metadata.  It
describes the moves of both players and offers the option to include
annotations.


> Even more troublesome the format not consistent when pawn,rook, knight
> grab a piece you must provide (in some cases) because of ambivalence
> can occure. 

This is what I suggested elsewhere:

| Rather than this:
| 
| 1. f4 e6 2. g4 Qh4 #
| 
| I would really prefer something like
| 
| 1. Pf2-f4 Pe7-e6 2. Pg2-g4 Qd8-h4 #

This format would need no disambiguation, and can even be used to 
describe casting and *en passant* moves.

But note that it's nearly twice as long as the original; that's not
likely to be popular in printed magazines, nor when you want to 
store games in a simple format.


> One can wonder why they did chose such a case based system 
> interpretation, and not a tile to tile consistent one. Probably 
> historical reasons.

I have no idea what you mean by tile to tile, unless it's what I 
described above.  (You could remove the piece names without any
ambiguity; I think they add something, but it would be fine without 
them.)  Unfortunately, neither of us is likely to get anyone to 
change this 25-year old format or the much older underlying 
algebraic notation.

  -- Scott

[toc] | [prev] | [next] | [standalone]

#38898

Den måndag 28 september 2020 kl. 23:25:36 UTC+2 skrev Scott Sauyet:
> Jonas Thörnvall <jonas.thornvall@gmail.com> wrote:
> 
> > Retract most said in thread i realised now that what i thought PGN was
> > a from tile to tile format, is just a positional format with both 
> > white and black. 
> 
> It is a *game* format.  It describes a game: the players, the event, 
> the date, the location, the final result, plus other metadata.  It
> describes the moves of both players and offers the option to include
> annotations.
> 
> 
> > Even more troublesome the format not consistent when pawn,rook, knight
> > grab a piece you must provide (in some cases) because of ambivalence
> > can occure. 
> 
> This is what I suggested elsewhere:
> 
> | Rather than this:
> | 
> | 1. f4 e6 2. g4 Qh4 #
> | 
> | I would really prefer something like
> | 
> | 1. Pf2-f4 Pe7-e6 2. Pg2-g4 Qd8-h4 #
> 
> This format would need no disambiguation, and can even be used to 
> describe casting and *en passant* moves.
> 
> But note that it's nearly twice as long as the original; that's not
> likely to be popular in printed magazines, nor when you want to 
> store games in a simple format.
> 
> 
> > One can wonder why they did chose such a case based system 
> > interpretation, and not a tile to tile consistent one. Probably 
> > historical reasons.
> 
> I have no idea what you mean by tile to tile, unless it's what I 
> described above.  (You could remove the piece names without any
> ambiguity; I think they add something, but it would be fine without 
> them.)  Unfortunately, neither of us is likely to get anyone to 
> change this 25-year old format or the much older underlying 
> algebraic notation.
> 
>   -- Scott

Hello Scott there is a guy who wrote a chess script called VanillaJSChess i found on GitHub he had this file called handlePGN.js that i suspect output UCI format for his engine.

But i am clueless as code reader, don't know what variable it expect in and what variable it return. If you can spot the in and out variables "that hopefully "read and output a full game as string or array". I am interested to know.

function algebraicNotation(){
  let colNotation = 'abcdefgh'.split('');
  let pieceShorthand, move, moveNotation;
  let notationLog = []

  for (let i=0;i<moveHistory.length;i+=2){
    moveNotation = ''
    for (let j=0;j<2;j++){
      move = moveHistory[i+j].move;
      //get letter of piece 
      if(move[2] === "Pawn") {
        pieceShorthand = '';
      } else if (move[2] === "Knight"){
        pieceShorthand = 'N'
      } else {
        pieceShorthand = move[2][0];  
      }
      //check if another piece can move there 
      if (moveHistory[i+j].double === 'column'){
        pieceShorthand += colNotation[move[0][1]];
      } else if (moveHistory[i+j].double === 'row'){
        pieceShorthand += String(8-move[0][0]);
      }

      //check if the move was a castle 
      if (moveHistory[i+j].castle){
        if (Math.abs(moveHistory[i+j].castle[1][1] - moveHistory[i+j].castle[0][1]) === 2){
             moveNotation += 'O-O';
        } else { 
             moveNotation += 'O-O-O';
        }
      } else if (moveHistory[i+j].capture) { //check if the move was a capture  
        if (pieceShorthand === '') {
          pieceShorthand = colNotation[move[0][1]];
          if (moveHistory[i+j].enPassant) {
            //debugger
          }
        }
        moveNotation += pieceShorthand + 'x' + colNotation[move[1][1]] +String(8-move[1][0]);
      } else {
        moveNotation += pieceShorthand+colNotation[move[1][1]]+String(8-move[1][0]);
      }

      if (moveHistory[i+j].promotion){
        moveNotation += '=' +  moveHistory[i+j].promotion;
      }

      // check if the move was a check or checkmate 
      if (moveHistory[i+j].check){ 
        if (moveHistory[i+j].checkmate) {
          moveNotation += '#' 
        } else {
          moveNotation += '+' 
        } 
      }
      //if white moved last 
      if (i+1 >= moveHistory.length){
        break
      }
      if (j === 0){moveNotation+= ' '}
    }
    notationLog.push(+ String(i/2+1)+'. '+ moveNotation)
  }
  return notationLog;
}






function readPGN(){
  //idea was to move each move 1 at a time. but what if they want to import and click through
  //what if they want to jump to a spot, or animate the game and change speeds. 
  //all options could be done by building moveHistory or undone moves
  return new Promise((resolve,reject)=>{
    let wasPlayingComputer = playingComputer;
    playingComputer = false;
  //   let pgnData = '1. Nf3 Nf6,2. Ne5 d6,3. Nxf7 Kxf7,4. e3 Nc6,5. Qh5+ Nxh5,6. f4 Nf6,7. h4 h6,8. h5 g5,9. hxg6+ Ke6,10. g7 Ng4,11. d3 Kf6,12. gxh8=Q+ Bg7,13. Qxd8 Nxd8'.split(',')
  //   let pgnData = '1. Nf3 Nc6,2. g3 d6,3. Bg2 Be6,4. O-O Qd7,5. Nc3 O-O-O,6. h4'.split(',');
    if (pgnText.value === "") {
      return
    }
    let cleanedPGN = pgnText.value.replace(/[\n\r]/g, '').replace(/,/g,'');
    let pgnData = cleanedPGN.split(/(\d+\.)/).filter(x=>!/(^\d+\.)/.test(x) && x !== '').map(x=>x.trim())
    let p1Color = whoWentFirst(pgnData[0].split(' ')[0]);
    if (p1Color !== firstMove){
      doToggleFirst().then(checkEachMove)
    } else {
      checkEachMove();  
    }
    async function checkEachMove(){
      let PGNboard = {}
      PGNboard.state = createSimulatedBoard(boards[0].state)
      boards.push(PGNboard)
      for (const twoMoves of pgnData){
        await findAndMakeMoves(twoMoves, PGNboard, p1Color);
      }
      boards.pop()
      setPGN(wasPlayingComputer)
      resolve();
    }
  });

  function createSimulatedBoard(board){
    let nextBoard = board.map(a=> Object.assign([],a)); //creates a board with all copied pieces 
    nextBoard.forEach((row,i)=>{
      row.forEach((square,j)=>{
        if (square){
          let clone = Object.assign( Object.create(Object.getPrototypeOf(square)), square);
          clone.rowCol = [...clone.rowCol]
          clone.action = JSON.parse(JSON.stringify(clone.action))
          nextBoard[i][j] = clone;
        }
      })
    });
    return nextBoard
  }

  function whoWentFirst(move){
    let row = move[move.length-1]
    return (row ==='3' || row === '4')
  }
}

async function findAndMakeMoves(twoMoves, PGNboard, turn){
  let moves = twoMoves.split(' ');
  let p1Color = turn;
  for (let move of moves) { 
    if (move === 'Rfe1'){
      debugger
    }
    let piecesOnBoard = getPiecesOnBoard(PGNboard);
    changePieceBoardID(piecesOnBoard,1)
    //breakdown
    let breakdown = breakdownMove(move,turn);
    breakdown.piece = getPieceName(move[0]);

    getMovesWithoutRating(piecesOnBoard);

    let piece = findMovingPiece(breakdown, turn, piecesOnBoard);

    breakdown.from = piece.rowCol 
    
    if (breakdown.capture){
      checkEnPassant(breakdown);  
    }

    simulateMove(breakdown, PGNboard.state)
    
    addMoveHistory(breakdown);

    //change for next move
    turn = !turn;
  }

  function simulateMove(breakdown, board){
    let to = breakdown.to;
    let from = breakdown.from;
    let promotion = breakdown.promotion;
    let castle = breakdown.castle;
    let enPassant = breakdown.enPassant;

    let piece =board[from[0]][from[1]];
    board[to[0]][to[1]] = piece;
    board[from[0]][from[1]] = null;

    if (promotion){
      let newPieceType = getPieceNameFromLetter(promotion);
      let promotedPiece = createPromotedPiece(newPieceType,null);
      board[to[0]][to[1]] = promotedPiece;
      promotedPiece.promoted = true;
      promotedPiece.color = piece.color;
      piece = promotedPiece;
    } else if (castle){
      board[castle[1][0]][castle[1][1]] = board[castle[0][0]][castle[0][1]]
      board[castle[1][0]][castle[1][1]].rowCol = castle[1]
      board[castle[1][0]][castle[1][1]].hasMoved = true;
      board[castle[0][0]][castle[0][1]] = null;
    } else if (enPassant) {
      board[enPassant[0]][enPassant[1]] = null;
    }

    piece.hasMoved = true;
    piece.rowCol = to;
  }

  function addMoveHistory(breakdown){
    moveHistory.push({move:[breakdown.from,breakdown.to,breakdown.piece],
    capture:breakdown.capture,castle:breakdown.castle,promotion:breakdown.promotion,
    enPassant:breakdown.enPassant})
    //debugger
  }

  function changePieceBoardID(piecesOnBoard,boardIndex){
    piecesOnBoard[true].forEach(piece=>{
      piece.boardID = boardIndex;
    })
    piecesOnBoard[false].forEach(piece=>{
      piece.boardID = boardIndex;
    })
  }

  function checkEnPassant(breakdown){
    if (PGNboard.state[breakdown.to[0]][breakdown.to[1]] === null){
      if (turn){
        breakdown.enPassant = [breakdown.to[0]+1,breakdown.to[1]]
      } else {
        breakdown.enPassant = [breakdown.to[0]-1,breakdown.to[1]]
      }
    }
  }

  function findMovingPiece(breakdown, turn, piecesOnBoard){
    let moveablePieces = piecesOnBoard[turn].filter(piece=>piece.constructor.name === breakdown.piece); 
    let pieceToMove,piece,possiblePiece;
    let possiblePieces = [];
    for (let i=0;i<moveablePieces.length;i++){
      piece = moveablePieces[i];
      if (breakdown.capture){
        possiblePiece = piece.action.legal.captures.find(move=> move[0] === breakdown.to[0] && move[1] === breakdown.to[1] );
      } else {
        possiblePiece = piece.action.legal.moves.find(move=> move[0] === breakdown.to[0] && move[1] === breakdown.to[1] );
      }
      if (breakdown.castle){
        return piece
      }
      if (possiblePiece) {
        possiblePieces.push(piece)  
      }
    }
    if (possiblePieces.length === 1 ){
      return possiblePieces[0]
    } else if (possiblePieces.length == 2) {
      if (breakdown.double) {
//         debugger
        let col = 'abcdefgh'.indexOf(breakdown.double)
        if (col > -1){
          return possiblePieces.find(x=>x.rowCol[1] === col)
        } else {
          return possiblePieces.find(x=>x.rowCol[0] === 8 - breakdown.double)
        }
      } else {
        debugger //double error somewhere
      }
    }
    if (!pieceToMove){debugger}
  }

  function breakdownMove(move,turn){
    let len;
    let breakdown = {};

    breakdown.capture = move.indexOf('x') !== -1;
    breakdown.promotion = move.indexOf('=') !== -1;
    breakdown.castle = move.indexOf('O-O') !== -1;
    breakdown.check =  move.indexOf('+') !== -1;
    breakdown.checkmate =  move.indexOf('#') !== -1;

    if (breakdown.capture) { 
      move =  move.replace('x','') 
      if (turn) { breakdown.capture = p2graveyard; } 
      else { breakdown.capture = p1graveyard; }
    }
    if (breakdown.check) { move = move.replace('+','') }
    if (breakdown.checkmate) { move = move.replace('#','') }

    if (breakdown.castle){
      if (move === "O-O"){
        if (p1Color){
          if (turn){
            breakdown.to = [7,6];
            breakdown.castle = [[7,7],[7,5]];
          } else {
            breakdown.to = [0,6];
            breakdown.castle = [[0,7],[0,5]];
          } 
        } else {
          if (turn){
            breakdown.to = [7,1];
            breakdown.castle = [[7,0],[7,2]];
          } else {
            breakdown.to = [0,1];
            breakdown.castle = [[0,0],[0,2]];
          } 
        }
      } else {
        if (p1Color){
          if (turn){
            breakdown.to = [7,2];
            breakdown.castle = [[7,0],[7,3]];
          } else {
            breakdown.to = [0,2]
            breakdown.castle = [[0,0],[0,3]];
          }
        } else {
          if (turn){
            breakdown.to = [7,5];
            breakdown.castle = [[7,7],[7,4]];
          } else {
            breakdown.to = [0,5]
            breakdown.castle = [[0,7],[0,4]];
          }
        }
      }
      return breakdown

    }

    if (breakdown.promotion) { 
      breakdown.promotion = move[move.indexOf('=')+1];
      move = move.split('=')[0]; 
    }

    len = move.length;
    if (len === 2){
      breakdown.piece = 'Pawn';
      breakdown.to = pgnToRowCol(move);
    } else {
      breakdown.piece = move[0];
      if (len === 3) {
        breakdown.to = pgnToRowCol(move.substring(1));
      } else if (len === 4){
          if ('abcdefg'.indexOf(move.substring(1,2)) === -1 ) {
            breakdown.double = move.substring(1,2);
          } else {
            breakdown.double = move.substring(1,2);
          }
          breakdown.to = pgnToRowCol(move.substring(2));
      } else {
        debugger
      }
    }
    return breakdown
  }
}
function pgnToRowCol(move){
  let colNotation = 'abcdefgh'.split('');
  let col = colNotation.indexOf(move[0]);
  let row = 8-move[1];
  return [row,col]
}

function getMovesWithoutRating(piecesOnBoard){
  clearAllLegalMoves(piecesOnBoard);
  getAllLegalMoves(piecesOnBoard);
}

function getPieceName(firstChar){
  if (firstChar === 'O'){
    return 'King'
  }else if ('KQRBNP'.indexOf(firstChar) === -1){
    return 'Pawn'
  } else if (firstChar === 'K') {
    return 'King'
  } else if (firstChar === 'Q') {
    return 'Queen'
  } else if (firstChar === 'R') {
    return 'Rook'
  } else if (firstChar === 'B') {
    return 'Bishop'
  } else if (firstChar === 'N') {
    return 'Knight'
  }
}

function setPGN(wasPlayingComputer){
  undoneMoves = moveHistory.reverse();
  playingComputer = wasPlayingComputer;
  moveHistory = [];
}
   

[toc] | [prev] | [next] | [standalone]

#38899

Jonas Thörnvall <jonas.t...@gmail.com> wrote:

> [... T]here is a guy who wrote a chess script called VanillaJSChess
> i found on GitHub he had this file called handlePGN.js that i 
> suspect output UCI format for his engine.

I assume UCI is the Universal Chess Interface [1].  I know nothing
about that protocol.  Nothing in a quick look at the code tells me
what format the author is using for internal position or game storage.

I'm sure with some dedicated time, we could puzzle that out.  But I'm
not particularly interested.

> But i am clueless as code reader, 

You might want to work on that, if you're trying to write an even
slightly sophisticated code project.

>                                   don't know what variable it expect 
> in and what variable it return. If you can spot the in and out 
> variables "that hopefully "read and output a full game as string or
> array". I am interested to know.
>
> [...much code deleted.  It can be found at [1] ...]


I glanced through `readPGN` and to me it looks like a terrible mess.
This "function" (scare quotes most definitely intended) takes no input
and returns no output except for a Promise that is never resolved with
a value or rejected with an error.  Instead it reads from some global
variable, `pgnText` and modifies the global variable `board` by 
pushing to it and popping from it (presumably it's some implementation
of a stack, possibly an array), but finally leaving it in the state
it started in.  Then it simply resolves with no value.

To understand a procedure like that, you will need to know much more
about the overall application design and the possible states that
might be involved.  To test it, you will have to shim several external
values, and even then it's not clear what important side-effects
you need to describe.

I don't find that at all worth my time.  You might get more
information by raising an issue ([3]) on that repository.  But do note
that the project was only in active development from March to May this
year... perhaps a Covid project?

  -- Scott


  [1]: <https://en.wikipedia.org/wiki/Universal_Chess_Interface>
  [2]: <https://github.com/VanillaJSChess/VanillaJSChess.github.io/blob/653b6e10b258a14ca2f72a215926bad6cd90e879/scripts/handlePGN.js>
  [3]: <https://github.com/VanillaJSChess/VanillaJSChess.github.io/issues/new>

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.javascript

csiph-web