Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #85915

Re: python implementation of a new integer encoding algorithm.

Path csiph.com!usenet.pasdenom.info!goblin2!goblin.stu.neva.ru!newsfeed.xs4all.nl!newsfeed3.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Return-Path <ian.g.kelly@gmail.com>
X-Original-To python-list@python.org
Delivered-To python-list@mail.python.org
X-Spam-Status OK 0.104
X-Spam-Level *
X-Spam-Evidence '*H*': 0.79; '*S*': 0.00; 'encoding': 0.05; 'binary': 0.07; 'removes': 0.07; 'wednesday,': 0.07; 'bits': 0.09; 'variant': 0.09; 'suggest': 0.14; '127': 0.16; '18:': 0.16; 'encoding.': 0.16; 'integers,': 0.16; 'length:': 0.16; 'unary': 0.16; 'subject:python': 0.16; 'weird': 0.16; 'all.': 0.16; 'wrote:': 0.18; 'bit': 0.19; 'differ': 0.19; 'thu,': 0.19; 'later': 0.20; 'feb': 0.22; 'appears': 0.22; 'byte': 0.24; 'looks': 0.24; 'define': 0.26; 'first,': 0.26; 'shown': 0.26; 'values': 0.27; 'header:In-Reply-To:1': 0.27; 'point': 0.28; 'am,': 0.29; 'character': 0.29; 'scale': 0.29; 'characters': 0.30; 'message-id:@mail.gmail.com': 0.30; "i'm": 0.30; 'claiming': 0.31; 'decimal': 0.31; 'implicit': 0.31; 'subject:skip:i 10': 0.31; 'probably': 0.32; "can't": 0.35; 'but': 0.35; 'received:google.com': 0.35; 'version': 0.36; '(we': 0.36; 'shorter': 0.36; "didn't": 0.36; 'shows': 0.36; 'half': 0.37; 'subject:new': 0.38; 'challenging': 0.38; 'saves': 0.38; 'to:addr :python-list': 0.38; 'short': 0.38; 'expect': 0.39; 'bad': 0.39; "couldn't": 0.39; 'extremely': 0.39; 'to:addr:python.org': 0.39; 'space': 0.40; 'dave': 0.60; 'results.': 0.60; 'full': 0.61; 'first': 0.61; 'provide': 0.64; 'more': 0.64; 'here': 0.66; 'sample': 0.67; 'results': 0.69; 'fact,': 0.69; 'wish': 0.70; 'below.': 0.71; 'applying': 0.72; 'introduce': 0.78; '10:': 0.84; '11:': 0.84; '12:': 0.84; '13:': 0.84; '14:': 0.84; '15:': 0.84; '2015': 0.84; 'beats': 0.84; 'borrow': 0.84; 'common,': 0.84; 'distinguish': 0.84; 'end.': 0.84; 'angel': 0.91; 'inefficient': 0.91
DKIM-Signature v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=EB4ZY+7U/IsODOZGYjzCMMk/snvxQ1Qtyt0ifvcyE1o=; b=MaXn32JVy7DD6MTEWRsPN/Y3hwER+uY2lb/sks0joq59A24dRVgAKzWi/LCi3Vxntk 6zUs4SNmG30BjHNIEez+/fAQoXjYOYzcszPIDTntNe7cYof0XMUO3m6XTiGtAAG809BV 6hYUzR67w4ULHo6XlGuprbSchRBdiIsqClgrpsIUcLcv7wyYmnGnXrpAW4ABrvb7ZNPI qQarnZ+6DRQ5kQXs7BNv+ZqH3Qga0a7Yv/tJ+4/WXPEZXhuo3j/0bf1WuJTH7HTuzJPq gtdMrQeQYhpF3UXuGPHsJ/KmNrC2XlsyBlV7USSG18sXCl4jaCVDsfohJw/9TeZUzHO0 SSDg==
X-Received by 10.70.130.37 with SMTP id ob5mr9463999pdb.72.1424369091678; Thu, 19 Feb 2015 10:04:51 -0800 (PST)
MIME-Version 1.0
In-Reply-To <993f64c3-fc85-48a7-9d02-a4f12ecb33c6@googlegroups.com>
References <e45a71b2-7ec0-4c7d-88ae-c48aebe154b7@googlegroups.com> <mailman.18784.1424182393.18130.python-list@python.org> <515047c1-a20d-430e-a029-1c2d77db2f1a@googlegroups.com> <mailman.18823.1424278025.18130.python-list@python.org> <2a717ffb-d61d-4407-9082-1c17cd7ee573@googlegroups.com> <mailman.18839.1424298000.18130.python-list@python.org> <993f64c3-fc85-48a7-9d02-a4f12ecb33c6@googlegroups.com>
From Ian Kelly <ian.g.kelly@gmail.com>
Date Thu, 19 Feb 2015 11:04:10 -0700
Subject Re: python implementation of a new integer encoding algorithm.
To Python <python-list@python.org>
Content-Type text/plain; charset=UTF-8
X-BeenThere python-list@python.org
X-Mailman-Version 2.1.15
Precedence list
List-Id General discussion list for the Python programming language <python-list.python.org>
List-Unsubscribe <https://mail.python.org/mailman/options/python-list>, <mailto:python-list-request@python.org?subject=unsubscribe>
List-Archive <http://mail.python.org/pipermail/python-list/>
List-Post <mailto:python-list@python.org>
List-Help <mailto:python-list-request@python.org?subject=help>
List-Subscribe <https://mail.python.org/mailman/listinfo/python-list>, <mailto:python-list-request@python.org?subject=subscribe>
Newsgroups comp.lang.python
Message-ID <mailman.18892.1424369100.18130.python-list@python.org> (permalink)
Lines 99
NNTP-Posting-Host 2001:888:2000:d::a6
X-Trace 1424369100 news.xs4all.nl 2883 [2001:888:2000:d::a6]:33808
X-Complaints-To abuse@xs4all.nl
Xref csiph.com comp.lang.python:85915

