7
\$\begingroup\$

Real-world programs often use libraries like ICU to support Unicode.

The puzzle is to create the smallest possible function that can determine whether a given Unicode character is lowercase, uppercase, or neither (a commonly used Unicode character property).

You may indicate the property in any way (whatever is shortest for your language); just explain what the output means in your answer.

Of course, using a language feature or a function from the standard library that already provides this distinction is forbidden.

This could potentially have some practical use, since some embedded programs have to choose between including a bulky library and not supporting Unicode.

\$\endgroup\$
8
  • 3
    \$\begingroup\$ Character classification changes (albeit in a stable manner) with each release of Unicode. Are you asking for a function that is hard coded to a particular version of Unicode? If so, then this is nothing more than an exercise in data compression, and one where I could choose the release to my advantage. As specified, the problem isn't actually practical, as your classification options are not a useful subset of the Unicode classifications, even for simple text processing. (There are many letters that are neither lowercase or uppercase, for example.) \$\endgroup\$ – MtnViewMark Jul 14 '11 at 1:55
  • 1
    \$\begingroup\$ Also, where can the database of character classifications be found? \$\endgroup\$ – Joey Adams Jul 14 '11 at 6:31
  • 2
    \$\begingroup\$ @Joey (and his upvoter): unicode.org/Public/UNIDATA/UnicodeData.txt – the usual place, basically. \$\endgroup\$ – Joey Jul 14 '11 at 8:01
  • 1
    \$\begingroup\$ MtnViewMark: Character classes are final for already-encoded characters, so nothing changes there, except characters are added. Also, how many uper- and lowercase characters have been added recently, especially in the BMP? I currently can only think of uppercase sharp s and the math alphabets (which are in the SMP, anyway). Agreed that it's only data compression, but for reasonably current versions of Unicode the number of upper- and lowercase characters is fairly stable. \$\endgroup\$ – Joey Jul 14 '11 at 8:37
  • 1
    \$\begingroup\$ Voting to close as unclear. Challenges should be self-contained, so the list or qualifications for each output should be made clear. If linked as an external file, the file should be a file that will not change over time. \$\endgroup\$ – mbomb007 Apr 16 '18 at 21:00
6
\$\begingroup\$

C & C++, 1922 1216 bytes/chars (BMP only 1451 1005 bytes/chars)

This is the "shortest" solution that came to mind that is both valid C and C++ and that supports all of Unicode version 6.1, not just the BMP:

int s[]={-74,-68,31054,-50,-49,-48,-47,-46,-44,-43,-39,-38,-37,-34,-33,-32,-30,-29,-28,-27,-26,-25,-24,-23,-22,-17,-16,-13,-12,-11,-10,-9,-8,-7,-6,-5,-4,-3,-2,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,16,19,20,27,28,29,53195,31,34,36,42,49,50,52,54,58,59,62,64,66,73,81,98,102,103,140,194,263,275,290,1066,1222,1230,2685,2732,2890,3379,6009,21254,22391,30996,53209};
char l[]="l5Hf`7HIAH2IH@IH7IJFIFHJIJKHLJKFHFJFIJIHIJKIJHJFHNFJ@IH?IHJIK1IBHFJHILDI!HI4HpIFKFHWZ-HIHKFH<IDHIFJHc&H9IQ4IJBIH(Ie+H{)Hh<HI.Hn I@H$I@HPCHRAHPAHPCHRAHPAHP;HJAHPAHPAHPDHIHNKFHIHPEHJHPAHRFHIHrKHKZFLJHPEHLdx'HJKHEILIHICHM$IHOILT,HIM~8IX=IoBIFH/IAHFIJDILIJIUDIk|BHTDHt5Hv*H\\5HYBHI9HY5HYEHFIBHI>HY5HY5HY5HY5HY5HY5HY5HY5HY3H[6HICHY6HICHY6HICHY6HICHY6HICHIG";
char u[]="i5Hm8HIBH^3IJAIJ7IHFIKHFIHIFHJEHIHIFHKHIHEIHIJIHIFHFIHKOEJAIJ@IFJIFH1IOHIHJIEHDIsIKVIFHFIHI:HI@H_JFHK=IMJIHJ#Ha:IQ3IHBIJ)IR,Hy,HIMz IQ%IQAHPCHRAHPAHPCHSEIPAHjEHTEHTEHTDHSEHqLKFHJFHJKDHNEIEHJEHRHMgw'HbIFHJEIEHIJPFH$IPIL\"8IX=IoBIK0IRFIHDILIJIUCI}5Hu*H\1775HY5HY5HYIHFJHJEHIAHY5HYHIEHJAHIBHZHIEHIDHIKBHZ5HY5HY5HY5HY5HY5H]6H^6H^6H^6H^6H^G";
int x(int a,char*p){int c=0,i=0,b=-1;while(c>0||s[*p-32]){if(!c)c=s[*p-32]<0?-s[*p++-32]:1,i=s[*p++-32];b+=i,--c;if(a==b)return 1;}return 0;}

