Anonymous user
Talk:Amb: Difference between revisions
m
added a section hearder (name) to the 1st (unnamed) discussion (to put the TOC in the proper place).
m (added a section hearder (name) to the 1st (unnamed) discussion (to put the TOC in the proper place).) |
|||
| (6 intermediate revisions by 5 users not shown) | |||
Line 1:
==A better sentence?==
"The Amb operator takes some number of expressions (or values if that's simpler in the language) and nondeterministically yields the one or fails if given no parameter, amb returns the value that doesn't lead to failure."
Line 15 ⟶ 17:
(This variant not really great but I believe it is accurate and complete). -- RDM 12:53, 27 August 2009 (EDT)
I've taken the plunge and clarified and expanded the description of the task.[[User:Kazinator|Kazinator]] ([[User talk:Kazinator|talk]]) 15:14, 31 October 2015 (UTC)
==Nondeterministic==
Line 20 ⟶ 23:
Can we assume, for the purposes of the task, that the pseudo-randomness of "random" numbers available on PCs without external assistance qualify as non-deterministic? --[[User:Short Circuit|Short Circuit]] 22:47, 22 March 2008 (MDT)
:The non-determinism is a red herring. No implementation of Amb I've seen is actually random. The important feature of Amb is backtracking via capturing the continuation. The result is something closer to exception handling. (Can Amb be implemented using only exceptions?)
::non-determinism doesn't mean randomness in computer science. This is clarified in the new task description.[[User:Kazinator|Kazinator]] ([[User talk:Kazinator|talk]]) 15:14, 31 October 2015 (UTC)
:This is an advanced (almost esoteric) concept covered in SICP among other places. See: http://c2.com/cgi/wiki?AmbSpecialForm [[wp:Continuation]]. --[[User:IanOsgood|IanOsgood]] 09:30, 24 March 2008 (MDT)
Line 38 ⟶ 42:
--[[User:Sluggo|Sluggo]] 22:20, 6 September 2009 (UTC)
: Non-termination presents a problem for continuations and threads also; they don't solve the issue at all of when a branch of the computation fails by not terminating! Processing is stuck there, that is all. Exception handling isn't in an of itself a solution; rather, nonlocal control transfers can support an explicit backtracking solution by providing a convenient direct branch to some earlier "top level" in cases when failure or success are confirmed.
For my part, and demonstrated by my VBScript entry, I don't think I understood the task at all. I don't think many did. Even after reading all this, I'm still not sure I do. I did have fun, all the same, coming up with the VBScript code. --[[User:Axtens|Axtens]] 08:47, 16 February 2010 (UTC)
Line 56 ⟶ 61:
Please put a complete C program, that can be compiled as it is.
:We'll need more than that. What's the error you're getting? --[[User:Mwn3d|Mwn3d]] 18:34, 27 June 2009 (UTC)
I've put an alternate C implementation at:
https://github.com/jimwise/shared/tree/master/nondeterminism/c
if that helps -- this uses setjmp/longjmp, and includes a few examples; no external code is required.
== Go ==
I added a solution inspired more by [http://www-formal.stanford.edu/jmc/basis.html McCarthy's original paper] than the SICP presentation. McCarthy talks about functions which may be "undefined" in some cases and says, "...when the computation process fails to terminate, the result is undefined." (bottom of p. 7 in the PDF.) The Go version handles this with channels and go routines.
: It seems they've taken down that server. Here's the Wayback Machine link: [https://web.archive.org/web/20120901194931/http://www-formal.stanford.edu/jmc/basis.html McCarthy's Paper via Wayback Machine] --[[User:Rabuf|Rabuf]] ([[User talk:Rabuf|talk]]) 17:09, 7 November 2013 (UTC)
:: It's still there, the wiki markup for the link was incorrect (I've corrected it). —[[User:dchapes|dchapes]] ([[User talk:dchapes|talk]] | [[Special:Contributions/dchapes|contribs]]) 14:19, 5 September 2014 (UTC)
He defines amb as a binary operator on x and y where either or both may be undefined. That is, x and y are separate computations which may or may not terminate. He talks of functions having possible values (plural) and while he doesn't specify that amb must enumerate its defined values, we assume so because we want to do backtracking. This binary enumerating amb can be composed into a form that works with multiple values. The result, in a context of computations that take an unknown amount of time, is a form that may yield a number of values, but perhaps not immediately, perhaps not all at once, perhaps never. A goroutine supplying values over a channel has this capability.
The function ambString shows this and gives us the enumerating property we need for searching. It takes a string slice and iterates over it, providing slices of length 1 on the result channel. If preparing the result slices were truly computations of unknown and potentially infinite duration, preparation of each slice could be done as a separate goroutine, but this would be overkill for the task. The important part is the result channel. The function creates the channel, starts the goroutine, and returns the channel without waiting for the goroutine to do anything. A caller of this function gets the channel back almost immediately, but then should assume that it might have to wait an unknown amount of time for an unknown number of results.
The function ambChain relies another concept of McCarthy's paper, "operator Am(x,π(x)) whose values are all x's satisfying π(x)." Here we understand that x is a computation with multiple possible values and π is a predicate that selects a subset of them. In ambChain, the call to ambString in the inner loop is the "x" of Am, and the boolean expression in the if statement on the next line is the predicate π. Just as the composed amb function of ambString runs as a separate goroutine, this Am operation runs as a separate goroutine. These goroutines started as the inner loop of the matching operation execute concurrently. The results of the Am operation are new, longer chains of words which are returned on a channel, maintaining amb behavior. ambChain has only a single result channel. The concurrent goroutines all send their matches on this common channel. The caller of ambChain does not know how many matches might be returned, but ambChain can recognize when it has enumerated all possibilities. It uses a sync.WaitGroup to track completion of goroutines and can close the result channel as ambString does.
The driver main enumerates the results of chaining the four word lists. If there were no matches, there would be no output. If there were multiple matches, it would print them all. If the computations were lengthy, results would be printed as the computations completed. The separate goroutines of ambString and ambChain ensure that even if some computations failed to terminate, any computations which could complete would, and return any found matches. —[[User:Sonia|Sonia]] 02:22, 29 February 2012 (UTC)
| |||