Re: [idn] ACE37,AMCW and LDUDE

["Soobok Lee" <lsb@postel.co.kr>]

If you tested with my old reordering I-D version 0.9:
 You'd better try with my newly submitted I-D version 1.0 at
  http://www.postel.co.kr/lsb-ace-01.txt

 it contains many examples for CJK.
 40~50% shorter ACE labels are produced!

 It does better compression for European
 domains, too.

----- Original Message -----
From: "Soobok Lee" <lsb@postel.co.kr>
To: "Keith Moore" <moore@cs.utk.edu>
Cc: <idn@ops.ietf.org>
Sent: Saturday, July 07, 2001 8:14 AM
Subject: Re: [idn] ACE37,AMCW and LDUDE


>
> ----- Original Message -----
> From: "Keith Moore" <moore@cs.utk.edu>
>
>
> > I would *really* like to avoid complex reordering of codepoints, because
> > it would require fairly large tables (that would have to be implemented
> > on some machines of modest capability) and would be error-prone.
> >
>
> It's not complex.
> Its table is not so large compared to that of KC norm and
> NAMEPREP. ACE & NAMEPREP will be packaged into one library
> as MDNkit of JPNIC. Look into KC norm and NAMEPREP tables and
> think about the reordering table, more simpler.
>
> Reordering reduce the length typical ACE label about 40% ~ 50%.
> Please throughly test my example sources with average length of
> han/hangul domains.
>
> > I also fear that this kind of mapping would encourage greater use
> > of proxies over end-to-end implementations, with all of the implications
> > for reliability, control, delay, etc. that would result from this design
> > choice.  I don't think we want to encourage a walled garden.
>
> No proxies needed. No walls.
> All reordering is hidden and done in ACE & de-ACE libraries transparently.
>
> No delay at all. Because what is needed is "n=maptable[n]" operation.
> Single machine instruction away!!!
> What i implemented in my example source is using mapping functions
> with tables. IN the final version, we can use only tables.
>
> >
> > I could see having a very simple reordering of codepoints in order
> > to increase the efficiency of DUDE for ideographic languages.  But my
> > (admittedly biased) sense is that we're fast approaching the point
> > of diminishing returns.  Just how important is it to provide for names
> > that are one or two ideographs longer?
> >
> > Keith
> >
>
> With DUDE+REORDERING , we get 7~8 more Han ideographs.
> If you have enough time, test with many han examples.
>
> code-block shifting does not help to reduce average XOR distance
> in general cases ( good only for the first 4096 code block ).
>
> What is important is  to reduce ACE label length of AVERAGED
> han/hangul domains. THis working group should concentrage
> attentions  not to the max length issue but to  issues of
> reducing ACE label length of average hangul/han domains.
>
> Soobok Lee
>
>
>
>
>
>