Op donderdag 9 april 2015 14:04:25 UTC+2 schreef Dave Angel:
> I still don't see where you have anywhere declared what your goal is.
Sorry that you didn't like the improvements to the stop bit encoding that I
illustrated in http://optarbvalintenc.blogspot.nl/2015/04/the-new-proposal.html
and the
On 04/09/2015 05:33 AM, janhein.vanderb...@gmail.com wrote:
Op donderdag 19 februari 2015 19:25:14 UTC+1 schreef Dave Angel:
I wrote the following pair of functions:
Here's a couple of ranges of output, showing that the 7bit scheme does
better for values between 384 and 16379.
Thanks fo
Op donderdag 19 februari 2015 19:25:14 UTC+1 schreef Dave Angel:
> I wrote the following pair of functions:
>
> def seven_code(n):
> acc = bytearray()
> if n == 0:
> acc.append(0)
> while n > 0:
> quotient, remainder = divmod(n, 128)
> acc.append(remainder
Op donderdag 19 februari 2015 19:05:12 UTC+1 schreef Ian:
> That stop-bit variant looks extremely inefficient (and wrong) to me.
You are right; I was wrong.
> 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
>
On Tue, 17 Feb 2015 03:22:47 -0800, janhein.vanderburg wrote:
> In http://optarbvalintenc.blogspot.nl/ I propose a new way to encode
> arbitrarily valued integers
I'm not quite sure I understand the problem that you're trying to solve
with this.
If I want to transmit some arbitrarily huge integ
Terry Reedy :
> It isn't, except that Guido gets a special pass
Wusses...
Or, it's good to be king.
Marko
--
https://mail.python.org/mailman/listinfo/python-list
On 2/19/2015 3:36 AM, Marko Rauhamaa wrote:
PS On the topic of pointlessness, why is top-posting the norm on
python-dev ... ?
It isn't, except that Guido gets a special pass and some of the posters
travel a lot and read and reply on phones, which makes snipping and
inline response difficult,
On Fri, Feb 20, 2015 at 5:41 AM, Dave Angel wrote:
> As I (and others) have said many times, making it optimal means making some
> assumptions about the distribution of likely values.
In fact, the very word "optimal" implies that. You have to have a set
of criteria on which you base your evaluati
On 02/19/2015 01:32 PM, Ian Kelly wrote:
On Thu, Feb 19, 2015 at 11:24 AM, Dave Angel wrote:
Here's a couple of ranges of output, showing that the 7bit scheme does
better for values between 384 and 16379.
382 2 80fe --- 2 7e82
383 2 80ff --- 2 7f82
384 3 81 --- 2 0083
384 jan grew 3 81000
On 02/19/2015 01:34 PM, Chris Angelico wrote:
On Fri, Feb 20, 2015 at 5:24 AM, Dave Angel wrote:
In all my experimenting, I haven't found any values where the 7bit scheme
does worse. It seems likely that for extremely large integers, it will, but
if those are to be the intended distribution, t
On Thu, Feb 19, 2015 at 11:24 AM, Dave Angel wrote:
> Here's a couple of ranges of output, showing that the 7bit scheme does
> better for values between 384 and 16379.
>
> 382 2 80fe --- 2 7e82
> 383 2 80ff --- 2 7f82
> 384 3 81 --- 2 0083
> 384 jan grew 3 81
> 385 3 810001 --- 2 0183
> 3
On Fri, Feb 20, 2015 at 5:24 AM, Dave Angel wrote:
> In all my experimenting, I haven't found any values where the 7bit scheme
> does worse. It seems likely that for extremely large integers, it will, but
> if those are to be the intended distribution, the 7bit scheme could be
> replaced by somet
On 02/19/2015 10:45 AM, janhein.vanderb...@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 opti
On Thu, Feb 19, 2015 at 11:04 AM, Ian Kelly wrote:
> 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 bi
On Thu, Feb 19, 2015 at 8:45 AM, 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
On Thursday, February 19, 2015 at 10:52:38 AM UTC+1, Jonas Wielicki wrote:
> I read through the discussion, but until you said it directly, I did not
> realize that you wanted feedback on your *python* code.
Thanks for the tips Jonas.
--
https://mail.python.org/mailman/listinfo/python-list
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
> defini
On Thu, Feb 19, 2015 at 11:28 AM, Mark Lawrence
wrote:
>
> No thanks as I won't be able to find any more candidates for my dream team.
>
>
I'm glad you like me here.
--
https://mail.python.org/mailman/listinfo/python-list
On 19/02/2015 09:42, Mario Figueiredo wrote:
On Thu, Feb 19, 2015 at 9:06 AM, Mark Lawrence mailto:breamore...@yahoo.co.uk>> wrote
The opinions being expressed seem to be along the lines of
"reinventing round wheels is a waste of time. Reinventing square or
even triangular wheels i
On Thu, Feb 19, 2015 at 9:06 AM, Mark Lawrence
wrote
>
>
> The opinions being expressed seem to be along the lines of "reinventing
> round wheels is a waste of time. Reinventing square or even triangular
> wheels is really pointless".
>
You obviously don't value the word 'exercise'.
> If you d
Dear Jan-Hein,
I read through the discussion, but until you said it directly, I did not
realize that you wanted feedback on your *python* code.
In that case, let me note a few things which make it unlikely that you
will get (usable) feedback:
1. The code on your website is not formatted and high
On 19/02/2015 08:36, Marko Rauhamaa wrote:
PS On the topic of pointlessness, why is top-posting the norm on
python-dev but shunned on python-list?
I don't know and I don't care provided top-posting remains the norm here.
--
My fellow Pythonistas, ask not what our language can do for you, ask
Mark Lawrence :
> The opinions being expressed seem to be along the lines of
> "reinventing round wheels is a waste of time. Reinventing square or
> even triangular wheels is really pointless".
I think it's even more pointless to mention the pointlessness of
someone's hobby.
Most pointless of al
On Thu, Feb 19, 2015 at 7:06 PM, Mark Lawrence wrote:
> On 19/02/2015 07:44, Mario Figueiredo wrote:
>>
>> A lot of patronizing egos running around in these groups. This is a
>> sad thread...
>>
>> What is being asked is for help, not whether this is useful or needed.
>> Jan-Hein is after some dir
On 19/02/2015 07:44, Mario Figueiredo wrote:
A lot of patronizing egos running around in these groups. This is a
sad thread...
What is being asked is for help, not whether this is useful or needed.
Jan-Hein is after some directions, not whether your bloody opinion on
how he should use his free t
A lot of patronizing egos running around in these groups. This is a
sad thread...
What is being asked is for help, not whether this is useful or needed.
Jan-Hein is after some directions, not whether your bloody opinion on
how he should use his free time.
If the interest and usability of a projec
On 2015-02-18, Marko Rauhamaa wrote:
> janhein.vanderb...@gmail.com:
>
>> Op woensdag 18 februari 2015 17:47:49 UTC+1 schreef Dave Angel:
>>> On 02/18/2015 03:59 AM, janhein.vanderb...@gmail.com wrote:
>>> > encoding individual integers optimally without any assumptions
>>> > about their values.
>
On 02/18/2015 02:55 PM, janhein.vanderb...@gmail.com wrote:
Op woensdag 18 februari 2015 17:47:49 UTC+1 schreef Dave Angel:
On 02/18/2015 03:59 AM, janhein.vanderb...@gmail.com wrote:
encoding individual integers optimally without any assumptions about their
values.
Contradiction in terms
Marko Rauhamaa :
> Out of curiosity, could you give me an example of an integer, not
> assuming anything about its value.
>
> I mean, any integer you could mention would be very close to zero
> compared with virtually all other integers.
And I don't mean to be snide, either. I'm just saying that
janhein.vanderb...@gmail.com:
> Op woensdag 18 februari 2015 17:47:49 UTC+1 schreef Dave Angel:
>> On 02/18/2015 03:59 AM, janhein.vanderb...@gmail.com wrote:
>> > encoding individual integers optimally without any assumptions
>> > about their values.
>>
>> Contradiction in terms.
>
> Not.
Out o
Op woensdag 18 februari 2015 17:47:49 UTC+1 schreef Dave Angel:
> On 02/18/2015 03:59 AM, janhein.vanderb...@gmail.com wrote:
>
>
> > encoding individual integers optimally without any assumptions about their
> > values.
> >
>
> Contradiction in terms.
>
> --
> DaveA
Not.
Jan-Hein.
--
https
Op woensdag 18 februari 2015 14:55:07 UTC+1 schreef Dave Angel:
> Define "beats." You might mean beats in simplicity, or in elegance, or
> in clarity of code. But you probably mean in space efficiency, or
> "compression." But that's meaningless without a target distribution of
> values that y
Op woensdag 18 februari 2015 11:33:18 UTC+1 schreef Laura Creighton:
> Hi Jan.
Hi Laura, thanks for your comments; let me explain my why:
> Should you ever need an assembler programmer for
> quick and dirty hacks for the PDP-11 line (11/20 and 11/05 preferred
> as it is harder) I am still the wom
Op woensdag 18 februari 2015 10:36:37 UTC+1 schreef Chris Angelico:
> I would actually look at it the other way:
I'm aware of that, since you already warned me with "This is a fine forum to
ask in. However, you may find that the advice you get isn't quite what you were
asking for. In my case, ...
On 18/02/2015 17:30, Grant Edwards wrote:
On 2015-02-18, Dave Angel wrote:
On 02/18/2015 03:59 AM, janhein.vanderb...@gmail.com wrote:
encoding individual integers optimally without any assumptions about
their values.
Contradiction in terms.
Ah, that depends on whether the encoding has t
On 2015-02-18, Dave Angel wrote:
> On 02/18/2015 03:59 AM, janhein.vanderb...@gmail.com wrote:
>
>
>> encoding individual integers optimally without any assumptions about
>> their values.
>
> Contradiction in terms.
Ah, that depends on whether the encoding has to be lossless or not.
For example:
On 18/02/2015 16:46, Dave Angel wrote:
On 02/18/2015 03:59 AM, janhein.vanderb...@gmail.com wrote:
encoding individual integers optimally without any assumptions about
their values.
Contradiction in terms.
I'm just pleased to see new blood coming through for my dream team, it's
been a b
On 02/18/2015 03:59 AM, janhein.vanderb...@gmail.com wrote:
encoding individual integers optimally without any assumptions about their
values.
Contradiction in terms.
--
DaveA
--
https://mail.python.org/mailman/listinfo/python-list
On Thu, Feb 19, 2015 at 12:54 AM, Dave Angel wrote:
>>> I've tried to read through the original algorithm description, but I'm
>>> not entirely sure: How many payload bits per transmitted byte does it
>>> actually achieve?
>>
>>
>> I don't think that payload bits per byte makes sense in this conce
On 02/18/2015 04:04 AM, janhein.vanderb...@gmail.com wrote:
On Tuesday, February 17, 2015 at 3:35:16 PM UTC+1, Chris Angelico wrote:
Oh, incidentally: If you want a decent binary format for
variable-sized integer, check out the MIDI spec.
I did some time ago, thanks, and it is indeed a decent
Hi Jan.
I'm an old fart. In the late 1970s, when I started programming these
things, and memory was non-existant, we came up with all sorts of data
compression algorithms which were absolutely necessary to get any work
done whatsoever. Should you ever need an assembler programmer for
quick and d
On Wed, Feb 18, 2015 at 7:55 PM, wrote:
>> Take the
>> easy option; you can always make things more complicated later.
> That makes sense alright.
> No offense, but I still believe that human readable text encoding complicates
> things right now and shouldn't be tried until "my way" has proven u
On Tuesday, February 17, 2015 at 5:43:43 PM UTC+1, Paul Rubin wrote:
> This is a reasonable place to ask specific python questions. The
> algorithm description itself is pretty confusing though, and it seems to
> address a problem that doesn't particularly seem to need a solution.
> It's pretty t
On Tuesday, February 17, 2015 at 3:35:16 PM UTC+1, Chris Angelico wrote:
> Oh, incidentally: If you want a decent binary format for
> variable-sized integer, check out the MIDI spec.
I did some time ago, thanks, and it is indeed a decent format.
I also looked at variations of that approach.
None o
On Tuesday, February 17, 2015 at 3:13:41 PM UTC+1, Dave Angel wrote:
> This is a fine forum for such a discussion. I for one would love to
> participate. However, note that it isn't necessary true that "the
> smaller the better" is a good algorithm. In context, there are
> frequently a number
On Tuesday, February 17, 2015 at 2:17:02 PM UTC+1, Chris Angelico wrote:
> This is a fine forum to ask in. However, you may find that the advice
> you get isn't quite what you were asking for. In my case, the advice
> I'm offering is: Don't do this.
Thanks Chris; let me explain why I want this.
As
janhein.vanderb...@gmail.com writes:
> The next step is the development of the python code that minimizes
> processor requirements without compromising the algorithm.
This is a reasonable place to ask specific python questions. The
algorithm description itself is pretty confusing though, and it s
On Wed, Feb 18, 2015 at 2:18 AM, Dave Angel wrote:
>> Sure. Not sure how you'd cope with an interior in the stream
>> without drastically losing efficiency, though.
>
>
> That's why it was base 65535, not 65536.
Doh. Yeah. I autocorrected in my head, but yes, base 65535 is safe.
ChrisA
--
On 02/17/2015 09:58 AM, Chris Angelico wrote:
On Wed, Feb 18, 2015 at 1:50 AM, Dave Angel wrote:
But the first thing I'd expect to see would be a target estimate of the
anticipated distribution of number values/magnitudes. For example, if a
typical integer is 1500 bits, plus/minus 200 bits, I'
On Wed, Feb 18, 2015 at 1:50 AM, Dave Angel wrote:
> But the first thing I'd expect to see would be a target estimate of the
> anticipated distribution of number values/magnitudes. For example, if a
> typical integer is 1500 bits, plus/minus 200 bits, I'd probably try encoding
> in base 65535, an
On 02/17/2015 09:34 AM, Chris Angelico wrote:
On Wed, Feb 18, 2015 at 1:12 AM, Dave Angel wrote:
They had a field type called a "compressed integer." It could vary between
one byte and I think about six. And the theory was that it took less space
than the equivalent format of fixed size integ
On Wed, Feb 18, 2015 at 1:12 AM, Dave Angel wrote:
> They had a field type called a "compressed integer." It could vary between
> one byte and I think about six. And the theory was that it took less space
> than the equivalent format of fixed size integers.
Oh, incidentally: If you want a decen
On 02/17/2015 06:22 AM, janhein.vanderb...@gmail.com wrote:
In http://optarbvalintenc.blogspot.nl/ I propose a new way to encode
arbitrarily valued integers and the python code that can be used as a reference
for practical implementations of codecs.
The encoding algorithm itself is optimized f
On Tue, Feb 17, 2015 at 10:22 PM, wrote:
> In http://optarbvalintenc.blogspot.nl/ I propose a new way to encode
> arbitrarily valued integers and the python code that can be used as a
> reference for practical implementations of codecs.
>
> The encoding algorithm itself is optimized for transmi
54 matches
Mail list logo