Show key headers only | View raw


On Thu, Feb 19, 2015 at 8:45 AM,  <janhein.vanderburg@gmail.com> wrote:
> On Wednesday, February 18, 2015 at 11:20:12 PM UTC+1, Dave Angel wrote:
>> I'm not necessarily doubting it, just challenging you to provide a data
>> sample that actually shows it.  And of course, I'm not claiming that
>> 7bit is in any way optimal.  You cannot define optimal without first
>> defining the distribution.
>
> Weird results.
> For a character size 2 the growth processes are shown below.
> I listed the decimal representations, the difficult representation, a stop bit encoding, and the number of characters they differ in length:
> 0:  00                          00                              0
> 1:  01                          01                              0
> 2:  10, 00                      10, 00                          0
> 3:  10, 01                      10, 01                          0
> 4:  10, 10                      11, 00                          0
> 5:  10, 11                      11, 01                          0
> 6:  11, 00.00                   11, 10, 00                      0
> 7:  11, 00.01                   11, 10, 01                      0
> 8:  11, 00.10                   11, 11, 00                      0
> 9:  11, 00.11                   11, 11, 01                      0
> 10: 11, 01.00                   11, 11, 10, 00                  1
> 11: 11, 01.01                   11, 11, 10, 01                  1
> 12: 11, 01.10                   11, 11, 11, 00                  1
> 13: 11, 01.11                   11, 11, 11, 01                  1
> 14: 11, 10.00, 00               11, 11, 11, 10, 00              1
> 15: 11, 10.00, 01               11, 11, 11, 10, 01              1
> 16: 11, 10.00, 10               11, 11, 11, 11, 00              1
> 17: 11, 10.00, 11               11, 11, 11, 11, 01              1
> 18: 11, 10.01, 00.00            11, 11, 11, 11, 10, 00          1
> 19: 11, 10.01, 00.01            11, 11, 11, 11, 10, 01          1
> 20: 11, 10.01, 00.10            11, 11, 11, 11, 11, 00          1
> 21: 11, 10.01, 00.11            11, 11, 11, 11, 11, 01          1
> 22: 11, 10.01, 01.00            11, 11, 11, 11, 11, 10, 00      2
> 23: 11, 10.01, 01.01            11, 11, 11, 11, 11, 10, 01      2
> 24: 11, 10.01, 01.10            11, 11, 11, 11, 11, 11, 00      2
> 25: 11, 10.01, 01.11            11, 11, 11, 11, 11, 11, 01      2
> 26: 11, 10.01, 10.00            11, 11, 11, 11, 11, 11, 10, 00  3
>
> I didn't take the time to prove it mathematically, but these results suggest to me that the complicated encoding beats the stop bit encoding.

That stop-bit variant looks extremely inefficient (and wrong) to me.
First, 2 bits per group is probably a bad choice for a stop-bit
encoding. It saves some space for very small integers, but it won't
scale well at all. Fully half of the bits are stop bits! Secondly, I
don't understand why the leading groups are all 11s and only the later
groups introduce variability. In fact, that's practically a unary
encoding with just a small amount of binary at the end. This is what I
would expect a 2-bit stop-bit encoding to look like:

