Any religious argument based on expertise in a language is necessarily unconvincing to someone who doesn’t already consider that language to be special or holy. Numerous languages have been asserted by various religions to have special or divine properties: Sanskrit, Pali, Chinese, Hebrew, Aramaic, Greek, Latin, Arabic, Tibetan, Persian, and even English. The question of linguistic competence is often brought up by religious apologists seeking to deflect issues raised by skeptics about problematic passages in their scriptures, but when good translations and linguistic resources are available, this is just a smokescreen. When there are errors in fact or reasoning in a translation, or instances of morally reprehensible behaviour, the problems are rarely made better by referring to the primary text in the original language. (In fact, the problems are sometimes worse, as religious translators attempt to minimise or downplay those aspects of the text which they think might offend their target audience.)

The fact that a lack of linguistic expertise is not actually a real issue with many religious apologists is made evident by the double standard of insisting on linguistic qualifications from critics of their scriptures, while criticising the scriptures of others without studying those in their original language. For example, no Muslim apologist has ever refrained from arguing that the Torah has been corrupted, in spite of not being able to read Hebrew and not having any substantial knowledge of the history of Jewish scripture. Similarly, many of the popular apologists for various religions are not trained in the study of religion, nor in the fields whose findings they claim support their religious beliefs.

Linguistic expertise, or indeed expertise in any field, is nowhere as important as demonstrating the ability to reason. For example, if I claimed that the arguments made by the Indian Buddhist philosophers against monotheism are absolutely devastating, no monotheist would accept that they are disqualified from rebutting these arguments on the grounds that they cannot read Sanskrit. Arguments must stand or fall on their own merits, regardless of which language they are expressed in. Linguistic expertise may allow a religious believer to gain a deeper understanding of the texts of his or her religion, but it can never defend his or her beliefs against criticisms made on the basis of logic or facts.

In the intersection between history and language, we find the story of the tower of Babel (Gen. 11:1–8). In order for this story to be true, it would have to be possible to build a skyscraper using nothing but Bronze Age brick technology. Any material sturdy enough to support a tower that reached to the sky would also be durable enough to leave behind some evidence for the present day, but no such evidence exists, and it is difficult to believe that the technology was used in just the one tower if it had existed. Furthermore, we humans have subsequently built towers reaching into the sky. Indeed, we have entire cities full of them. We have even left the confines of the Earth’s surface and walked on the Moon. And yet none of these developments brought about any visible divine intervention. Instead, they are the products of science and engineering.

So, even though the spotlight is on biology as a field where science and religion are in conflict, it is not the only one. I have discussed some examples from history and linguistics above, but there are many others. The point is that the more broadly educated a person is, the more obvious it becomes that every religious belief can be explained as a human product of its time and place, without recourse to divine intervention. In order to maintain a belief in the literal inerrancy of the Bible, it is not sufficient merely to assert intelligent design creationism as an alternative to the biological theory of evolution. One must also propose alternate theories to the standard theories in the fields of archeology, linguistics, history, hydrology, geology, astronomy, material science, and so on.

Religious believers cannot accuse a skeptic of ignoring the evidence. As I hope I have shown, the more evidence one examines, the stronger the case becomes that religion is a human invention. Conversely, religious believers often do not examine the evidence themselves, instead relying on people they presume to be experts. But even if there are experts in Middle Eastern history, say, who are fervent Christians, or experts in classical Arabic who are devout Muslims, there are people who are equally expert in those subjects who believe in other religions, or in no religion. Furthermore, an expert in Middle Eastern history may be quite ignorant of another area in which the evidence demonstrates that their beliefs are false, and no one can be an expert in every field touching upon their religious beliefs.

When religious believers defer to supposed authorities as their reason for believing that their religion is true, they’re essentially admitting that they do not consider themselves qualified to judge the evidence and arguments for themselves. But in that case, they would also be unqualified to judge whether the evidence is actually incompatible with their beliefs or whether the arguments allegedly supporting their beliefs are wrong. When religious believers cite an authority whose arguments they do not themselves understand as the justification for their beliefs, the discussion is basically at an impasse. For example, there are what I think are serious problems or errors in the arguments for monotheism made by Ghazālī and Plantinga. If I’m right and their arguments are wrong, then citing these authorities has done nothing to convince me. However, if I’m wrong and their arguments are right, then I’m simply incapable of seeing how they could be right, and thus I am not convinced by their arguments in that case either.

