search

aimacode / aima-javascript

Javascript visualization of algorithms from Russell And Norvig's "Artificial Intelligence - A Modern Approach"
http://aimacode.github.io/aima-javascript/
MIT License
541 stars 217 forks source link

3-Solving-Problems-By-Searching #57

Closed redblobgames closed 5 years ago

redblobgames commented 7 years ago

Let's discuss the visualizations for chapter 3 here.

norvig commented 7 years ago

These are looking very nice!

redblobgames commented 7 years ago

@nervgh For formatting, you might try prettier. I think its default settings are similar to the style used in this project. You can run prettier --write at the command line (works like standard --fix).

nervgh commented 7 years ago

@redblobgames

Take a look at the uniform cost search diagram on http://aimacode.github.io/aima-javascript/3-Solving-Problems-By-Searching/

By the way, it would be great to have anchors per section (algorithm). It would give readers the ability to make references directly to an algorithm. For example:

we used to have it animate on page load but now use a slider so that the reader has control over the speed of the process

Good. I will try to use it for visualization of a stage of execution:

  ----|---------     // <-- this is our slider
0%..............100%

Another dataset that may be useful is the bidirectional search diagram on the page. That one (drawn with canvas instead of svg because it has so many nodes) would let you show the "contour line" aspect of A. Breadth first search expands uniformly in all directions but A expands much more quickly towards the goal and slowly in other directions

I will keep this thought in my mind, but previously I will plan focus on fixing the bugs, following the project's code style and reducing dependencies (Vue).

prettier --write

I've heard about prettier before, thanks. I think you can add something like this into "Implementation Guide". I mean we should prefer automation over instructions (when we talk about the code style in my opinion).

redblobgames commented 7 years ago

@nervgh I agree, it would be nice to add anchors. Until recently none of the chapters were even close to being complete so we hadn't set up a table of contents or section links. I created #98 to track this.

I agree that automatic code formatting is nice, especially when multiple people are working on the same code. For the most part, it hasn't come up yet because we don't have a lot of people contributing code to the same chapter, and we've let the primary author of each chapter choose libraries and code style. I'll add something to the wiki.

nervgh commented 7 years ago

@redblobgames Hi, Amit. I'm sorry for the long response delay. Everyday tasks (job) take much time. The current status is:

3. Sometimes I see the same node in the priority queue more than once. Although there are some variants of A* that allow that, the version explained in the book does not allow a node to be in the priority queue more than once. You can see this in the uniform cost search pseudocode — it checks if a node is already in the priority queue before adding it. https://github.com/aimacode/aima-javascript/issues/57#issuecomment-322055509

fixed

2. The heuristic is not admissible or consistent. You can see this by searching from A to O. It will find the path A-D-E-I-K-N-O (g=19) but the path A-B-C-D-F-J-N-O is shorter (g=12). One of the properties listed in ch 3 is that the f value should be nondecreasing along the path. We should probably use an admissible heuristic although I admit I haven't actually thought about what that would be for this example (maybe we should switch to the example in the book). https://github.com/aimacode/aima-javascript/issues/57#issuecomment-322055509

I've tried fix this using existing data-set. I made re-weight of the edges and one little change of h(n) function commit

Please, give me your feedback about these problems. Can we consider them as resolved?

redblobgames commented 7 years ago

@nervgh In your code you have A skip the node if it's already in the queue. A should not skip the nodes that are already in the queue. See the last if statement in figure 3.14. If you skip that node then you lose the optimality of A*.

I don't understand what the dividing by 32 does but I will take another look at it when I get more time.

nervgh commented 7 years ago

@redblobgames

In your code you have A skip the node if it's already in the queue. A should not skip the nodes that are already in the queue. See the last if statement in figure 3.14. If you skip that node then you lose the optimality of A*.

Ok. I will investigate that issue.

I don't understand what the dividing by 32 does