0: 00
1: 01
2: 11, 00
3: 11, 01
4: 11, 10, 00
5: 11, 10, 01
6: 11, 11, 00
7: 11, 11, 01
8: 11, 10, 10, 00
9: 11, 10, 10, 01
10: 11, 10, 11, 00
11: 11, 10, 11, 01
12: 11, 11, 10, 00
13: 11, 11, 10, 01
14: 11, 11, 11, 00
15: 11, 11, 11, 01
16: 11, 10, 10, 10, 00
17: 11, 10, 10, 10, 01
18: 11, 10, 10, 11, 00
19: 11, 10, 10, 11, 01
20: 11, 10, 11, 10, 00
21: 11, 10, 11, 10, 01
22: 11, 10, 11, 11, 00
23: 11, 10, 11, 11, 01
24: 11, 11, 10, 10, 00
25: 11, 11, 10, 10, 01
26: 11, 11, 10, 11, 00
27: 11, 11, 10, 11, 01
28: 11, 11, 11, 10, 00
29: 11, 11, 11, 10, 01
30: 11, 11, 11, 11, 00
31: 11, 11, 11, 11, 01
etc.

Notice that the size grows as O(log n), not O(n) as above. Notice also
that the only values here for which this saves space over the 7-bit
version are 0-7. Unless you expect those values to be very common, the
7-bit encoding that needs only one byte all the way up to 127 makes a
lot of sense.

