From ee0b99ace82a7abdbaa2a64799b60d8f0d48b5fe Mon Sep 17 00:00:00 2001 From: Aleksander Sadikov Date: Wed, 28 Sep 2016 18:01:22 +0200 Subject: English translation for sins/3 added. --- prolog/problems/sorting/sins_3/en.py | 94 +++++++++++++++++++++++++++++++++++- 1 file changed, 93 insertions(+), 1 deletion(-) diff --git a/prolog/problems/sorting/sins_3/en.py b/prolog/problems/sorting/sins_3/en.py index 0bf7483..4194ad0 100644 --- a/prolog/problems/sorting/sins_3/en.py +++ b/prolog/problems/sorting/sins_3/en.py @@ -10,4 +10,96 @@ description = '''\ L = [1,2,3,3,4]. ''' -hint = {} +plan = ['''\ +

For starters, let's remember that we're inserting into a sorted list. Let's go through the list, +element by element, until we find a proper place for the new element.

+''', '''\ +

Step by step you compare the new element with the list's current head. The heads will be increasing in +value as the list is sorted. Which means that at some point the new element will become smaller than the +current head, right?

+''', '''\ +

If the new element X is larger than the current head H, then we insert it +somewhere in the tail -- this will be taken care of by the recursion, as always, right? And if it's not larger, +then we found the proper place for the new element and we insert it now in front of the current +head H! You know how to put two elements before the tail at the same time, right? (It's the +same as taking two elements out.)

+'''] + +hint = { + 'eq_instead_of_equ': '''\ +

The operator == is "stricter" than operator = in the sense that +for the latter it is enough to be able to make the two operands equal (unification).

+

Of course, you can also solve the exercise without explicit use of either of these two operators, just +remember that unification is implicitly performed with the predicate's arguments (head of clause).

+''', + + 'eq_instead_of_equ_markup': '''\ +

Perhaps the operator for unification (=) would be better?

+''', + + 'base_case': '''\ +

Did you think of a base case? This will probably be the case when you (finally) insert a new element +into the list.

+''', + + 'recursive_case': '''\ +

The base case is ok. However, what about the general recursive case?

+''', + + 'predicate_always_false': '''\ +

It seems your predicate is always "false". Did you give it the correct name, +or is it perhaps misspelled?

+

If the name is correct, check whether something else is misspelled, perhaps there is a full stop instead of +a comma or vice versa, or maybe you typed a variable name in lowercase?

+

It is, of course, also possible that your conditions are too restrictive, or even impossible to satisfy +(as would be, for example, the condition that X is simultaneously smaller and greater than +Y, or something similarly impossible).

+''', + + 'timeout': '''\ +

Is there an infinite recursion at work here? How will it ever stop?

+

Or perhaps is there a missing, faulty, or simply incompatible (with the general recursive case) base case?

+''', + + 'bad_[]_case': '''\ +

What's the result of inserting an element into an empty list? Surely not an empty list or even an +arbitrary result (a variable without an assigned value)?

+''', + + 'returns_elem_instead_of_list': '''\ +

You have to return a list, not an element.

+''', + + 'maxEl_base_case_missing': '''\ +

The solution is almost correct. But you probably forgot one specific case. What happens if you're trying +to insert a new largest element into the list? Try the following query.

+

?- sins(9, [1,2,3,4,5], L).

+''', + + 'x_and_head_swapped': '''\ +

Hmmm, what should be the ordering of the new element and the current head of the list?

+

?- sins(3, [1,2,4,5,6], L).

+''', + + 'duplicates_incorrect': '''\ +

Did you forget that duplicates are also allowed? The first query below works fine, the other one doesn't.

+

?- sins(3, [1,2,4,5,6], L).

+

?- sins(3, [1,2,3,4,5], L).

+''', + + 'unprotected_branch': '''\ +

Did you "protect" (with a condition) both options (branches)? Be careful, if one branch doesn't have a +condition, the first solution returned will probably be correct, but it will leave the door open for other +solutions which will not be correct. The semicolon stands for logical OR, not logical XOR. This means that +prolog can still search for solutions in the other branch even if the first branch's condition is satisfied! +That's why you need both conditions.

+

Try the following query and ask for more solutions.

+

?- sins(3, [1,2,4,5,6], L).

+''', + + 'forgotten_heads': '''\ +

Did you forget to return the heads, removed before the recursion, into the list? I did that, too... ;)

+

Look what happens with the query below and you'll immediately understand the error.

+

?- sins(4, [1,2,3,5,6], L).

+''', +} -- cgit v1.2.1