This is the reason that the geographic and temporal aspects of the evidence that religion is a human invention are so powerful. It is so easy to explain to anyone: just plot the spread of the world’s religions on a series of maps corresponding to successive instances in time. When you do so, it can be clearly seen by anyone that religious beliefs and ideas are spread by human migration, conquest, and contact. You do not have to be an expert to immediately notice that there are no instances of “misplaced jinn”, that is, reports of human interactions with supernatural beings in a place and time where humans did not already believe that such beings exist. The simplest and best explanation for this readily observable fact is that supernatural beings such as gods, or angels, or demons, or jinn, do not exist outside of the human imagination.

This is not to say that the phenomena which they were concocted to explain do not exist, such as people hearing voices, seeing strange lights, feeling a presence that is not visible, getting spontaneously cured of diseases, becoming inexplicably ill, and so on. In fact, given that these phenomena do exist and need explaining, it is easy to see how people all over the world came up with the idea of supernatural beings, or witchcraft. And, for a person who is surrounded only by those who share the same view of the supernatural world (which would be most people in history), the explanation is good enough. The problem only arises when you begin to compare what different religions teach about the supernatural world, and examine how the descriptions of the supernatural world coming from a particular time and place just happen to correspond exactly with the religious composition and dispositions of the people living there. This is something that only a few scholars would have had the privilege to even be in a position to notice in a hundred years ago, but with the spread of libraries and the Internet, it is something that many people now can see for themselves.

(Continued in part 20 here.)

– davinci

Related posts:

1. The geographic and temporal spread argument, part 16
2. The geographic and temporal spread argument, part 7
3. The geographic and temporal spread argument, part 18

This exercise, like the previous one on combinations of a string, is from the book Programming Interviews Exposed by John Mongan and Noah Suojanen^[1]\(\).

For a string of length \(n\), there are \(n! = n \times (n-1) \times (n-2) \times \cdots \times 1\) permutations. It’s fairly easy to see how these arise. A permutation may begin with any of the \(n\) characters. Having fixed this first character, the second one may be chosen from the remaining \((n – 1)\) characters. And so on.

The recursive structure of the problem is then obvious. To compute the permutations of a string of \(n\) characters, first cycle through the characters in the string. For each character, remove it from the string, compute the permutations of the remaining \((n – 1)\) characters, and then prepend the previously removed character to each of the resulting permutations. The base case is the empty string, whose only permutation is itself.

The problem stipulates that each occurrence of a repeated character is to be treated as a distinct character. Consider the input string “aba”. When dealing with the first “a”, the program should remove it, compute the permutations of “ba” (which are “ba” and “ab”), and then prepend “a” to those permutations (resulting in “aba” and “aab”). However, when dealing with the second occurrence of “a”, the program should remove that “a”, and compute the permutations of the remaining string, “ab”. This seems to cause some difficulty, as it will mean that our program has to distinguish between the removal of the first “a” and the removal of the second “a”. Note, however, that the permutations of “ab” are the same as the permutations of “ba” (though they might be output in a different order). A little thought shows that any time we need to remove a character, we can always just remove its first occurrence, since the permutations of the resulting characters will be the same regardless of which occurrence we remove.

To begin with, we need a function to remove the first occurrence of an item from a list. This is basically an exercise from “Scheme 101″:

1
2
3
4
5
6