Please note that "shortest" in this case does not mean that the solution is in any way efficient; it simply means that it is the shortest source code solution. It does not require any Unicode support in the standard library, and in fact does not use the standard library at all. (Which I now understand is what code golf means ... I'm a newbie around here, what can I say.)

To build the lower and upper case data tables I worked as follows:

  1. Downloaded UnicodeData.txt.
  2. Extracted a list of all lines that included the text ";Ll;" or ";Lu;" to indicate a lower case letter or upper case letter respectively.
  3. Built two vectors of code points using the data from step 2.
  4. Converted each absolute code point value to a relative value, the difference between the previous code point and this code point. Because it is convenient for the difference to always be a positive integer (not zero or negative), I use -1 as the value of the first previous code point. In this way zero will not appear anywhere in the sequence.
  5. Used a form of run length encoding to compress runs of identical values into a pair of values. If the next value appears two or more times consecutively, replace the sequence with the negative of the length of the sequence and the value. Otherwise the value only appears once, so just use it as is.
  6. Terminated the compressed vector with zero to mark the end of the sequence.
  7. I noticed there were 96 unique values in the run length encoded vectors, so I built an array of the unique integers and used the index into that array for the lower and upper case vectors.

The above process compressed the vector of lower case code points from 1751 unique values to 350 mostly small non-unique values. In like fashion, the upper case code point vector went from 1441 values to 331 values.

Next I wrote the unique value vector out as a comma separated list of integers suitable for including in source code. I assumed int was 32 bits to avoid using long so that I could save an additional four characters / bytes of source code. Then I wrote out the lower and upper case vectors as strings, where each character in the string has a code 32 greater than its index into the unique integer array. This saves about half the characters necessary to encode the lower & upper case array through omission of comma characters. Three of the characters used have to be escaped (\", \, and \177). They are assigned to unique integers that only appear once in the data so as to minimize the size of the string literals.

What I wound up with was a global array of integers, two global arrays of characters, and a function. An array named s for the unique signed integers, an array named u for the character based upper case code point indexes, and another array named l for the character based lower case code point indexes. The function x takes code point a and pointer to an array of characters p and returns 1 if the code point is in the decompressed / normalized array of code points or 0 otherwise.

If you want to determine if code point cp is lower case, you call "x(cp, l)". If you want to determine if it is upper case, you call "x(cp, u)".

Since the point to this exercise is to make the smallest code to accomplish the task, I never save the decompressed / normalized data. I decompress it piecemeal as I need it every time I call it.

It would be possible to terminate the while loop early if the code point I'm checking has already been passed by during decompression. That would add extra code so I didn't bother, deciding I'd rather pay the speed penalty.

I admit the code is ugly. I did not write it this way originally. Here is the C++ version that I derived the compact C version from:

const int Ii[] = {-74,-68,31054,-50,-49,-48,-47,-46,-44,-43,-39,-38,-37,-34,-33,-32,-30,-29,-28,-27,-26,-25,-24,-23,-22,-17,-16,-13,-12,-11,-10,-9,-8,-7,-6,-5,-4,-3,-2,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,16,19,20,27,28,29,53195,31,34,36,42,49,50,52,54,58,59,62,64,66,73,81,98,102,103,140,194,263,275,290,1066,1222,1230,2685,2732,2890,3379,6009,21254,22391,30996,53209};
const char Ll[] = "l5Hf`7HIAH2IH@IH7IJFIFHJIJKHLJKFHFJFIJIHIJKIJHJFHNFJ@IH?IHJIK1IBHFJHILDI!HI4HpIFKFHWZ-HIHKFH<IDHIFJHc&H9IQ4IJBIH(Ie+H{)Hh<HI.Hn I@H$I@HPCHRAHPAHPCHRAHPAHP;HJAHPAHPAHPDHIHNKFHIHPEHJHPAHRFHIHrKHKZFLJHPEHLdx'HJKHEILIHICHM$IHOILT,HIM~8IX=IoBIFH/IAHFIJDILIJIUDIk|BHTDHt5Hv*H\\5HYBHI9HY5HYEHFIBHI>HY5HY5HY5HY5HY5HY5HY5HY5HY3H[6HICHY6HICHY6HICHY6HICHY6HICHIG";
const char Lu[] = "i5Hm8HIBH^3IJAIJ7IHFIKHFIHIFHJEHIHIFHKHIHEIHIJIHIFHFIHKOEJAIJ@IFJIFH1IOHIHJIEHDIsIKVIFHFIHI:HI@H_JFHK=IMJIHJ#Ha:IQ3IHBIJ)IR,Hy,HIMz IQ%IQAHPCHRAHPAHPCHSEIPAHjEHTEHTEHTDHSEHqLKFHJFHJKDHNEIEHJEHRHMgw'HbIFHJEIEHIJPFH$IPIL\"8IX=IoBIK0IRFIHDILIJIUCI}5Hu*H\1775HY5HY5HYIHFJHJEHIAHY5HYHIEHJAHIBHZHIEHIDHIKBHZ5HY5HY5HY5HY5HY5H]6H^6H^6H^6H^6H^G";

bool isXx(int cp, const char* Xx)
{
    int count = 0, step = 0, code = -1;

    while ((count > 0) || (Ii[*Xx-32] != 0))
    {
        if (count == 0)
        {
            count = (Ii[*Xx-32] < 0) ? -(Ii[*(Xx++)-32]) : 1;
            step = Ii[*(Xx++)-32];
        }

        code += step;
        --count;

        if (cp < code)
            break;

        if (cp == code)
            return true;
    }

    return false;
}

inline bool isLl(int cp)
{
    return isXx(cp, Ll);
}

inline bool isLu(int cp)
{
    return isXx(cp, Lu);
}

In the end, the compact version takes 1922 1216 bytes (including CR+LF end of line sequences). The original version only takes 2271 1578 bytes.

To put this in context of the other solutions that only support the BMP, the equivalent compact version only takes 1451 1005 bytes (or 1800 1367 bytes for the original version).

\$\endgroup\$
4
  • \$\begingroup\$ I'm accepting this one even though it's a bit longer, because it supports astral-plane characters, does something clever, and explains how it was created. Also, it's probably possible to shorten the arrays by encoding them into character strings in some way. \$\endgroup\$ – Mechanical snail Sep 16 '12 at 21:54
  • \$\begingroup\$ Thanks. I considered encoding them in some other way, but the obvious solutions would have involved more code to decode, and I intuited that the overhead wouldn't make enough of a difference (though I didn't try so I could be wrong). \$\endgroup\$ – CasaDeRobison Sep 16 '12 at 22:05
  • \$\begingroup\$ @Mechanicalsnail So after a few hours of not thinking about it, I came up with a new encoding using character strings that involves little over head and shrinks the size of the compact solution from 1922 bytes/chars to 1216 bytes/chars. So two things: 1, you were correct, and 2, since I'm a relative newbie to the codegolf.stackexchange site, what's the best way to share it? Should I replace the original above, or append it to the end of this accepted answer, or post yet another answer? \$\endgroup\$ – CasaDeRobison Sep 17 '12 at 0:50
  • \$\begingroup\$ I would probably replace the existing answer. Also keep an old version when it contains something interesting or if they help understand how the solution works; if the new version is better in all respects then just delete the old one. I would add a second answer if my new solution is completely different (e.g. works by a different method, is written in a different language, etc.). \$\endgroup\$ – Mechanical snail Sep 17 '12 at 7:17
1
\$\begingroup\$

Python 3, 1369 chars (not bytes)

a='abcdefghijklmnopqrstuvwxyzªµºßàáâãäåæçèéêëìíîïðñòóôõöøùúûüýþÿāăąćĉċčďđēĕėęěĝğġģĥħĩīĭįıijĵķĸĺļľŀłńņňʼnŋōŏőœŕŗřśŝşšţťŧũūŭůűųŵŷźżžſƀƃƅƈƌƍƒƕƙƚƛƞơƣƥƨƪƫƭưƴƶƹƺƽƾƿdžljnjǎǐǒǔǖǘǚǜǝǟǡǣǥǧǩǫǭǯǰdzǵǹǻǽǿȁȃȅȇȉȋȍȏȑȓȕȗșțȝȟȡȣȥȧȩȫȭȯȱȳȴȵȶȷȸȹȼȿɀɂɇɉɋɍɏɐɑɒɓɔɕɖɗɘəɚɛɜɝɞɟɠɡɢɣɤɥɦɧɨɩɪɫɬɭɮɯɰɱɲɳɴɵɶɷɸɹɺɻɼɽɾɿʀʁʂʃʄʅʆʇʈʉʊʋʌʍʎʏʐʑʒʓʕʖʗʘʙʚʛʜʝʞʟʠʡʢʣʤʥʦʧʨʩʪʫʬʭʮʯͱͳͷͻͼͽΐάέήίΰαβγδεζηθικλμνξοπρςστυφχψωϊϋόύώϐϑϕϖϗϙϛϝϟϡϣϥϧϩϫϭϯϰϱϲϳϵϸϻϼабвгдежзийклмнопрстуфхцчшщъыьэюяѐёђѓєѕіїјљњћќѝўџѡѣѥѧѩѫѭѯѱѳѵѷѹѻѽѿҁҋҍҏґғҕҗҙқҝҟҡңҥҧҩҫҭүұҳҵҷҹһҽҿӂӄӆӈӊӌӎӏӑӓӕӗәӛӝӟӡӣӥӧөӫӭӯӱӳӵӷӹӻӽӿԁԃԅԇԉԋԍԏԑԓԕԗԙԛԝԟԡԣԥԧաբգդեզէըթժիլխծկհձղճմյնշոչպջռսվտրցւփքօֆևᴀᴁᴂᴃᴄᴅᴆᴇᴈᴉᴊᴋᴌᴍᴎᴏᴐᴑᴒᴓᴔᴕᴖᴗᴘᴙᴚᴛᴜᴝᴞᴟᴠᴡᴢᴣᴤᴥᴦᴧᴨᴩᴪᴫᵢᵣᵤᵥᵦᵧᵨᵩᵪᵫᵬᵭᵮᵯᵰᵱᵲᵳᵴᵵᵶᵷᵹᵺᵻᵼᵽᵾᵿᶀᶁᶂᶃᶄᶅᶆᶇᶈᶉᶊᶋᶌᶍᶎᶏᶐᶑᶒᶓᶔᶕᶖᶗᶘᶙᶚḁḃḅḇḉḋḍḏḑḓḕḗḙḛḝḟḡḣḥḧḩḫḭḯḱḳḵḷḹḻḽḿṁṃṅṇṉṋṍṏṑṓṕṗṙṛṝṟṡṣṥṧṩṫṭṯṱṳṵṷṹṻṽṿẁẃẅẇẉẋẍẏẑẓẕẖẗẘẙẚẛẜẝẟạảấầẩẫậắằẳẵặẹẻẽếềểễệỉịọỏốồổỗộớờởỡợụủứừửữựỳỵỷỹỻỽỿἀἁἂἃἄἅἆἇἐἑἒἓἔἕἠἡἢἣἤἥἦἧἰἱἲἳἴἵἶἷὀὁὂὃὄὅὐὑὒὓὔὕὖὗὠὡὢὣὤὥὦὧὰάὲέὴήὶίὸόὺύὼώᾀᾁᾂᾃᾄᾅᾆᾇᾐᾑᾒᾓᾔᾕᾖᾗᾠᾡᾢᾣᾤᾥᾦᾧᾰᾱᾲᾳᾴᾶᾷιῂῃῄῆῇῐῑῒΐῖῗῠῡῢΰῤῥῦῧῲῳῴῶῷℊℎℏℓℯℴℹℼℽⅆⅇⅈⅉⅎↄⰰⰱⰲⰳⰴⰵⰶⰷⰸⰹⰺⰻⰼⰽⰾⰿⱀⱁⱂⱃⱄⱅⱆⱇⱈⱉⱊⱋⱌⱍⱎⱏⱐⱑⱒⱓⱔⱕⱖⱗⱘⱙⱚⱛⱜⱝⱞⱡⱥⱦⱨⱪⱬⱱⱳⱴⱶⱷⱸⱹⱺⱻⱼⲁⲃⲅⲇⲉⲋⲍⲏⲑⲓⲕⲗⲙⲛⲝⲟⲡⲣⲥⲧⲩⲫⲭⲯⲱⲳⲵⲷⲹⲻⲽⲿⳁⳃⳅⳇⳉⳋⳍⳏⳑⳓⳕⳗⳙⳛⳝⳟⳡⳣⳤⳬⳮⴀⴁⴂⴃⴄⴅⴆⴇⴈⴉⴊⴋⴌⴍⴎⴏⴐⴑⴒⴓⴔⴕⴖⴗⴘⴙⴚⴛⴜⴝⴞⴟⴠⴡⴢⴣⴤⴥꙁꙃꙅꙇꙉꙋꙍꙏꙑꙓꙕꙗꙙꙛꙝꙟꙡꙣꙥꙧꙩꙫꙭꚁꚃꚅꚇꚉꚋꚍꚏꚑꚓꚕꚗꜣꜥꜧꜩꜫꜭꜯꜰꜱꜳꜵꜷꜹꜻꜽꜿꝁꝃꝅꝇꝉꝋꝍꝏꝑꝓꝕꝗꝙꝛꝝꝟꝡꝣꝥꝧꝩꝫꝭꝯꝱꝲꝳꝴꝵꝶꝷꝸꝺꝼꝿꞁꞃꞅꞇꞌꞎꞑꞡꞣꞥꞧꞩꟺfffiflffifflſtstﬓﬔﬕﬖﬗabcdefghijklmnopqrstuvwxyz'
def f(x):
 if x in a:
  return 'lowercase'
 if x in a.upper()+'ℂℇℋℍİℑℐℒℕℙℛℚℝℜẞℤΩℨÅKℭℬℱℰℳℿℾⅅℌϓϒϔϴ':
  return 'uppercase'
 return 'neither'

Almost as small as the other answer (uses the same approach but using literals instead of numbers) but no effort at all.

Your browser may not render the chars properly and it is UTF-8

Edit: Making uppercase characters and adding those which didn't correspond to any lowercase saved a ton of chars

\$\endgroup\$
3
  • \$\begingroup\$ Technically that's reusing embedded Unicode information, though, thus approximately on par with directly querying character information. \$\endgroup\$ – Joey Jul 14 '11 at 11:10
  • \$\begingroup\$ @Joye on many languages 'a' == 97. So what's the difference of comparing a char to a number or to another char? \$\endgroup\$ – JBernardo Jul 14 '11 at 11:28
  • 1
    \$\begingroup\$ I meant the upper() part which is relying on Python knowing how to uppercase arbitrary Unicode characters, thereby not embedding the mapping itself. \$\endgroup\$ – Joey Jul 14 '11 at 12:31
1
\$\begingroup\$

PowerShell, 2101

filter x{if(97..122+170,181,186+223..246+248..255+311..312+(0..26|%{$_*2+257})+
328..329+(0..6|%{$_*2+314})+(0..22|%{$_*2+331})+382..384+378,380,387,389+
396..397+392,402+409..411+405,414,417,419,421,426,427,424,429,432,441,442+
445..447+436,438,454,457,476,477+(0..7|%{$_*2+460})+495,496+(0..7|%{$_*2+479})+
499,501+563..569+(0..28|%{$_*2+505})+575,576,572,578+591..659+661..687+
891..893+(0..3|%{$_*2+583})+940..974+976,977,912+981..983+1007..1011+
(0..10|%{$_*2+985})+1013,1016,1019,1020+1072..1119+(0..16|%{$_*2+1121})+
(0..26|%{$_*2+1163})+1230,1231+(0..5|%{$_*2+1218})+1377..1415+7424..7467+
7522..7578+(0..33|%{$_*2+1233})+7829..7835+(0..73|%{$_*2+7681})+7936..7943+
7952..7957+7968..7975+7984..7991+8000..8005+8016..8023+8032..8039+
8048..8061+8064..8071+8080..8087+8096..8103+8112..8116+8118,8119+
(0..44|%{$_*2+7841})+8130..8135+8144..8147+8150..8151+8160..8167+8178..8180+
8182,8183,8126,8305,8319+8462..8463+8458,8467,8495,8500,8508,8509+8518..8521+
8505,8526,8580+11312..11358+11365,11366,11361,11368,11370,11372,11382,11383,
11380+11491,11492+11520..11557+64256..64262+64275..64279+65345..65370+
(0..48|%{$_*2+11393})-ne7544-ne8133-eq$_){1}elseif(65..90+192..214+216..222+
(0..27|%{$_*2+256})+(0..7|%{$_*2+313})+376,377+(0..22|%{$_*2+330})+385..386+
379,381+390..395+398..408+412..416+388,422,423,418,420,425,428+430..435+439,
440,437,444,452,455,458,497,500+(0..7|%{$_*2+461})+(0..8|%{$_*2+478})+
502..504+570..574+(0..28|%{$_*2+506})+579..582+577,584,586,588,590,902,908+
904..906+910..939+978..980+(0..11|%{$_*2+984})+1012,1015,1017,1018+1021..1071+
(0..16|%{$_*2+1120})+1216,1217+(0..26|%{$_*2+1162})+(0..5|%{$_*2+1219})+
1329..1366+4256..4293+(0..33|%{$_*2+1232})+(0..74|%{$_*2+7680})+7944..7951+
7960..7965+7976..7983+7992..7999+8008..8013+(0..44|%{$_*2+7840})+8040..8047+
8120..8123+8136..8139+8152..8155+8168..8172+8184..8187+(0..3|%{$_*2+8025})+
8450,8455,8469+8459..8461+8464..8466+8473..8477+8490..8493+8496..8499+8510,
8511,8484,8486,8488,8517+11264..11310+8579,11360+11362..11364+11367,11369,
11371,11381+65313..65338+(0..49|%{$_*2+11392})-notmatch'^(392|40[25]|414|432|572|912|930)$'-eq$_){2}else{0}}

Notes:

  • Returns 1 for lower-case, 2 for upper-case and 0 for neither.
  • Works only for BMP code points (as the char type in .NET represents a single UTF-16 code unit).

This uses a few distinct ways of compressing the code points for the two sets:

  • adjacent code points are conflated in a range (97..122)
  • code points that are two apart are conflated in a small pipeline (0..22|%{$_*2+331})
  • Ranges with only one missing value are done via 7522..7578-ne7544, effectively removing that single element. This may not be done with all such rages by now.

I did the first two steps automatically, the third one and minor optimizations (0..1|%{2*$_+11370} is useless) were done by hand.

Some tests:

PS> [char]'a'|x
1
PS> [char]'A'|x
2
PS> [char]'1'|x
0
PS> [char]'α'|x
1
PS> [char]'Д'|x
2
\$\endgroup\$
1
\$\begingroup\$

Python 2: 811 characters (after minification)

def D(s):
    k = 0
    for i in map(ord, s.decode('base64').decode('utf8')):
        for j in range(i // 2):
            yield k
            k ^= i % 2
        k ^= 1 - i % 2
U = list(D('woI0w4ouAw5CbwQfBF0ECQYEBwQDBgQIAwQDBgYEAwQLBAUEBQQDBgcEBgMOAwQDBAMEHwQjBAMEBQZ1DgQDBAQFCBHJggcGAx4FBgcEAyIDEkYDBAYGLwoDBAUEBGZgQxJtBBkEwqccTOGakkzhqbTEqxLDgxIQEAwUEBAQEAwWDxAQwpAIGAgYCBgKFgjIjAMIAwYGBAYEAwYKDA0IBAgUBAoDegPhk7heYgUGBA0GBAMEAxTDh++Kuj8GFyYvxJYbBnsUCQQRCAPqvKo0xoo='))
L = list(D('w4I0XgMUAwgDSDADEG8EHwRdBAkGBAcEAwYECAMEAwYGBAMECwQFBAUEAwYHBAQEBgwDBAMEIQQjBAQHBnUOBAMEBAUIEcKKAzbGggcGAwYGJAM2RgMEBgYvCgUEAwQEZmBFEmsEGQTCqXpO4ruwWGwsA0TDjMSpEsODEhAMFBAQEBAMFBAQEBAcBBAQEBAQEAoDBAwDBgYDBBAIBAQQEBQGAwTDsgMaA8SUAwYEBgM2AwgDCAMEBBAICANqA+GVll4EAwYEDQgFBAMOCMOFBDZM74i2PwYXJi/ElhkGfxAJBBMIA+qbpg4YCuChkjTFig=='))
f = lambda x: U[x] and 'upper' or L[x] and 'lower' or 'neither'

This supports the base multi-lingual plane only (as for the other answers). You could make it a bit shorter by omitting the encoding/decoding steps (and just putting Unicode strings into the program source), but then I think you really ought to count the length in bytes rather than characters.

\$\endgroup\$
6
  • 2
    \$\begingroup\$ Why do you only count non-whitespace characters? \$\endgroup\$ – Joey Jul 16 '11 at 16:27
  • 1
    \$\begingroup\$ Because removal of whitespace is essentially a mechanical operation. In most cases it just makes the code harder to read, without adding anything of value. When analyzing the code, of course the first thing you would do is to restore the whitespace to make it readable. So I prefer to take this step for granted, in order to focus on the more interesting and creative aspects of the challenge. \$\endgroup\$ – user2186 Jul 16 '11 at 16:54
  • \$\begingroup\$ So there is no necessary whitespace in there. Plenty of languages have that and then not counting characters you need for the program to work is a bit cheating. \$\endgroup\$ – Joey Jul 16 '11 at 16:59
  • \$\begingroup\$ Would it be better if I gave the length after minification instead, like this? \$\endgroup\$ – user2186 Jul 16 '11 at 17:12
  • \$\begingroup\$ That's better, I guess. Usually rules like "Don't count whitespace" are given in the task specification here and when they're absent everyone should count the same. \$\endgroup\$ – Joey Jul 16 '11 at 17:14

Not the answer you're looking for? Browse other questions tagged or ask your own question.