There's also an optimization that can be added here if we wish to
inject a bit of cleverness. Notice that all values with more than one
group start with 11, never 10. We can borrow a trick from IEEE
floating point and make the leading 1 bit of the mantissa implicit for
all values greater than 3 (we can't do it for 2 and 3 because then we
couldn't distinguish them from 0 and 1). Applying this optimization
removes one full group from the representation of all values greater
than 3, which appears to make the stop-bit representation as short as
or shorter than the "difficult" one for all the values that have been
enumerated above.

Back to comp.lang.python | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

python implementation of a new integer encoding algorithm. janhein.vanderburg@gmail.com - 2015-02-17 03:22 -0800
  Re: python implementation of a new integer encoding algorithm. Chris Angelico <rosuav@gmail.com> - 2015-02-18 00:16 +1100
    Re: python implementation of a new integer encoding algorithm. janhein.vanderburg@gmail.com - 2015-02-18 00:55 -0800
      Re: python implementation of a new integer encoding algorithm. Chris Angelico <rosuav@gmail.com> - 2015-02-18 20:36 +1100
        Re: python implementation of a new integer encoding algorithm. janhein.vanderburg@gmail.com - 2015-02-18 11:29 -0800
      Re: python implementation of a new integer encoding algorithm. Laura Creighton <lac@openend.se> - 2015-02-18 11:32 +0100
        Re: python implementation of a new integer encoding algorithm. janhein.vanderburg@gmail.com - 2015-02-18 11:48 -0800
      People hated it for the same reasons I found them cool (was: python implementation of a new integer encoding algorithm.) Ben Finney <ben+python@benfinney.id.au> - 2015-02-18 21:57 +1100
  Re: python implementation of a new integer encoding algorithm. Dave Angel <davea@davea.name> - 2015-02-17 09:12 -0500
    Re: python implementation of a new integer encoding algorithm. janhein.vanderburg@gmail.com - 2015-02-18 00:59 -0800
      Re: python implementation of a new integer encoding algorithm. Dave Angel <davea@davea.name> - 2015-02-18 11:46 -0500
        Re: python implementation of a new integer encoding algorithm. Grant Edwards <invalid@invalid.invalid> - 2015-02-18 17:30 +0000
          Re: python implementation of a new integer encoding algorithm. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-02-18 18:12 +0000
        Re: python implementation of a new integer encoding algorithm. janhein.vanderburg@gmail.com - 2015-02-18 11:55 -0800
          Re: python implementation of a new integer encoding algorithm. Marko Rauhamaa <marko@pacujo.net> - 2015-02-18 23:54 +0200
            Re: python implementation of a new integer encoding algorithm. Marko Rauhamaa <marko@pacujo.net> - 2015-02-19 00:08 +0200
            Re: python implementation of a new integer encoding algorithm. Grant Edwards <invalid@invalid.invalid> - 2015-02-18 22:58 +0000
          Re: python implementation of a new integer encoding algorithm. Dave Angel <davea@davea.name> - 2015-02-18 17:19 -0500
            Re: python implementation of a new integer encoding algorithm. janhein.vanderburg@gmail.com - 2015-02-19 07:45 -0800
              Re: python implementation of a new integer encoding algorithm. Ian Kelly <ian.g.kelly@gmail.com> - 2015-02-19 11:04 -0700
              Re: python implementation of a new integer encoding algorithm. Ian Kelly <ian.g.kelly@gmail.com> - 2015-02-19 11:16 -0700
              Re: python implementation of a new integer encoding algorithm. Dave Angel <davea@davea.name> - 2015-02-19 13:24 -0500
              Re: python implementation of a new integer encoding algorithm. Chris Angelico <rosuav@gmail.com> - 2015-02-20 05:34 +1100
              Re: python implementation of a new integer encoding algorithm. Ian Kelly <ian.g.kelly@gmail.com> - 2015-02-19 11:32 -0700
              Re: python implementation of a new integer encoding algorithm. Dave Angel <davea@davea.name> - 2015-02-19 13:41 -0500
              Re: python implementation of a new integer encoding algorithm. Dave Angel <davea@davea.name> - 2015-02-19 13:46 -0500
              Re: python implementation of a new integer encoding algorithm. Chris Angelico <rosuav@gmail.com> - 2015-02-20 05:49 +1100
      Re: python implementation of a new integer encoding algorithm. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-02-18 17:00 +0000
  Re: python implementation of a new integer encoding algorithm. Chris Angelico <rosuav@gmail.com> - 2015-02-18 01:34 +1100
    Re: python implementation of a new integer encoding algorithm. janhein.vanderburg@gmail.com - 2015-02-18 01:04 -0800
      Re: python implementation of a new integer encoding algorithm. Dave Angel <davea@davea.name> - 2015-02-18 08:54 -0500
        Re: python implementation of a new integer encoding algorithm. janhein.vanderburg@gmail.com - 2015-02-18 11:52 -0800
      Re: python implementation of a new integer encoding algorithm. Chris Angelico <rosuav@gmail.com> - 2015-02-19 01:16 +1100
  Re: python implementation of a new integer encoding algorithm. Dave Angel <davea@davea.name> - 2015-02-17 09:50 -0500
  Re: python implementation of a new integer encoding algorithm. Chris Angelico <rosuav@gmail.com> - 2015-02-18 01:58 +1100
  Re: python implementation of a new integer encoding algorithm. Dave Angel <davea@davea.name> - 2015-02-17 10:18 -0500
  Re: python implementation of a new integer encoding algorithm. Chris Angelico <rosuav@gmail.com> - 2015-02-18 02:25 +1100
  Re: python implementation of a new integer encoding algorithm. Paul Rubin <no.email@nospam.invalid> - 2015-02-17 08:43 -0800
    Re: python implementation of a new integer encoding algorithm. janhein.vanderburg@gmail.com - 2015-02-18 01:06 -0800
  Re: python implementation of a new integer encoding algorithm. Mario Figueiredo <marfig@gmail.com> - 2015-02-19 08:44 +0100
    Re: python implementation of a new integer encoding algorithm. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-02-19 08:06 +0000
      Re: python implementation of a new integer encoding algorithm. Marko Rauhamaa <marko@pacujo.net> - 2015-02-19 10:36 +0200
        Re: python implementation of a new integer encoding algorithm. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-02-19 09:33 +0000
        Re: python implementation of a new integer encoding algorithm. Terry Reedy <tjreedy@udel.edu> - 2015-02-19 14:50 -0500
          Re: python implementation of a new integer encoding algorithm. Marko Rauhamaa <marko@pacujo.net> - 2015-02-19 21:55 +0200
    Re: python implementation of a new integer encoding algorithm. Chris Angelico <rosuav@gmail.com> - 2015-02-19 19:36 +1100
    Re: python implementation of a new integer encoding algorithm. Mario Figueiredo <marfig@gmail.com> - 2015-02-19 10:42 +0100
    Re: python implementation of a new integer encoding algorithm. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-02-19 10:28 +0000
    Re: python implementation of a new integer encoding algorithm. Mario Figueiredo <marfig@gmail.com> - 2015-02-19 14:27 +0100
  Re: python implementation of a new integer encoding algorithm. Jonas Wielicki <jonas@wielicki.name> - 2015-02-19 09:38 +0100
    Re: python implementation of a new integer encoding algorithm. janhein.vanderburg@gmail.com - 2015-02-19 07:58 -0800
  Re: python implementation of a new integer encoding algorithm. Denis McMahon <denismfmcmahon@gmail.com> - 2015-02-20 02:46 +0000
    Re: python implementation of a new integer encoding algorithm. wxjmfauth@gmail.com - 2015-02-20 00:58 -0800

csiph-web