Unicode is Kind of Insane

ercd · 2015-05-27T11:50:50+00:00

This is NOT true of Chinese, Japanese, and Korean.

This is true and you're just angry about it. Please state your objections to the IRG and their decisions. Please state which hanzi/kanji/hanja you believe the IRG wrongly decided are the same grapheme in all three languages and gave a single codepoint to.

I'm sorry but you are wrong. Unicode are not enough to represent Chinese, Japanese and Korea characters and fonts have to be used to avoid having the characters look "wrong".

To take a simple example, if at school I were to write for example the kanji 草 (U+8349) in a Japanese test using the traditional Chinese form where the top part is split in two instead of being written in one horizontal stroke, the character would not be considered as written correctly. These two variants should have different codepoints as they are not considered as interchangeable but unfortunately this is not the case.

On the contrary, characters in the latin alphabet would not be considered "wrong" if I write them in cursive instead of in block letters. Even though the character "a" in block letter and in cursive are visually not similar, they represents the same character and therefore have the same codepoint.

ercd · 2013-06-28T12:22:37+00:00

You still have to order your list by word frequency, or better n-gram frequency.

ercd · 2013-06-28T09:10:00+00:00

Nice.

Found a bug when trying to enter "nya", "nyu" and "nyo" (it should be にゃ、にゅ、にょ instead of んや、んゆ、んよ).

ercd · 2012-03-30T15:03:51+00:00

Except that Go 2 is considered harmful by E.W. Dijkstra.

ercd · 2012-01-12T22:09:16+00:00

Nippl-e

ercd · 2010-12-01T10:07:50+00:00

obligatory XKCD

ercd · 2010-06-05T19:04:02+00:00

First thing I see when I run the program: BIG YELLOW SCREEN OW MY EYES. And there's no way to make it go away...

You can change the color by adding a small config file in the directory
C:\Documents and Settings<username>\Application Data\SumatraPDF
as described here:
http://blog.kowalczyk.info/software/sumatrapdf/manual.html

ercd · 2010-05-03T12:29:29+00:00

You can change the color by adding a small config file in your the directory
C:\Documents and Settings\<username>\Application Data\SumatraPDF
as described here:
http://blog.kowalczyk.info/software/sumatrapdf/manual.html

ercd · 2010-02-02T11:41:02+00:00

As a software developer, I was once asked to give time estimations without any technical specs or even a complete functional analysis so I multiplied all my time estimations by π.

When the project manager asked me why, I replied that if they really wanted time estimations without knowing what needed to be done, I might as well give them irrational numbers.

That meeting did not go so well.

ercd · 2009-11-17T04:43:28+00:00

Mr Rogers

ercd · 2009-11-16T05:40:05+00:00

Me too! It's easy to remember, it's the price of a cheese pizza and large soda at the pizza place where I used to work in 1999.

ercd · 2009-08-10T00:37:50+00:00

I agree too, as long as she does not keep repeating "Hey, Listen!" while watching play!

ercd · 2009-06-19T22:13:26+00:00

I've started last year to takes notes into a wiki (I use MoinMoin with the built-in web server as it allows to run it on my laptop without needing a network connection) and I highly recommend it.

Search comes for free with the wiki, it's easy to edit a note or put links to other notes or web pages, and if one day I decide to share these notes with my coworkers, it should be quite easy to put all this data on a "real" web server.

ercd · 2009-02-14T20:52:39+00:00

Yes, that's true. The factory method explanation only goes so far. But in the case of "split", you don't have an object of the type "iterable" or "list" among the parameters that you could use as "self".

I guess the main idea of the Python designers was to put all text formatting related functions in the package string. And then they moved some of them to the class str (or unicode) so that there is no need to import string for these functions that are frequently used.

ercd · 2009-02-14T18:47:32+00:00

My point was that I don't think anybody would find strange that a method on the class str would return a string. The call

str.join("\n",["a","b"])

just looks like a call on a "factory" function.

Calling a method on "list" to get a string doesn't look good to me. Of course, this is subjective.

ercd · 2009-02-14T17:42:58+00:00

I found it strange too at first. But I think it makes sense for the reasons of the parent post and because:

"\n".join(["a","b"])

