Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.javascript > #38771 > unrolled thread
| Started by | Jonas Thörnvall <jonas.thornvall@gmail.com> |
|---|---|
| First post | 2020-09-10 23:45 -0700 |
| Last post | 2020-09-14 14:47 -0700 |
| Articles | 2 on this page of 22 — 6 participants |
Back to article view | Back to comp.lang.javascript
Drop off an if evaluation? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-09-10 23:45 -0700
Re: Drop off an if evaluation? Arno Welzel <usenet@arnowelzel.de> - 2020-09-11 09:05 +0200
Re: Drop off an if evaluation? Julio Di Egidio <julio@diegidio.name> - 2020-09-11 03:33 -0700
Re: Drop off an if evaluation? Julio Di Egidio <julio@diegidio.name> - 2020-09-11 07:01 -0700
Re: Drop off an if evaluation? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2020-09-11 18:20 +0200
Re: Drop off an if evaluation? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-09-11 10:05 -0700
Re: Drop off an if evaluation? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-09-11 10:19 -0700
Re: Drop off an if evaluation? Julio Di Egidio <julio@diegidio.name> - 2020-09-11 11:20 -0700
Re: Drop off an if evaluation? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-09-11 11:43 -0700
Re: Drop off an if evaluation? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-09-11 12:18 -0700
Re: Drop off an if evaluation? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-09-11 14:28 -0700
Re: Drop off an if evaluation? luserdroog <luser.droog@gmail.com> - 2020-09-12 20:59 -0700
Re: Drop off an if evaluation? luserdroog <luser.droog@gmail.com> - 2020-09-12 21:49 -0700
Re: Drop off an if evaluation? luserdroog <luser.droog@gmail.com> - 2020-09-12 23:15 -0700
Re: Drop off an if evaluation? John G Harris <niam@jghnorth.org.uk.invalid> - 2020-09-13 11:13 +0100
Re: Drop off an if evaluation? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-09-13 04:00 -0700
Re: Drop off an if evaluation? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-09-13 04:09 -0700
Re: Drop off an if evaluation? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-09-13 04:47 -0700
Re: Drop off an if evaluation? luserdroog <luser.droog@gmail.com> - 2020-09-13 22:56 -0700
Re: Drop off an if evaluation? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-09-14 08:22 -0700
Re: Drop off an if evaluation? luserdroog <luser.droog@gmail.com> - 2020-09-14 10:55 -0700
Re: Drop off an if evaluation? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-09-14 14:47 -0700
Page 2 of 2 — ← Prev page 1 [2]
| From | luserdroog <luser.droog@gmail.com> |
|---|---|
| Date | 2020-09-14 10:55 -0700 |
| Message-ID | <43e90c05-f02e-49d7-9da4-478b52ee6769o@googlegroups.com> |
| In reply to | #38791 |
On Monday, September 14, 2020 at 10:22:28 AM UTC-5, Jonas Thörnvall wrote: > Den måndag 14 september 2020 kl. 07:56:14 UTC+2 skrev luserdroog: > > On Sunday, September 13, 2020 at 6:47:52 AM UTC-5, Jonas Thörnvall wrote: > > > Den söndag 13 september 2020 kl. 13:00:13 UTC+2 skrev Jonas Thörnvall: > > > > Den söndag 13 september 2020 kl. 12:13:12 UTC+2 skrev John G Harris: > > > > > On Sat, 12 Sep 2020 20:59:00 -0700 (PDT), luserdroog > > > > > <luser.droog@gmail.com> wrote: > > > > > > > > > > > > > > > <snip> > > > > > >I agree with Julio here. Having a bunch of similarly named variables > > > > > >like these just screams out for a data structure. Put the complexity > > > > > >into the data structure and then the code *WILL* be shorter (if you > > > > > >keep working at it!) and it will be easier to write, read, and > > > > > >reason about. > > > > > <snip> > > > > > > > > > > Putting their advice in as few words as possible : > > > > > > > > > > Think first > > > > > Code after > > > > > > > > > > John > > > > > > > > Putting boolean for movements of individual pieces is just the kind of abstractions "I" try to avoid. I guess though you mean i should use the "tile numbering" to keep track on false and true "moved or not". > > > > > > > > For me there is something about write things in cleartext, because then you do not need try figure out what is going on. > > > > > > > > Either the thingy is untouched or its not, either the thingy is marked for movement or its not. > > > > > > > > Nah abstractions should probably be used where they make things easier lifting and unveil "code" into functional statements, not be used to supress information content into obscure structures whos inhabitants are unknown and unnamed. > > > > > > > > Well that is my thought on the subject. > > > > > > > > JT > > > > > > The only knowledge/information needed to fully understand my chess it to just write down a flowchart and it even won't be that big. Or better up some JSP chart. You do not even have to understand Javascript programming. Just start with the functions and break them down. > > > > That's kinda the crux of the issue right there. The functions should > > already be broken down into bite-size pieces with a nice descriptive > > name, a clear interface, and no more than 10 lines at most. > > > > Every time you find yourself writing a long comment about a for loop > > or something, a "paragraph" of code, consider wrapping that whole > > loop in a function and giving it a name. The name is a "free" comment. And it lets you /collapse/ the for loop and remove it from > > the larger function, making the function smaller and easier to read. > > > > A good function should roughly contain just /one/ syntactic > > construct IMO. One loop. Or one if/else to decide which subfunction > > to call. Then you can quickly read each function by itself to see > > if it makes sense. And you can spot bugs and problem areas more > > easily. > > > > In contrast, with storybook code you have to maintain the whole > > saga in your head. You have to remember the exact sequence of > > events that led to the calculation of each variable ..., any tweak > > in one place can have weird effects elsewhere in the program... > > I do not know whatever piece of my code you think off because there is hardly any function over 10 lines except for board initiation, and almost all use the loops to call other functions after a new assignment. > > Where are those giant functions you speak off? Ok. I think I was talking to myself from 10 years ago. If you don't have this bad habit I described, that's good! Maybe I was off base here. I'm sorry.
[toc] | [prev] | [next] | [standalone]
| From | Jonas Thörnvall <jonas.thornvall@gmail.com> |
|---|---|
| Date | 2020-09-14 14:47 -0700 |
| Message-ID | <ff121652-158f-421b-ba75-19a2245a3cceo@googlegroups.com> |
| In reply to | #38792 |
Den måndag 14 september 2020 kl. 19:55:36 UTC+2 skrev luserdroog: > On Monday, September 14, 2020 at 10:22:28 AM UTC-5, Jonas Thörnvall wrote: > > Den måndag 14 september 2020 kl. 07:56:14 UTC+2 skrev luserdroog: > > > On Sunday, September 13, 2020 at 6:47:52 AM UTC-5, Jonas Thörnvall wrote: > > > > Den söndag 13 september 2020 kl. 13:00:13 UTC+2 skrev Jonas Thörnvall: > > > > > Den söndag 13 september 2020 kl. 12:13:12 UTC+2 skrev John G Harris: > > > > > > On Sat, 12 Sep 2020 20:59:00 -0700 (PDT), luserdroog > > > > > > <luser.droog@gmail.com> wrote: > > > > > > > > > > > > > > > > > > <snip> > > > > > > >I agree with Julio here. Having a bunch of similarly named variables > > > > > > >like these just screams out for a data structure. Put the complexity > > > > > > >into the data structure and then the code *WILL* be shorter (if you > > > > > > >keep working at it!) and it will be easier to write, read, and > > > > > > >reason about. > > > > > > <snip> > > > > > > > > > > > > Putting their advice in as few words as possible : > > > > > > > > > > > > Think first > > > > > > Code after > > > > > > > > > > > > John > > > > > > > > > > Putting boolean for movements of individual pieces is just the kind of abstractions "I" try to avoid. I guess though you mean i should use the "tile numbering" to keep track on false and true "moved or not". > > > > > > > > > > For me there is something about write things in cleartext, because then you do not need try figure out what is going on. > > > > > > > > > > Either the thingy is untouched or its not, either the thingy is marked for movement or its not. > > > > > > > > > > Nah abstractions should probably be used where they make things easier lifting and unveil "code" into functional statements, not be used to supress information content into obscure structures whos inhabitants are unknown and unnamed. > > > > > > > > > > Well that is my thought on the subject. > > > > > > > > > > JT > > > > > > > > The only knowledge/information needed to fully understand my chess it to just write down a flowchart and it even won't be that big. Or better up some JSP chart. You do not even have to understand Javascript programming. Just start with the functions and break them down. > > > > > > That's kinda the crux of the issue right there. The functions should > > > already be broken down into bite-size pieces with a nice descriptive > > > name, a clear interface, and no more than 10 lines at most. > > > > > > Every time you find yourself writing a long comment about a for loop > > > or something, a "paragraph" of code, consider wrapping that whole > > > loop in a function and giving it a name. The name is a "free" comment. And it lets you /collapse/ the for loop and remove it from > > > the larger function, making the function smaller and easier to read. > > > > > > A good function should roughly contain just /one/ syntactic > > > construct IMO. One loop. Or one if/else to decide which subfunction > > > to call. Then you can quickly read each function by itself to see > > > if it makes sense. And you can spot bugs and problem areas more > > > easily. > > > > > > In contrast, with storybook code you have to maintain the whole > > > saga in your head. You have to remember the exact sequence of > > > events that led to the calculation of each variable ..., any tweak > > > in one place can have weird effects elsewhere in the program... > > > > I do not know whatever piece of my code you think off because there is hardly any function over 10 lines except for board initiation, and almost all use the loops to call other functions after a new assignment. > > > > Where are those giant functions you speak off? > > Ok. I think I was talking to myself from 10 years ago. If you > don't have this bad habit I described, that's good! Maybe I > was off base here. I'm sorry. Well the code is available at github, the published folder is the "chess" folder. https://github.com/jonasth/jonasth.github.io And the site on github below https://jonasth.github.io/chess/chess.html Have not fixed 100& functionality of check. But i think castlings are 100% working. Check have two or three cases to fix "prevent king from catch" easy, prevent that you move a piece and get own king in check "remove those moves", three tell when no pieces can block King and your check mate. And there seem to be curious cases when King take opponent without realise it become in check.... That one will be harder i hate look for bugs that not obvious. Otherwise then that it is just en passant. And of course a more comprehensive version of rules already done, doing analyse at depth will be the real challenge, to come up with what constitutes a chess engine and what parameters to use for tuning. I have many ideas though howto evaluate board using different criterias. "That may or may not be good for chess evaluation".
[toc] | [prev] | [standalone]
Page 2 of 2 — ← Prev page 1 [2]
Back to top | Article view | comp.lang.javascript
csiph-web