I've played with existing data-set and have thought about how to adapt that. It is the stupid attempt to "scale down" euclidean distance :smile_cat:

I'm sorry, Amit, but I'm still like a child in AI :baby: Thank you for your time and patience.

redblobgames commented 7 years ago

@nervgh No worries! Our main goal is not to implement the algorithms (although that's sometimes necessary), but to figure out what the core concepts are that someone new to AI would need to understand. So it'll be helpful to us if you have suggestions on what concepts were most confusing for learning A. Then someone (you or someone else) can think about how best to show those concepts with the A diagram(s).

nervgh commented 7 years ago

@redblobgames I had the second edition of "Artificial Intelligence: A Modern Approach" when I wrote my first comment in this thread. That book was translated on my native (Russian) language. What does it mean?

The things like these to make confused me a little.

Now I have 3th edition on original (English) language. I see the book is much better explains many things :+1: Right now I cannot answer on your question. I think I need read it before I could be to say something.

redblobgames commented 7 years ago

@nervgh Aha! I had forgotten about the different editions. Yes, we have been working with the 3rd edition. I think the Java folk are moving to the 4th edition.

redblobgames commented 7 years ago

@Rishav159 Feedback from someone I showed this chapter to:

For bi-directional search, the behavior is the same for any location in the graph. Are there graphs where some locations are good for bi-directional search but other locations are bad? And if so, it might be useful to be able to position the begin/end nodes so that the reader can see some places it's good and some places it's bad.

My guess is that the current diagram is good for introducing the main idea but it doesn't answer the question of whether it's always better than breadth first search or if it's only sometimes better. That might requires a second diagram.

Rishav159 commented 7 years ago

If we assume that the starting and end points are known, there are very few instances where bi-directional bfs performs poorly than standard bfs. From what I can think of right now, bi-directional bfs visits a lot more nodes if the the destination is not reachable from the source node. Other than that, I can't think of any other case where bi-directional bfs performs worse than standard bfs.

nervgh commented 7 years ago

@redblobgames I read aima3 now and I see that we have not mentioned about of the advantages of "Iterative deepening depth-first search":

Iterative deepening combines the benefits of depth-first and breadth-first search. Like depth-first search, its memory requirements are modest: O(bd) to be precise. Like breadth-first search, it is complete when the branching factor is finite and optimal when the path cost is a nondecreasing function of the depth of the node.

It may cause a reader to the conclusion what only the bi-directional search has advantages vs another uninformed search algorithms.

I've found one very interesting comparison for me:

Iterative deepening search may seem wasteful because states are generated multiple times. It turns out this is not too costly. The reason is that in a search tree with the same (or nearly the same) branching factor at each level, most of the nodes are in the bottom level, so it does not matter much that the upper levels are generated multiple times

For example, if b = 10 and d = 5, the numbers are N (IDS) = 50 + 400 + 3, 000 + 20, 000 + 100, 000 = 123, 450 N (BFS) = 10 + 100 + 1, 000 + 10, 000 + 100, 000 = 111, 110

Here is the authors' summary about IDS:

In general, iterative deepening is the preferred uninformed search method when the search space is large and the depth of the solution is not known.

redblobgames commented 7 years ago

@nervgh Yes, this is one of the things we may change in the future. We were told that we should make the visualizations for people who are currently studying from the book, so we should not include the explanations that are in the book on the web pages. @Rishav159 and I thought we should include a small amount of explanation. After we get feedback from the authors of the book, we may need to remove the small explanations we have now, or make them longer.

nervgh commented 7 years ago

@redblobgames Thank you for the clarification!

nervgh commented 7 years ago

@redblobgames

A* should not skip the nodes that are already in the queue

fixed

I don't understand what the dividing by 32 does but I will take another look at it when I get more time.

fixed

It looks like the h(n) is admissible and consistent now. Am I wrong one more time? :smile_cat: The paths A->L and A->K assert it (for me).

However, there is 11pm on my clock at the moment and may be I should go to bed :sleeping: and I need look at that on next day :sweat_smile:

nervgh commented 7 years ago

@redblobgames

If you merge the master branch you will have a slider class to play with. We've found the slider to be more useful as it lets the reader see things step by step at their own pace instead of at the fixed speed of setInterval

The visualization of A* works with the slider from now.

redblobgames commented 7 years ago

@nervgh Looking pretty good!

(Side note: I think one day someone will figure out how to make the javascript code as short as the python version that Peter Norvig wrote (see https://github.com/aimacode/aima-python/blob/master/search.py#L395) — it reuses search functionality instead of each algorithm reimplementing search)

nervgh commented 7 years ago

@redblobgames Thank you! :smiley_cat:

+1 for reusing and simplification of the code

I want to complete the A* visualization. The checklist for my task I see as follows:

And I have two questions:

  1. Is it all or I've missed something?
  2. Can we look at the second item of the checklist above from the other side: can we reduce jQuery instead Vue (in the context of 3 chapter)?
redblobgames commented 7 years ago

@nervgh Yes, please format the code with prettier, and use two.js (and a little bit of jquery) instead of vue.

Although it would be possible to rewrite the entire chapter with vue instead of two.js, it has low benefit compared to other things we could do. This chapter is nearly complete. We have been letting whoever writes the majority of the chapter to choose the library (see issue #47), so vue would best be used in a new chapter rather than rewriting a chapter that already is implemented.

The reader does not care that you used vue vs something else. We want to focus on the things that benefit the reader :-)

nervgh commented 7 years ago

@redblobgames

please format the code with prettier

I think it would be reasonable to add the prettier as the devDependency to this project. I am not sure, do we really use all these (one, two, three) dependencies or we can clean up these?

The reader does not care that you used vue vs something else. We want to focus on the things that benefit the reader :-)

Do you mean cute cats on the page? :smile_cat: "The client does not care what we use behind the scene. He want to have a product which fits his expectations and/or does one thing better than another products on the market" =)

nervgh commented 7 years ago

@redblobgames

I've done two subtasks.

However, I can stay these changes as they are, squash all my commits and submit the pull request if you will approve that.

nervgh commented 6 years ago

@redblobgames I hope I have not said something awful and we could continue working on this task and finalize it in the future :smiley_cat:

redblobgames commented 6 years ago

@nervgh I'm terribly sorry! I was away for a few weeks and then I forgot to check this when I got back.

  1. No, we don't currently use all the dependencies, or even package.json at all. I think the people who set these up would like keep these in there. My involvement in this project is primarily for visualizations and not to choose coding style, libraries, build system, folder structure, web design, etc., so I'm going to leave those things to others.
  2. I agree that prettier's defaults aren't necessarily producing the nicest code, and I would hesitate to recommending it to everyone. In this case I thought it would help automate the switch from the style you were using to the style this project is using. For people already writing code in the project's style, prettier may make things worse. The main goal is to match the existing style.
  3. I agree that the imperative style you have now isn't as nice as what Vue or D3 would provide, since the construction of the table isn't supported by Two.js. At some point someone may want to revisit the choice of libraries for existing chapters. I think D3 would be the top choice based on the experience of several contributors, and it does seem like D3 is being used by people working on new chapters.
  4. Yes, please submit the pull request :-)
nervgh commented 6 years ago

@redblobgames don't worry about it! :v: We are humans and we make mistakes all the time. Especially I do :smile_cat: Anybody who does not work that one does not make them! (I am not sure how exactly to say this in English =)

  1. I think I could help with that
  2. I have not solution right now but I could investigate this problem and try to found something appropriate for us (it has low priority I think)
  3. It is done -- #106
redblobgames commented 5 years ago

This chapter is essentially design-complete so I'm closing this issue. There are minor improvements that are filed as separate issues.