Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Let's consider a similar query first: [Edit: Do this <strong>without</strong> adding your own definition ; <code>member/2</code> is already defined]</p> <pre><code>?- member(a,[b,a]). true. </code></pre> <p>In this case you get the optimal answer: There is exactly one solution. But when exchanging the elements in the list we get:</p> <pre><code>?- member(a,[a,b]). true ; false. </code></pre> <p>Logically, both are just the affirmation that the query is true.</p> <p>The reason for the difference is that in the second query the answer <code>true</code> is given immediately upon finding <code>a</code> as element of the list. The remaining list <code>[b]</code> does not contain a fitting element, but this is not yet examined. Only upon request (hitting <kbd>SPACE</kbd> or <kbd>;</kbd>) the rest of the list is tried with the result that there is no further solution.</p> <p>Essentially, this little difference gives you a hint when a computation is completely finished and when there is still some work to do. For simple queries this does not make a difference, but in more complex queries these open alternatives (choicepoints) may accumulate and use up memory.</p> <p>Older toplevels always asked if you want to see a further solution, even if there was none.</p> <p>Edit:</p> <p>The ability to avoid asking for the next answer, if there is none, is extremely dependent on the very implementation details. Even within the same system, and the same program loaded you might get different results. In this case, however, I was using SWI's built-in definition for <code>member/2</code> whereas you used your own definition, which overwrites the built-in definition.</p> <p>SWI uses the following definition as built-in which is logically equivalent to yours but makes avoiding unnecessary choice points easier to SWI &mdash; but many other systems cannot profit from this:</p> <pre><code>member(B, [C|A]) :- member_(A, B, C). member_(_, A, A). member_([C|A], B, _) :- member_(A, B, C). </code></pre> <p>To make things even more complex: Many Prologs have a different toplevel that does never ask for further answers when the query does not contain a variable. So in those systems (like YAP) you get a wrong impression.</p> <p>Try the following query to see this:</p> <pre><code>?- member(X,[1]). X = 1. </code></pre> <p>SWI is again able to determine that this is the only answer. But YAP, e.g., is not.</p>
    singulars
    1. This table or related slice is empty.
    1. POProlog list membership, multiple results returned
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USfalse
    1. USfalse
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POProlog list membership, multiple results returned
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COI actually still get the true and false answer for both of those queries. In the second query I dont see why it would continue trying to examine [b] when the first rule has already found a as the head of the list.
      singulars
      1. PO
      1. USJustin
    2. CO@Justin Becasue you pressed the `;` button. It examined the head, found it matches, and reported back `true` to you. But it still hasn't looked at the rest of the list.
      singulars
      1. PO
      1. USWill Ness
    3. CO@WillNess so your saying even though rule 1 has satisfied the query, rule 2 will be evaluated (and therefore examining the tail of the list [b] and failing)?
      singulars
      1. PO
      1. USJustin
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload