<?xml version="1.0"?>
<!-- name="generator" content="blosxom/2.0.2" -->
<!DOCTYPE rss PUBLIC "-//Netscape Communications//DTD RSS 0.91//EN" "http://my.netscape.com/publish/formats/rss-0.91.dtd">

<rss version="0.91">
  <channel>
    <title>peteg's blog   2007-09-15-UnicodeNumerals.autumn</title>
    <link>http://peteg.org/blog</link>
    <description></description>
    <language>en</language>

  <item>
    <title>&lt;a href=&quot;http://unicode.org/&quot;&gt;Unicode&lt;/a&gt; Numerals.</title>
    <link>http://peteg.org/blog/2007/09/15#2007-09-15-UnicodeNumerals</link>
    <category>/cs</category>
    <description>
&lt;p&gt;

OK, take a deep breath. Look at &lt;a
href=&quot;http://en.wikipedia.org/wiki/Unicode_numerals&quot;&gt;this page&lt;/a&gt; and
tell me the world isn't crazy.

&lt;/p&gt;&lt;p&gt;

Say you want to talk to the world in &lt;a href=&quot;http://unicode.org/&quot;&gt;Unicode&lt;/a&gt;, but you want to do
it &lt;em&gt;quickly&lt;/em&gt;. Well, obviously you're going to draft &lt;a href=&quot;http://www.lysator.liu.se/c/&quot;&gt;C&lt;/a&gt;'s
&lt;code&gt;atoi&lt;/code&gt; and friends to convert numerals to your internal
integer type, right? That's great in theory, but when your code is
running on someone else's webserver that you know little about, things
might get a little tricky.

&lt;/p&gt;&lt;p&gt;

&lt;a href=&quot;http://haskell.org/&quot;&gt;Haskell&lt;/a&gt;'s &lt;a href=&quot;http://www.cse.unsw.edu.au/~chak/haskell/ffi/&quot;&gt;FFI&lt;/a&gt; specifies that the functions in the
&lt;code&gt;CString&lt;/code&gt; module are subject to the current
&lt;em&gt;locale&lt;/em&gt;, which renders them unpredictable on the hitherto
mentioned webserver. I can imagine a numeral encoding that
e.g. &lt;code&gt;strtol_l&lt;/code&gt; understands with the locale setting of
today that it fails to understand tomorrow. I don't think there are
enough manpages in all the world to clarify this problem.

&lt;/p&gt;&lt;p&gt;

Solution? Use integers only for internal purposes, like user
identifiers, render them in &lt;a href=&quot;http://en.wikipedia.org/wiki/ASCII&quot;&gt;ASCII&lt;/a&gt;, and use &lt;a href=&quot;http://unicode.org/&quot;&gt;Unicode&lt;/a&gt; strings for
everything else. Don't use the &lt;code&gt;CString&lt;/code&gt; module, carefully
unpack &lt;a href=&quot;http://en.wikipedia.org/wiki/UTF-8&quot;&gt;UTF-8&lt;/a&gt; &lt;code&gt;ByteString&lt;/code&gt;s into &lt;a href=&quot;http://haskell.org/&quot;&gt;Haskell&lt;/a&gt;
&lt;code&gt;String&lt;/code&gt;s, and don't expect warp speed. If you're (cough)
putting this stuff in a library, hope like hell your users don't try
anything too weird.

&lt;/p&gt;&lt;p&gt;

One day someone will resolve all the issues of implementing a proper
&lt;a href=&quot;http://unicode.org/&quot;&gt;Unicode&lt;/a&gt; I/O layer, and I will thank them for it.

&lt;/p&gt;</description>
  </item>
  <item>
    <title>Proving insertion sort correct.</title>
    <link>http://peteg.org/blog/2007/03/14#2007-03-14-InsertionSort</link>
    <category>/cs</category>
    <description>
Fun and games. All I want to do is convince &lt;a href=&quot;http://isabelle.in.tum.de/&quot;&gt;Isabelle&lt;/a&gt; of the proposition
that, for a given list of objects, there is a permutation that is sorted
according to a given order. In case anyone thinks this is completely
trivial, I ask that you try to show that a recursive insertion sort does it
before reading &lt;a
href=&quot;http://www.cs.cornell.edu/courses/cs312/2004sp/lectures/rec11.txt&quot;&gt;this
cheat sheet&lt;/a&gt;. Perhaps merge sort is easier. Anyway, it is annoying that
there appear to be no results on sorting sequences in &lt;a href=&quot;http://isabelle.in.tum.de/&quot;&gt;Isabelle&lt;/a&gt;'s
library.</description>
  </item>
  <item>
    <title>Trees ain't trees.</title>
    <link>http://peteg.org/blog/2007/01/03#2007-01-03-Trees</link>
    <category>/cs</category>
    <description>
&lt;div class=&quot;figure&quot;&gt;
&lt;p&gt;&lt;a href=&quot;http://peteg.org//static/IMG_1681.JPG&quot;&gt;&lt;img src=&quot;http://peteg.org//static/cache/tn_IMG_1681.JPG&quot; width=&quot;70&quot; height=&quot;81&quot; class=&quot;scaled&quot; style=&quot;&quot; alt=&quot;&quot; /&gt;&lt;/a&gt;&lt;/p&gt;&lt;/div&gt;


&lt;p&gt;

Any idiot knows a tree has a &lt;a
href=&quot;http://en.wikipedia.org/wiki/Tree_data_structure&quot;&gt;branching
structure&lt;/a&gt;, or at least that's what we've been telling the first years
since time immemorial. There was a proper CS tree at &lt;a href=&quot;http://www.unsw.edu.au/&quot;&gt;UNSW&lt;/a&gt; back before I
got there that the internet doesn't appear to remember so well. This photo
of the &quot;right way up&quot; fig is from &lt;a
href=&quot;http://www.cse.unsw.edu.au/~geoffw/&quot;&gt;Geoff Whale&lt;/a&gt;'s data structures
textbook, and carries the following attribution:

&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;

Evidence that trees sometimes really are as shown in data structure
textbooks. Sculpture using the medium of a dead fig tree at &lt;a href=&quot;http://www.unsw.edu.au/&quot;&gt;UNSW&lt;/a&gt;. Photo
by Russell Bastock.

&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;

I reproduce it here without permission. That must be the Applied Science
building in the background and my guess is that it sat at the eastern end of
where the Red Centre is now.

&lt;/p&gt;

&lt;div class=&quot;figure&quot;&gt;
&lt;p&gt;&lt;a href=&quot;http://peteg.org//static/IMG_1673.JPG&quot;&gt;&lt;img src=&quot;http://peteg.org//static/cache/tn_IMG_1673.JPG&quot; width=&quot;70&quot; height=&quot;93&quot; class=&quot;scaled&quot; style=&quot;&quot; alt=&quot;&quot; /&gt;&lt;/a&gt;&lt;/p&gt;&lt;/div&gt;


&lt;p&gt;

I spotted this purported &quot;tree&quot; on Centennial Avenue, near Avoca St (which
runs between Queen and Centennial parks) several months ago but have only
now got around to photographing it. I grant that it appears to be a &lt;a
href=&quot;http://en.wikipedia.org/wiki/Directed_acyclic_graph&quot;&gt;DAG&lt;/a&gt;, and is
therefore for most purposes a tree.

&lt;/p&gt;</description>
  </item>
  </channel>
</rss>