(define (remove-once the-item the-list)
    (cond ((null? the-list) '())
          ((equal? the-item (car the-list)) (cdr the-list))
          (else (cons (car the-list) (remove-once the-item (cdr the-list))))
    )
)

The heart of our solution will be a function called permute. Given an empty set, it returns a set containing only the empty set. Otherwise, it calls itself recursively. The outline looks like this:

(define (permute the-list)
    (if (null? the-list) '(())
        (...)
    )
)

What goes into the (...) above? We can build this up from the inside out. We know that there is a recursive call to permute, but with the selected character removed (ignoring for the moment how we select this character):

(permute (remove-once the-selected the-list))

The selected character should be prepended to each of the resulting permutations:

(map (lambda (the-rest) (cons the-selected the-rest))
    (permute (remove-once the-selected the-list)))

Each of the characters should become the selected character in turn:

(map (lambda (the-selected) 
    (map (lambda (the-rest) (cons the-selected the-rest))
        (permute (remove-once the-selected the-list)))) 
                 the-list)

Running the above code on the input '(a b c d e) will result in something like '( (a-perms) (b-perms) (c-perms) (d-perms) (e-perms) ), where x-perms are permutations beginning with the letter x. This list of lists of permutations should be flattened by applying append. The rest of the program in Scheme is then:

8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

(define (permute the-list)
    (if (null? the-list) '(())
        (apply append
            (map (lambda (the-selected) 
                         (map (lambda (the-rest) (cons the-selected the-rest))
                              (permute (remove-once the-selected the-list)))) 
                 the-list)
        )
    )
)
 
(define (permutations the-string)
    (map (lambda (s) (apply string s))
        (permute (string->list the-string)))
)
 
(define test-input "abcde")
(display (permutations test-input))

Because we need to output \(n!\) permutations (note that the factorial grows faster than the exponential function), it’s probably a good idea in most cases not to keep the permutations in memory, but rather to print them out as they are generated.

The following Python program uses logic similar to the above Scheme program, but prints out each permutation right away. The only difference in the logic is that, because the Python program uses strings and indices into strings, it distinguishes between each occurrence of a repeated character:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

def print_permutations(input_string):
 
    def print_permutations_helper(set_of_chars, output_string):
        if set_of_chars == "":
            print output_string,
        else:
            for index, char in enumerate(set_of_chars):
                print_permutations_helper(
                    set_of_chars[:index]+set_of_chars[index+1:], 
                    output_string + char)
 
    print_permutations_helper(input_string, "")
 
test_input = "abcde"
print_permutations(test_input)

One can manipulate sets, lists, or strings in C++ using STL classes, but it’s probably much faster to just use a boolean array to keep track of which letters have been “removed” from use. The following C++ program produces the same output as the above Python program:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

#include<iostream>
#include<string.h>
using namespace std;
 
void print_permutations_helper(char *input, char *output, bool *used,
    int len, int depth)
{
    // At the current depth, cycle through all the letters.
    for( int i = 0; i < len; i++ ) {
 
        // If the letter hasn't been used yet, use it.
        if( !used[i] ) {
            output[depth] = input[i];
 
            if( depth == len - 1 ) {
                cout << output << " ";
            } else {
                used[i] = true;
                print_permutations_helper(input, output, used, len, depth+1);
                used[i] = false;
            }
        }
    }
}
 
void print_permutations(char *input) 
{
    // Allocate a new character buffer to hold the output, and also
    // an array of flags for keeping track of which letters have
    // already been used.  (Assume that this always succeeds, or
    // that error handling is taken care of elsewhere.)
    int len = strlen(input);
    char *output = new char[len+1];
    output[len] = '\ 0';
    bool *used = new bool[len+1];
 
    // Initialise all the letters as unused.
    for( int i = 0; i < len; i++ ) {
        used[i] = false;
    }
 
    // Recursively print the permutations. 
    print_permutations_helper(input, output, used, len, 0);
    cout << endl;
 
    // Free the memory.    
    delete output;
    delete used;
}
 
int main()
{
    char test_input[] = "abcde";
    print_permutations(test_input);
}

As with the previous exercise on combinations of a string, this exercise also demonstrates how the typical approach to solving a problem will differ depending on whether Scheme or C++ (or some other language) is used. One can postulate a version of the Sapir-Whorf hypothesis for programming languages, that the language used to tackle a problem has an effect on the way in which it is solved.

– davinci 11804

Related posts:

1. Programming exercise: combinations of a string
2. Programming exercise: Hello, world!
3. Programming exercise: maximum value in integer array, part 1

Like the previous exercise, this one is also from the book Programming Interviews Exposed by John Mongan and Noah Suojanen^[1]\(\).

To begin with, let’s consider an example. What are the combinations of the string “abcde”? Since the ordering of the letters within the combinations don’t matter, let’s keep the letters in the same order as in the original string. Also, for now, let’s include the empty string as one of the combinations, for simplicity. Then it’s clear that there are \(2^{5} = 32\) combinations, since each of the \(5\) letters can be either included or excluded. (For an input string of length \(n\), there will be \(2^{n}\) combinations, including the empty string.)

The letter “a” will be included in half of the combinations, and excluded in the other half. (Of course, this is also true of each of the other letters.) In fact, those combinations that exclude “a” are just the combinations of the string “bcde”, and those that include “a” are exactly these same combinations, but prefixed with “a”. This gives an obvious recursive solution to the problem.

Expressed in Scheme, the program looks like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

(define (power-set the-set)
    (if (null? the-set) '(())
        (let ( (power-set-of-subset (power-set (cdr the-set))) 
               (prepend-excluded (lambda (subset) (cons (car the-set) subset))) )
             (append
                power-set-of-subset
                (map prepend-excluded power-set-of-subset) 
             ) 
        )
    )
)
 
(define (combinations the-string)
    (map (lambda (s) (apply string s)) 
         (cdr (power-set (string->list the-string))) )
)
 
(define test-input "abcde")
(display (combinations test-input))

The combinations function just converts the input string to a list of letters, applies power-set to the list, and converts the result back into a list of strings. (The empty set is excluded by applying cdr, since it is the first item in the list returned by power-set by design.)

The power-set function is pretty straightforward. It computes the power set of the subset that excludes the first letter (with a recursive call), then returns a set consisting of the elements of this power set along with these elements prepended with the excluded letter. The base case is slightly tricky: the power set of the empty set is not the empty set, but a set containing only the empty set.

(Aside: I wish that the higher-order functions map and fold/reduce had better names — especially “map”, a word that is used for just too many things.)

The same program can be written in Python as follows:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

def combinations(input_string):
 
    def combinations_helper(set_of_chars):
        if set_of_chars == "":
            return [""]
        else:
            combinations_of_subset = combinations_helper(set_of_chars[1:])
            combinations_of_subset.extend(
                map( lambda t: set_of_chars[0] + t, combinations_of_subset)
            )
        return combinations_of_subset
 
    return combinations_helper(input_string)[1:]
 
test_input = "abcde"
print combinations(test_input)

The Python program uses string manipulation operations (string slicing, concatenation) instead of treating the input as a list as the Scheme program does. The idea, however, is exactly the same.

There are probably more efficient ways to write these programs in these languages. In particular, the conversions between strings and lists (in Scheme) and the string manipulation operations (in Python) may be expensive.

What I like about the idea behind the above programs is that the result of the computation for the combinations excluding a character are re-used when computing the combinations including it. This saves on a lot of recursive calls.

The “obvious” solution to the same problem in C++ is the following:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

#include<iostream>
#include<string.h>
using namespace std;
 
void print_combinations_helper(char *input, char *output, 
    int len, int depth, int start)
{
    // The variable depth holds the recursion depth, or, equivalently, 
    // the index into the output string of the character that's being
    // generated.  The variable start is the index of the first of
    // the still available letters.
 
    // At the current depth, cycle through the still available letters.
    for( int i = start; i < len; i++ ) {
        output[depth] = input[i];
        print_combinations_helper(input, output, len, depth+1, i+1);
    }
    output[depth] = '\ 0';
    cout << output << endl;
}
 
void print_combinations(char *input) 
{
    // Allocate a new character buffer to hold the output.  (Assume 
    // that this always succeeds, or that error handling is being
    // taken care of elsewhere.)
    int len = strlen(input);
    char *output = new char[len+1];
 
    // Recursively print the combinations, starting with the first
    // character.
    print_combinations_helper(input, output, len, 0, 0);
 
    // Free the memory for the output buffer.
    delete output;
}
 
int main() 
{
    char test_input[] = "abcde";
    print_combinations(test_input);
}

The above program actually also prints out the empty string as one of the combinations, but this can be easily fixed by an if clause, or by relocating the cout statement (lines 18–19) inside the loop (at line 16, and substituting depth+1 for depth). The reason that I didn’t write the program that way is because then the combinations would have been output in a very different order compared to the above Scheme/Python programs. (The way it’s written now, the output is actually in exactly the reverse order, but that’s good enough for comparison purposes.)

While the recursive function is called only \(n+1\) times in the Scheme/Python programs (once for each character and once more for the empty set), the C++ program makes a total of \(2^{n}\) calls to the recursive helper function. On the other hand, while the Scheme/Python programs have to keep \(2^{n}\) items in memory (each of which is \(O(n)\) in size), the C++ program prints each combination as soon as it has been computed and thus uses only \(O(n)\) memory.

Personally, I prefer the solution used in the Scheme program because I find it conceptually much more elegant. It would also be preferably if recursive function calls are expensive for some reason. However, the solution used in the C++ program is better if memory is limited, or if the combinations do not need to be retained in memory after they have been printed.

Of course, one can write the first program in C++ or the second one in Scheme, but the point is that the two solutions are, in some sense, the more “natural” ones for their respective languages.

– davinci 11803

Related posts:

1. Programming exercise: permutations of a string
2. Programming exercise: Hello, world!
3. Programming exercise: maximum value in integer array, part 1