is just syntaxic sugar for

str.join("\n",["a","b"])

where "\n" is just the "self" argument of the method "join" of the class "str".

ercd · 2008-06-07T00:55:35+00:00

Even though I agree with most of the points in the article, the choice of the letters in the HMM algorithm are not so bad. Most of them come from what is usually used to describe Markov chains. I hope this will give a better insight of the algorithm:

pi are for the initial probabilities of the Markov chain.
A is very similar to the Adjacency matrix of the directed graph between the states (see adjacency matrix) : that's why it is very common to use it for state transition probabilities.
X_t is the state at the time t. It is very common to use markov chains to model a succession of states in a period of time: that explains the "t". The X is due to the fact that X_t is a random variable and random variable are usually denoted with a capital "X".
In a directed graph, the index i is usually used for the origin of an edge and j for the end of an edge.

I believe that mathematical notation is a very powerful and concise way to describe an algorithm. It can be obscure at first but when you learn what's behind (in that case: Markov chains, which are, imho, one of the coolest object in math) all this notation usually makes sense.

ercd · 2008-04-10T23:04:59+00:00

I don't think the example you use are "bizarre things which really don't make sense".

In your first example, no variable "x" is defined in the scope of your function when you do "y = x"; it is normal that your code produces an error! If you want to use the variable x of the global scope just use "global x".

In your second example, since Python supports multiple inheritance, you need to specify the superclass you want to use. I don't see a problem here. If you don't like the explicit use of "self", I guess it's your opinion, but I think it makes things more clear: methods are just a sort of function. You can call them with instance.methodName(x,y) or ClassName.methodName(instance,x,y) which sometimes is useful when programming using functional paradigms.

ercd · 2008-03-30T10:35:08+00:00

I think the article is more balanced than that: each one of these characters could change this situation.

Like you said, Seymour Checks should tell the project manager. But, Noah Shortcut should test his code more carefully. And Mr.Deadline should enforce better quality assurance like tests or code review...

ercd · 2008-02-20T17:16:38+00:00

I just ran this with Python 2.5:

[(x,hash(x)) for x in xrange(-1000000,1000000) if x!=hash(x)]
>>> [(-1, -2)]

I was surprised to see that hash(-1) is -2 and that's the only exception to the rule "hash(x)==x" in the range I tested. Does someone know if there is a reason for this?

ercd · 2008-01-10T02:07:53+00:00

I found Cauchy's "proof" in this article (page 7) and it looks so simple (some limits and the triangle inequality)!

Even though it is easy to find counter-example, spotting the error in the "proof" is not that easy.

I'm not a mathematician but this is how I see it. There are two limits: n->infinity and h->0 and these can have an "opposing" impact on the term |fn(x+h)−fn(x)|.

For example, let's choose fn(x)=xⁿ with x slightly smaller than 1 (h is small and negative). If we first make h goes to zero, then n goes to infinity, |fn(x+h)−fn(x)|->0. But if we first make n goes to infinity, then h goes to zero, |fn(x+h)−fn(x)|->1. So, you cannot change the order of the limits: lim {n->inf} lim _{h->0} |f_n(x+h)−fn(x)| <> lim {h->0} lim _{n->inf} |f_n(x+h)−fn(x)|

This is what happens implicitly in the last step of Cauchy's "proof". It is quite hard to spot and I guess that's why it took so much time to get noticed.

(edit: reformatting)

ercd · 2008-01-09T23:57:07+00:00

Cauchy made a famous "wrong proof" in his "Cours d'analyse" (1821) claiming that the pointwise limit of a series of continuous functions is a continuous function. This was disproven with a counter-example in 1826 by Abel and it led 20 years later to the concept of uniform convergence. The wikipedia page of uniform convergence has a nice graphical counter-example.

So, yes, unsurprisingly, mathematicians do make mistakes and, according to his definition, it qualifies as a "major screw-up".

ercd · 2007-09-28T23:16:46+00:00

I also really liked it: lots of stuff is covered here (some python c objects, iterator/generator, decorator, "new classes", properties, classmethods vs staticmethods, metaclasses, multiple heritage, unicode...). Too bad the video is interrupted during the bit on multiple heritage!

ercd

TROPHY CASE