# Distinguish English and Spanish with regular expressions

The task is to to compete for the shortest regex (in bytes) in your preferred programming language which can distinguish between English and Spanish with minimum 60% 90% accuracy.

Silvio Mayolo's submission (pinned as Best Answer) has secured his spot as the winner of original contest against any chance of being contested. In order to provide room for further submissions, he has generously allowed the scoring requirement to be pushed to 90% accuracy.

# Links to wordlists have been replaced due to concerns voiced in the comments.

The following word lists (based on these) must be used: English, Spanish

The Spanish wordlist is already transliterated into ASCII, and there is no word present in either which is also present in the other.

A naive approach to distinguishing Spanish from English might be to match if the word ends in a vowel:

# [aeiou]$i9 bytes Here's a live example, where 6 of 8 words are successfully identified, for 75% accuracy: const regex = /[aeiou]$/i;

const words = [
'hello',
'hola',
'world',
'mundo',
'foo',
'tonto',
'bar',
'barra'
];

words.forEach(word => {
const match = word.match(regex);
const langs = ['English', 'Spanish'];
const lang = langs[+!!match];
console.log(word, lang);
});

• Thanks, I like these changes. Could you please also make a link an ASCII-transliterated Spanish word list? I'm not clear though on how our accuracy is judged. Are we given a word from one of the two word lists (20,000 words total) and our regex judges if it's English of Spanish, with us choosing which one is "match" and "not match"? What about if the string happens to appears in both lists?
– xnor
Jul 22 '20 at 23:04
• My experience with length-accuracy trade-off scoring formulas is that they're almost always turn out unbalanced or exploitable by answers caring for pretty much just about the one or the other. Moreover, dividing by byte count is usually a bad idea that rewards ultra-short answers when the other factor has a cap. I'd suggest just putting a higher required goal accuracy.
– xnor
Jul 23 '20 at 2:22
• Regarding the Sandbox, it's good that you posted there first, but one day is too little time to gather feedback. Three days minimum is usually recommended by default, but with this being not a bog-standard code golf but a challenge with a test battery, I'd suggest a week or two at least.
– xnor
Jul 23 '20 at 2:24
• That metric may not quite be enough. A 2-byte answer can beat my answer if it has accuracy of 84% or above (which may be possible with 2 bytes, but I'm not hopeful). A 3-byte or more answer, even with 100% accuracy, can only get a 0.33 score, at most. I like this challenge, but I'm not sure what the right metric for it is, to be honest. Jul 23 '20 at 2:24
• I’m voting to close this question because "This contest is frozen until a reasonable scoring system can be decided on." Jul 23 '20 at 2:52

# Any Language, 0.3677 (60.6064%, 1 byte)

a


No, I'm not joking. The single-character regular expression a successfully identifies Spanish words over English given your input files 60.6064% of the time, which makes it a valid submission.

Here's a complete, runnable Perl script that checks the percentage of this regular expression, assuming you've downloaded english.json and spanish.json into the same folder as the script.

#!/usr/bin/perl

use strict;
use warnings;
use 5.010;

my @english;
my @spanish;

my $fh; open$fh, '<', 'english.json';
while (<$fh>) { push @english,$1 if /"(\w+)"/;
}
close $fh; open$fh, '<', 'spanish.json';
while (<$fh>) { push @spanish,$1 if /"(\w+)"/;
}
close $fh; my$correct = 0;
my $total = 0; my$re = qr/a/;

for (@english) {
$total++;$correct++ unless /$re/; } for (@spanish) {$total++;
$correct++ if /$re/;
}

say "$correct /$total (@{[100*$correct/$total]}%)";

• Good job! That's fascinating that just having the letter a makes a word significantly more likely to be Spanish as opposed to English. Also, maybe I should have consulted a linguist to review the OP before submission :P Jul 23 '20 at 1:31
• Well, can't imagine anybody's going to beat that... Jul 23 '20 at 1:31
• Also amazing how it just barely qualified by 0.6% percentage points. Jul 23 '20 at 1:33
• It's also the only letter that satisfies the criteria. The next best would be o, with 58.69%, then it drops way down to 54.08% with t. On the flipside, n occurs most uniformly, at 50.13% accuracy. Jul 23 '20 at 1:40
• I wrote a script to analyze common character sequences in the two files, in the hopes of finding a 3- or 4-character constant regex that would do it. Sure enough, my script came back with a, which made me chuckle. Jul 23 '20 at 1:53

# 50 bytes, 90.02% accurate

(a(d?|is|r|se?)|dor|eis|ese|je|n|[ns]te|os?|res?)\$

For 18,004 out of the 20,000 words in es_clean.json and en_clean.json, this regex matches iff the input word is Spanish.