pocketsphinx no module named pocketsphinx found

[ldompeling]

I try to run an example python file for pocketsphinx but I get this error: 

File "continuous_test.py", line 5, in 
from pocketsphinx.pocketsphinx import *
ImportError: No module named pocketsphinx

Does somebody knows how to repair this.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: pocketsphinx no module named pocketsphinx found

[Peter Otten]

ldompel...@casema.nl wrote:

> I try to run an example python file for pocketsphinx but I get this error:
> 
> File "continuous_test.py", line 5, in 
> from pocketsphinx.pocketsphinx import *
> ImportError: No module named pocketsphinx
> 
> Does somebody knows how to repair this.

Did you install pocketsphinx successfully?

If not, well, it should be obvious that you cannot import a package that is 
not installed. The pypi page lists the requirements:

https://pypi.python.org/pypi/pocketsphinx

Make sure that those for your system are fulfilled and then retry the 
install.

If yes, did you create a module called pocketsphinx.py to try out the 
library? Then rename your own module and remove the corresponding 
pocketsphinx.pyc.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: pocketsphinx no module named pocketsphinx found

[ldompeling]

Op dinsdag 12 juli 2016 10:00:51 UTC+2 schreef ldomp...@casema.nl:
> I try to run an example python file for pocketsphinx but I get this error: 
> 
> File "continuous_test.py", line 5, in 
> from pocketsphinx.pocketsphinx import *
> ImportError: No module named pocketsphinx
> 
> Does somebody knows how to repair this.

I think that pocketsphinx installed successfully because I install it on my 
raspberry pi with sudo-apt-get
How can I create a module named pocketsphinx.py to try out the library.

Thanks
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: pocketsphinx no module named pocketsphinx found

[Steven D'Aprano]

On Tuesday 12 July 2016 18:47, ldompel...@casema.nl wrote:

> Op dinsdag 12 juli 2016 10:00:51 UTC+2 schreef ldomp...@casema.nl:
>> I try to run an example python file for pocketsphinx but I get this error:
>> 
>> File "continuous_test.py", line 5, in 
>> from pocketsphinx.pocketsphinx import *
>> ImportError: No module named pocketsphinx
>> 
>> Does somebody knows how to repair this.
> 
> I think that pocketsphinx installed successfully because I install it on my
> raspberry pi with sudo-apt-get 

Are you running two different versions of Python? If you are, then perhaps apt-
get installed it for the system Python, but you're running a different version.

If your Raspberry Pi is running "locate", you can run this:

locate site-packages


and it will show you all the third-party Python packages installed in the 
standard location. Can you see pocketsphinx? If not, then it is not installed.

Once you are sure it is installed, try running these lines at the Python 
prompt, one at a time, and tell us exactly what happens:


import pocketsphinx


If there is no error, what does this give?0

print (pocketsphinx.__file__)


(There are TWO underscores at the start and end of "file".)



> How can I create a module named
> pocketsphinx.py to try out the library.

DON'T do that. You **do not** want to create a module called "pocketsphinx.py". 
If you have, that may be your problem. Call it something else, like "main.py" 
or "testps.py", or "mypocketsphinx.py".




-- 
Steve

-- 
https://mail.python.org/mailman/listinfo/python-list

Getting number of neighbours for a 3d numpy arrays

[Heli]

Hi, 

I have a 3d numpy array containing true/false values for each i,j,k. The size 
of the array is a*b*c. 

for each cell with indices i,j,k; I will need to check all its neighbours and 
calculate the number of neighbour cells with true values. 

A cell with index i,j,k has the following neighbours :

n1 with indices [i-1,j,k] if i>0 ; cell with i=0 does not have any n1 
neighbour. (left neighbour)

n2 with inidices [i+1,j,k] if i0
n4 with inidces [i,j+1,k] if j0
n6 with indices [i,j,k+1] if k0 :
n1=myarray[i-1,j,k]
if n1== True:
n_neigh+=1

if i<248:
n2=grains_3d[i+1,j,k]
if n2== True:
n_neigh_grains+=1

if j>0:
n3=myarray[i,j-1,k]
if n3== True:
n_neigh+=1

if j<1247:
n4=myarray[i,j+1,k]
if n4== True:
n_neigh+=1

if k>0 :
n5=myarray[i,j,k-1]
if n5== True:
n_neigh+=1

if k<169:
n6=myarray[i,j,k+1]
if n6== True:
n_neigh+=1

Is there anyway I can get an array containg all n1 neighbour, a second array 
containing all n2 neighbours and so on and then add n1 to n6 arrays 
element-wise to get all neighbours that meet certain conditions for a cell. 

Thanks in Advance for your help, 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What is precision of a number representation?

[Antoon Pardon]

Op 12-07-16 om 06:19 schreef Steven D'Aprano:
> On Tue, 12 Jul 2016 07:51 am, Chris Angelico wrote:
>
>> say, 2,147
>> millimeters, with a precision of four significant digits
>
> How do you represent 1 mm to a precision of four significant digits, in such
> a way that it is distinguished from 1 mm to one significant digit, and 1 mm
> to a precision of four decimal places?
>
> 0001
> 1
> 1.

Your question doesn't has an answer because 1 mm doesn't have a precision of
four significant digits.

A precision is an indication of a fault tolerance. You don't indicate less
fault tolerace by writing it as 0001.

Please explain how 0001 represants a difference in precision than just 1.

Writing 1. instead of 1 can be understood as the actual number being
between 0.5 and 1.5 instead of the actual number being between
0.95 and 1.05.

Now between which two numbers is 0001 supposed to be?

-- 
Antoon Pardon


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What is precision of a number representation?

[Marko Rauhamaa]

Antoon Pardon :

> Op 12-07-16 om 06:19 schreef Steven D'Aprano:
>> How do you represent 1 mm to a precision of four significant digits,
>> in such a way that it is distinguished from 1 mm to one significant
>> digit, and 1 mm to a precision of four decimal places?
>
> Your question doesn't has an answer because 1 mm doesn't have a
> precision of four significant digits.

Your statement is invalid. You presuppose some notational conventions.
1 mm is simply one millimeter; in and of itself it doesn't in any way
convey precision.

> A precision is an indication of a fault tolerance. You don't indicate
> less fault tolerace by writing it as 0001.

I doubt a "fault" is relevant here. In ordinary usage, precision refers
to a range of values, which is probably what you are getting at.

> Please explain how 0001 represants a difference in precision than just
> 1.

"Precision" here is not ordinary usage. Historically, it comes from the
printf(3) library function:

Each conversion specification is introduced by the character %,
and ends with a conversion specifier. In between there may be (in
this order) zero or more flags, an optional minimum field width,
an optional precision and an optional length modifier.
[man 3 printf]

Thus, "precision" is simply the name of a formatting field, regardless
of the semantics of that field. The name was chosen because for floating
point numbers, it actually refers to the precision of the numeric
representation. However, the field has other uses that have nothing to
do with precision:

Precision [...] gives the minimum number of digits to appear for d,
i, o, u, x, and X conversions, the number of digits to appear after
the radix character for a, A, e, E, f, and F conversions, the
maximum number of significant digits for g and G conversions, or the
maximum number of characters to be printed from a string for s and S
conversions.
[man 3 printf]

> Writing 1. instead of 1 can be understood as the actual number
> being between 0.5 and 1.5 instead of the actual number being
> between 0.95 and 1.05.

That certainly is a very common practice.

> Now between which two numbers is 0001 supposed to be?

What is your problem? What practical trouble is Python's format method
giving you?

Do you ever "turn on" a light or "roll down" a window by pushing a
button? Do you "turn up" the volume by moving a slider? Why, do you ever
"write" to a solid state "disk?"


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What is precision of a number representation?

[Antoon Pardon]

Op 12-07-16 om 12:27 schreef Marko Rauhamaa:
> Antoon Pardon :
>
>> Op 12-07-16 om 06:19 schreef Steven D'Aprano:
>>> How do you represent 1 mm to a precision of four significant digits,
>>> in such a way that it is distinguished from 1 mm to one significant
>>> digit, and 1 mm to a precision of four decimal places?
>> A precision is an indication of a fault tolerance. You don't indicate
>> less fault tolerace by writing it as 0001.
>
>> Please explain how 0001 represants a difference in precision than just
>> 1.
> "Precision" here is not ordinary usage. Historically, it comes from the
> printf(3) library function:

Steven was talking about significant digits. So my use of precision
was in that context. So I think your printf here is irrelevant.

Talking about how your number is printed is different from talking
about the significance of the digits. If you for whatever reason want
to write 1 as 0001, be my guest.

If you state that this somehow expresses a difference in significant
digits, I would like someone to explain how. And yes I want that expressed
in difference of fault or error tolerance, because that is what IMO
significant digits refer to.

>
>> Now between which two numbers is 0001 supposed to be?
> What is your problem? What practical trouble is Python's format method
> giving you?

This is not about Python's format. This is about someone stating a
difference in significant digits.

-- 
Antoon. 


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: pocketsphinx no module named pocketsphinx found

[ldompeling]

Op dinsdag 12 juli 2016 10:00:51 UTC+2 schreef ldomp...@casema.nl:
> I try to run an example python file for pocketsphinx but I get this error: 
> 
> File "continuous_test.py", line 5, in 
> from pocketsphinx.pocketsphinx import *
> ImportError: No module named pocketsphinx
> 
> Does somebody knows how to repair this.
I had python version 2.6 3.0 3.4 installed and removed.
I reinstall pocketsphinx python and now I don't get any errors while import 
from pocketsphinx. So I tried to run some python examples and now I get this 
error. I don't have a clue whats coing on.

INFO: feat.c(715): Initializing feature stream to type: '1s_c_d_dd', ceplen=13, 
CMN='live', VARNORM='no', AGC='none'
INFO: cmn.c(97): mean[0]= 12.00, mean[1..12]= 0.0
ERROR: "acmod.c", line 83: Folder 'pocketsphinx/model/en-us/en-us' does not 
contain acoustic model definition 'mdef'
Traceback (most recent call last):
  File "example.py", line 15, in 
decoder = Decoder(config)
  File "/usr/local/lib/python2.7/dist-packages/pocketsphinx/pocketsphinx.py", 
line 271, in __init__
this = _pocketsphinx.new_Decoder(*args)
RuntimeError: new_Decoder returned -1
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: pocketsphinx no module named pocketsphinx found

[Steven D'Aprano]

On Tue, 12 Jul 2016 09:32 pm, ldompel...@casema.nl wrote:

> I reinstall pocketsphinx python and now I don't get any errors while
> import from pocketsphinx. So I tried to run some python examples and now I
> get this error. I don't have a clue whats coing on.

[...]

> RuntimeError: new_Decoder returned -1

That's a pocketsphinx error. Try reading the docs, or asking on the
pocketsphinx forums. You might be lucky and find somebody here who knows
pocketsphinx, but your best chance will come from a specialist pocketsphinx
forum.




-- 
Steven
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Getting number of neighbours for a 3d numpy arrays

[Peter Otten]

Heli wrote:

> I have a 3d numpy array containing true/false values for each i,j,k. The
> size of the array is a*b*c.
> 
> for each cell with indices i,j,k; I will need to check all its neighbours
> and calculate the number of neighbour cells with true values.
> 
> A cell with index i,j,k has the following neighbours :
> 
> n1 with indices [i-1,j,k] if i>0 ; cell with i=0 does not have any n1
> neighbour. (left neighbour)

I'm not a numpy expert, so the following may be less elegant than and not as 
efficient as possible; it may also be outright wrong ;)

With that caveat:

$ cat neighbours.py   
import numpy
from collections import deque


def print_int(a):
print(numpy.array(a, dtype=int))

# generate sample data

numpy.random.seed(42)

SHAPE = (3, 3, 3)
DIMENSIONS = len(SHAPE)  # dimensions

a = numpy.random.random(SHAPE) < .5
b = numpy.zeros(SHAPE, dtype=int)

print("input data:")
print_int(a)
print("")


# actual calculation
full = slice(None, None, None)
left = slice(None, -1, None)
right = slice(1, None, None)

ileft = deque([left] + [full] * (DIMENSIONS-1))
iright = deque([right] + [full] * (DIMENSIONS-1))
for i in range(DIMENSIONS):
b[ileft] += a[iright]
b[iright] += a[ileft]
ileft.rotate()
iright.rotate()

print("number of neighbours:")
print(b)
$ python neighbours.py
input data:
[[[1 0 0]
  [0 1 1]
  [1 0 0]]

 [[0 1 0]
  [0 1 1]
  [1 1 0]]

 [[1 1 0]
  [1 1 1]
  [1 0 1]]]

number of neighbours:
[[[0 3 1]
  [3 2 2]
  [1 3 1]]

 [[3 2 2]
  [3 5 3]
  [3 2 3]]

 [[2 3 2]
  [3 4 3]
  [2 4 1]]]


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Getting number of neighbours for a 3d numpy arrays

[Nobody]

Some common ways to handle the boundary condition:

1. Generate clamped indices, test for validity and substitute invalid
entries with an "identity" element. E.g.

ijk = np.mgrid[:a,:b,:c]
i,j,k = ijk
i0,j0,k0 = np.maximum(0,ijk-1)
i1,j1,k1 = np.minimum(np.array(a,b,c).T-1,ijk+1)

n1 = (i>0  ) & myarray[i0,j,k]
n2 = (i0  ) & myarray[i,j0,k]
n4 = (j0  ) & myarray[i,j,k0]
n6 = (k0  ) & np.roll(myarray, 1,axis=0)
n2 = (i0  ) & np.roll(myarray, 1,axis=1)
n4 = (j0  ) & np.roll(myarray, 1,axis=2)
n6 = (khttps://mail.python.org/mailman/listinfo/python-list

Re: What is precision of a number representation?

[Steven D'Aprano]

On Tue, 12 Jul 2016 07:50 pm, Antoon Pardon wrote:

> Op 12-07-16 om 06:19 schreef Steven D'Aprano:
>> On Tue, 12 Jul 2016 07:51 am, Chris Angelico wrote:
>>
>>> say, 2,147
>>> millimeters, with a precision of four significant digits
>>
>> How do you represent 1 mm to a precision of four significant digits, in
>> such a way that it is distinguished from 1 mm to one significant digit,
>> and 1 mm to a precision of four decimal places?
>>
>> 0001
>> 1
>> 1.
> 
> Your question doesn't has an answer because 1 mm doesn't have a precision
> of four significant digits.

None of this argument has even the slightest relevance to the question of
what the so-called "precision" field in a format string means with integer
arguments. Regardless of any consensus, or lack thereof, about what a
measurement precision of "four significant digits" might mean for a
measurement of 1 unit, the meaning and usefulness of the precision field in
format strings will remain. How do you get this result with format?

py> "%8.4d" % 29
'0029'


If you don't like my interpretation of leading zeroes, okay, I'm not going
to defend it. It's really not that important. Perhaps after thinking about
it more I'll also decide that it doesn't really make sense.

When it comes to printf and the string % operator with integer types, the
so-called "precision" field should not be understood as anything to do with
measurement error.


> A precision is an indication of a fault tolerance. You don't indicate less
> fault tolerace by writing it as 0001.

Measurement precision, as indicated by significant digits, doesn't have
anything to do with fault tolerance. It tells you the estimated error in
the measurement, not how much fault your application can withstand. "Fault
tolerance" is a technical term that refers to the ability of a system,
machine or device to continue working correctly even when parts of it have
broken down.


> Please explain how 0001 represants a difference in precision than just 1.

The first is a 16-bit word; the second is a 4-bit nybble.

Or, if the numbers are in decimal, perhaps the first comes from an old
analogue speedometers, where there are four counters. This tells you that
the largest possible number that we could count is . The second in that
case could come from a single analogue counter, in which case the largest
number is 9.



-- 
Steven
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What is precision of a number representation?

[Random832]

On Tue, Jul 12, 2016, at 02:21, Steven D'Aprano wrote:
> If not, then what are the alternatives? Using str.format, how would
> you get the same output as this?
> 
> 
> py> "%8.4d" % 25
> '0025'

"%04d" % 25

"%8s" % ("%04d" % 25)

The latter (well, generally, "format it how you want and then use %*s to
put it in fixed columns") is something that I've actually *done*,
because it's easier to reason about.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: subprocess: xterm -c cat, need to send data to cat and have it displayed in the xterm window

[Random832]

On Tue, Jul 12, 2016, at 02:27, Steven D'Aprano wrote:
> On Tuesday 12 July 2016 13:20, Veek. M wrote:
> > I then need to get it translated which also works and then display in
> > XTerm using cat.
> 
> Why not just print it? Why do you have to use cat?

Well, displaying something in a new xterm (i.e. not one that already
exists and is your controlling terminal) without a process to run "in"
the terminal is rather esoteric and isn't portable to terminals other
than xterm.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: subprocess: xterm -c cat, need to send data to cat and have it displayed in the xterm window

[Veek. M]

Steven D'Aprano wrote:

> On Tuesday 12 July 2016 13:20, Veek. M wrote:
> 
>> Script grabs some image data and runs imagemagick on it to extract
>> some chinese. Then tesseract OCR to get the actual unicode.
>> 
>> I then need to get it translated which also works and then display in
>> XTerm using cat.
> 
> Why not just print it? Why do you have to use cat? That sounds like
> "Useless use of cat" to me:
> 
> 
http://porkmail.org/era/unix/award.htmlhttp://porkmail.org/era/unix/award.html
> 

Yeah, i changed that to 'tail -f' - works much better with tempfile.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Compression of random binary data

[jonas . thornvall]

Den måndag 11 juli 2016 kl. 20:38:51 UTC+2 skrev Steven D'Aprano:
> On Tue, 12 Jul 2016 03:52 am, jonas.thornv...@gmail.com wrote:
> 
> > What kind of statistic law or mathematical conjecture  or is it even a
> > physical law is violated by compression of random binary data?
> 
> The pigeon hole principle. If you have 100 pigeon holes, and 101 pigeons,
> then clearly at least one pigeon hole must have two pigeons in it.
> 
> To keep the numbers small and manageable, let's say we are going to compress
> one byte at a time. Now a byte has eight bits, so there are exactly 256
> possible bytes:
> 
>  
>  0001
>  0010
> ...
>  1110
>  
> 
> Now, suppose I claim that I can LOSSLESSLY (that is, reversibly) compress
> any random byte to just two bits. The lossless part is important: its not
> hard to compress random data by irreversibly throwing some of it away, and
> there's no violation there.
> 
> So I claim that you can give me any random byte, I will compress it to just
> two bits:
> 
> 00
> 01
> 10
> 11
> 
> and then be able to decompress it back again to give you the original byte
> once more.
> 
> Obviously I'm trying to pull a fast one! There's no way I can do this. I can
> squeeze 256 pigeons into just four pigeon holes, but only by doubling them
> up. Suppose I compress these three bytes to 00:
> 
>  
> 0110 1001
> 1100 0110
> 
> Now when I go to uncompress 00, what should I return? There is no way for me
> to know which of the three was the original value.
> 
> (If I'm cunning, I'll have sneakily stored some data *elsewhere*, say, in
> the file name, or in a database, so that you need this extra hidden data to
> uncompress the 00 back to a full byte. But then I'm not compressing eight
> bits down to two. I'm compressing eight bits down to two bits plus
> who-knows-how-many-bits of hidden data.)
> 
> So the pigeon hole principle tells us one of two things:
> 
> (1) If you compress random data, then it must be lossy; I can compress eight
> bits to two, but then I can't uncompress it back again, at least not
> without throwing away some data.
> 
> (2) Or, if the compression is lossless, then some data must be expanded
> rather than compressed. If you pick data at random, some of it will be
> expanded.
> 
> Suppose I have a compression algorithm that infallibly and reversibly
> compresses as follows:
> 
>   <--> 00
>  0001 <--> 01
>  0010 <--> 10
>  0011 <--> 11
> 
> That part is fine. But what will my algorithm do with the other 252 bytes?
> At *best* it will leave them untouched:
> 
>  0100 <-->  0100
> ...
>   <-->  
> 
> which is no compression at all, but at worst it will actually expand them
> and make them bigger. (After all, it's likely that my compression format
> has at least a bit of overhead.)
> 
> In practice, compression algorithms are designed to look for particular
> kinds of order or structure in the data, and compress that. That's fine for
> the sorts of non-random data we care about: pictures are rarely pictures of
> static, text files are rarely random collections of bits. But if you do
> throw a random set of bits at a lossless compression algorithm, it will at
> best not compress it at all, and at worst actually make the file bigger.
> 
> 
> > What is to say that you can not do it if the symbolic representation is
> > richer than the symbolic represenatation of the dataset.
> > 
> > Isn't it a fact that the set of squareroots actually depict numbers in a
> > shorter way than their actual representation.
> 
> Sure. But you need to know what √2 means. It *represents* the number
> 1.41421356237... but doesn't compress it. There's nothing you can do to the
> symbol √2 that will uncompress back to the infinite series of digits. All
> you can do is look it up somewhere to see what the digits are.
> 
> > Now the inpretator or program must know the rules. And i have very good
> > rules to make it happen.
> 
> Right. How much information is in the rules? More than you save with
> the "compression". Consider:
> 
> 1.41421356237 compressed down to √2, that's 13 characters down to 2. Great!
> But to *uncompress*, you need to store a rule:
> 
> √2=1.41421356237 
> 
> and that's *sixteen* characters. So your "compression" is:
> 
> original: 13
> compressed to: 2
> plus rule: 16
> 
> means you have "compressed" 13 characters to 18.
> 
> Now, this is still worth doing if you need to repeat the √2 many times, so
> long as you don't have to repeat the rule. That's useful. But it's not
> compression. It's more like keeping an index to a database, or a scrap of
> paper with the title of a book written on it:
> 
> "See Lord Of The Rings, by J.R.R. Tolkien"
> 
> That's a lot smaller than the actual book: eight words, instead of who knows
> how many tens of thousands. But you can't call it compression: you can't
> sit down with the scrap of paper *and nothing else* and uncompress it back
> to the entire LOTR trilogy.
> 
> 
> 
> 

Re: Compression of random binary data

[jonas . thornvall]

Den tisdag 12 juli 2016 kl. 05:01:20 UTC+2 skrev Lawrence D’Oliveiro:
> On Tuesday, July 12, 2016 at 5:52:27 AM UTC+12, jonas.t...@gmail.com wrote:
> 
> > What kind of statistic law or mathematical conjecture  or is it even a
> > physical law is violated by compression of random binary data? 
> 
> Try compressing already-compressed data.
> 
> Does that answer your question?

Yes that is my question, and also a claim i can do it.
-- 
https://mail.python.org/mailman/listinfo/python-list

How do you guys tackle a package with poorish documentation?

[Veek. M]

I've been messing with QQ (a Chinese chat app) and started receiving a 
lot of shady traffic partly because I was stupid enough to install the 
insecure QQ=international version. 

Anyway, so I decided to write something to provide me with a diff for 
networks. Basically track my current n/w with marginal shady traffic and 
then try to track what happens when I connect.

scapy seems like the internet approved version for python but I 
installed: pypcap https://github.com/dugsong/pypcap

import pcap
for ts, pkt in pcap.pcap():
print ts, `pkt`

which prints a timestamp and a pkt reference. Works great. Unfortunately 
I want what's in the packet and took a look at: pydoc pcap

 class pcap(__builtin__.object)
 |  pcap(name=None, snaplen=65535, promisc=True, timeout_ms=None, 
immediate=False)  -> packet capture object

So, what's a 'packet capture object'? It's not in pydoc and I then 
wasted a lot of time looking for better docs hoping it'll be in a book 
or in an on-line tutorial, and that's when I encountered scapy.
pypcap is and egg with a .so so how do you even do anything with it?

My question is: how do you guys deal with a situation like this? Do you 
look through the source code? Do you switch to scapy? Do you now look 
for books on scapy - there are quite a few, with chapters covering it.

A lot of my time goes to the dogs browsing for stuff so I was wondering 
if that's the norm? 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Compression of random binary data

[Steven D'Aprano]

On Wed, 13 Jul 2016 12:24 am, jonas.thornv...@gmail.com wrote:

> Den måndag 11 juli 2016 kl. 20:38:51 UTC+2 skrev Steven D'Aprano:
>> On Tue, 12 Jul 2016 03:52 am, jonas.thornv...@gmail.com wrote:
>> 
>> > What kind of statistic law or mathematical conjecture  or is it even a
>> > physical law is violated by compression of random binary data?
>> 
>> The pigeon hole principle. If you have 100 pigeon holes, and 101 pigeons,
>> then clearly at least one pigeon hole must have two pigeons in it.
[...]
> But it seem your reasoning is based upon interpretation of the actual
> digits, bits and bytes value.

Not at all. If you think that, you've misread my example. There's no
interpretation of the bytes: they are just 8-bit numbers from 0 to 255. You
cannot losslessly compress all 256 of them to just four 2-bit numbers.


> There could be different interpretation 
> worlds of course you would have to chose one using digits, An 
> interpretationworld here could be reading out different word lengths of
> the dataset and maybe a lookup table.

Any lookup table you have counts as part of the compressed data.


> But it could also be arithmetic rules that magically recreate a number
> from a number of folds or difference of folds.

Oh, sure, if you believe in magic, anything is possible. Just close your
eyes, click your heels together, and wish really, really hard.

Suppose I could compress ANY random data, no matter what, down to 10% of the
original size. Okay, let's start with a million bits of data. Compress it
down to 100,000 bits.

But I believe that I can compress *anything*, any random collection of data.
Okay, let me compress it again. Now I have 10,000 bits.

Compress it again. Now I have 1,000 bits.

Compress it again. Now I have 100 bits.

Compress it again. Now I have 10 bits.

Compress it again. Now I have 1 bit, either a 0 or a 1.


Can you not see how absurd this is? I have claimed that I can take *any*
random set of data, and by compressing it again and again and again,
compress it down to ONE BIT, either a 0 or a 1, WITHOUT LOSS. Somehow I
have to take that 0 bit and uncompress it back to the Complete Works Of
William Shakespeare, and *also* uncompress it back to the recent Deadpool
movie, AND uncompress it back to last year's Ant Man movie, AND uncompress
it back to some funny picture of a cat.

How can I possibly know which of the billions and billions of different
files this 0 bit represents?

If you pass me a 0 bit, and say "uncompress this", and I get The Lord Of The
Rings novels, and then you pass me another 0 bit, and I uncompress it and
get The Hobbit, well, how did I tell the two bits apart? They're both zero.



The alternative is to say, it doesn't matter how clever you are, you can't
compress *everything*. There are some things that simply won't compress.
Eventually you get something no longer compresses. If you could compress
EVERYTHING, then you could compress the compressed data, and compress the
compressed-compressed data, and so on, until you've got only a single bit.
And that is ridiculous.



-- 
Steven
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Compression of random binary data

[Steven D'Aprano]

On Wed, 13 Jul 2016 12:29 am, jonas.thornv...@gmail.com wrote:

> Den tisdag 12 juli 2016 kl. 05:01:20 UTC+2 skrev Lawrence D’Oliveiro:
>> On Tuesday, July 12, 2016 at 5:52:27 AM UTC+12, jonas.t...@gmail.com
>> wrote:
>> 
>> > What kind of statistic law or mathematical conjecture  or is it even a
>> > physical law is violated by compression of random binary data?
>> 
>> Try compressing already-compressed data.
>> 
>> Does that answer your question?
> 
> Yes that is my question, and also a claim i can do it.

Can you also make a perpetual motion machine, square the circle, and find an
exact rational fraction equal to pi?


What gets me is the people who *say* that they can compress already
compressed data. We know they can't, because if they could, they could
compress it again and again and again and again until there was only a
single bit, AND STILL REVERSE IT, using no external storage. Your lookup
tables are part of the compressed data. If the "compressed file" plus the
lookup table is bigger than the original file, then you haven't really
compressed anything. You've just moved some of it from the file into a
lookup table.

So why do people claim that they can compress already compressed data? Who
are they fooling? Themselves?



-- 
Steve

-- 
https://mail.python.org/mailman/listinfo/python-list

how raspi-idle3 configure?

[Egon Mueller]

Hello,
is there a manual concerning the python3-ide on a raspberry / debian jessie?
- The menue bar and the items there would I like to have a little bit 
greater for better readability.
- After running a program is needed long search to return to editing 
window.

- 

Where can read a beginner so simple things about handling the python 3 
idle3? I don't think about python programming, only about better 
handling the ide.


Thanks
Egon
--
https://mail.python.org/mailman/listinfo/python-list

Re: Compression of random binary data

[mm0fmf]

On 12/07/2016 15:29, jonas.thornv...@gmail.com wrote:

Den tisdag 12 juli 2016 kl. 05:01:20 UTC+2 skrev Lawrence D’Oliveiro:

On Tuesday, July 12, 2016 at 5:52:27 AM UTC+12, jonas.t...@gmail.com wrote:


What kind of statistic law or mathematical conjecture  or is it even a
physical law is violated by compression of random binary data?


Try compressing already-compressed data.

Does that answer your question?


Yes that is my question, and also a claim i can do it.



*plonk*
--
https://mail.python.org/mailman/listinfo/python-list

Re: Compression of random binary data

[jonas . thornvall]

Den tisdag 12 juli 2016 kl. 17:12:01 UTC+2 skrev Steven D'Aprano:
> On Wed, 13 Jul 2016 12:24 am, jonas.thornv...@gmail.com wrote:
> 
> > Den måndag 11 juli 2016 kl. 20:38:51 UTC+2 skrev Steven D'Aprano:
> >> On Tue, 12 Jul 2016 03:52 am, jonas.thornv...@gmail.com wrote:
> >> 
> >> > What kind of statistic law or mathematical conjecture  or is it even a
> >> > physical law is violated by compression of random binary data?
> >> 
> >> The pigeon hole principle. If you have 100 pigeon holes, and 101 pigeons,
> >> then clearly at least one pigeon hole must have two pigeons in it.
> [...]
> > But it seem your reasoning is based upon interpretation of the actual
> > digits, bits and bytes value.
> 
> Not at all. If you think that, you've misread my example. There's no
> interpretation of the bytes: they are just 8-bit numbers from 0 to 255. You
> cannot losslessly compress all 256 of them to just four 2-bit numbers.
> 
> 
> > There could be different interpretation 
> > worlds of course you would have to chose one using digits, An 
> > interpretationworld here could be reading out different word lengths of
> > the dataset and maybe a lookup table.
> 
> Any lookup table you have counts as part of the compressed data.
> 
> 
> > But it could also be arithmetic rules that magically recreate a number
> > from a number of folds or difference of folds.
> 
> Oh, sure, if you believe in magic, anything is possible. Just close your
> eyes, click your heels together, and wish really, really hard.
> 
> Suppose I could compress ANY random data, no matter what, down to 10% of the
> original size. Okay, let's start with a million bits of data. Compress it
> down to 100,000 bits.
> 
> But I believe that I can compress *anything*, any random collection of data.
> Okay, let me compress it again. Now I have 10,000 bits.
> 
> Compress it again. Now I have 1,000 bits.
> 
> Compress it again. Now I have 100 bits.
> 
> Compress it again. Now I have 10 bits.
> 
> Compress it again. Now I have 1 bit, either a 0 or a 1.
> 
> 
> Can you not see how absurd this is? I have claimed that I can take *any*
> random set of data, and by compressing it again and again and again,
> compress it down to ONE BIT, either a 0 or a 1, WITHOUT LOSS. Somehow I
> have to take that 0 bit and uncompress it back to the Complete Works Of
> William Shakespeare, and *also* uncompress it back to the recent Deadpool
> movie, AND uncompress it back to last year's Ant Man movie, AND uncompress
> it back to some funny picture of a cat.
> 
> How can I possibly know which of the billions and billions of different
> files this 0 bit represents?
> 
> If you pass me a 0 bit, and say "uncompress this", and I get The Lord Of The
> Rings novels, and then you pass me another 0 bit, and I uncompress it and
> get The Hobbit, well, how did I tell the two bits apart? They're both zero.
> 
> 
> 
> The alternative is to say, it doesn't matter how clever you are, you can't
> compress *everything*. There are some things that simply won't compress.
> Eventually you get something no longer compresses. If you could compress
> EVERYTHING, then you could compress the compressed data, and compress the
> compressed-compressed data, and so on, until you've got only a single bit.
> And that is ridiculous.
> 
> 
> 
> -- 
> Steven
> “Cheer up,” they said, “things could be worse.” So I cheered up, and sure
> enough, things got worse.

No it is only compressible down to a limit given by the algorithm.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Compression of random binary data

[jonas . thornvall]

Den tisdag 12 juli 2016 kl. 17:19:54 UTC+2 skrev Steven D'Aprano:
> On Wed, 13 Jul 2016 12:29 am, jonas.thornv...@gmail.com wrote:
> 
> > Den tisdag 12 juli 2016 kl. 05:01:20 UTC+2 skrev Lawrence D’Oliveiro:
> >> On Tuesday, July 12, 2016 at 5:52:27 AM UTC+12, jonas.t...@gmail.com
> >> wrote:
> >> 
> >> > What kind of statistic law or mathematical conjecture  or is it even a
> >> > physical law is violated by compression of random binary data?
> >> 
> >> Try compressing already-compressed data.
> >> 
> >> Does that answer your question?
> > 
> > Yes that is my question, and also a claim i can do it.
> 
> Can you also make a perpetual motion machine, square the circle, and find an
> exact rational fraction equal to pi?
> 
> 
> What gets me is the people who *say* that they can compress already
> compressed data. We know they can't, because if they could, they could
> compress it again and again and again and again until there was only a
> single bit, AND STILL REVERSE IT, using no external storage. Your lookup
> tables are part of the compressed data. If the "compressed file" plus the
> lookup table is bigger than the original file, then you haven't really
> compressed anything. You've just moved some of it from the file into a
> lookup table.
> 
> So why do people claim that they can compress already compressed data? Who
> are they fooling? Themselves?
> 
> 
> 
> -- 
> Steve

Well the algorithm start with looking up a suitable folding structure "close 
enough to the number", then it works down the folding structure finding the 
fold where the difference or sum between the folds closest to zero.

You do the same prinicple with the remainder until zero is achieved.

So our first fold can either be bigger or smaller, and it seek a configuration 
for the fold that close in max on the actual random number. The second fold 
could be a fold that depending upon our first fold was bigger or smaller than 
number either will add or subtract lower layers of the fold. 

There will come out a difference that need to be folded, the process is 
repeated until there is nothing to fold.

It is basicly a search algorithm looking for suitable folding structures.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Compression of random binary data

[Michael Torrie]

On 07/12/2016 11:46 AM, jonas.thornv...@gmail.com wrote:
> Well the algorithm start with looking up a suitable folding structure
> "close enough to the number", then it works down the folding
> structure finding the fold where the difference or sum between the
> folds closest to zero.
> 
> You do the same prinicple with the remainder until zero is achieved.
> 
> So our first fold can either be bigger or smaller, and it seek a
> configuration for the fold that close in max on the actual random
> number. The second fold could be a fold that depending upon our first
> fold was bigger or smaller than number either will add or subtract
> lower layers of the fold.
> 
> There will come out a difference that need to be folded, the process
> is repeated until there is nothing to fold.
> 
> It is basicly a search algorithm looking for suitable folding
> structures.

Better patent it quickly then.  And you will win a noble prize for math
if you could do what you say you could.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: how raspi-idle3 configure?

[memilanuk]

Egon Mueller  online.de> writes:
> 
> Where can read a beginner so simple things about handling the python 3 
> idle3? I don't think about python programming, only about better 
> handling the ide.
> 

This link might be of some help...

https://hkn.eecs.berkeley.edu/~DYOO/python/idle_intro/index.html

HTH,

Monte


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: pocketsphinx no module named pocketsphinx found

[ldompeling]

Op dinsdag 12 juli 2016 10:00:51 UTC+2 schreef ldomp...@casema.nl:
> I try to run an example python file for pocketsphinx but I get this error: 
> 
> File "continuous_test.py", line 5, in 
> from pocketsphinx.pocketsphinx import *
> ImportError: No module named pocketsphinx
> 
> Does somebody knows how to repair this.

I work it out with importing pocketsphinx and sphinxbase but I have an other 
error:

Traceback (most recent call last):
  File "", line 1, in 
ImportError: No module named Decoder

Is there a way to download the module Decoder somewhere? 

 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Touch screen development in Python

[Jahn]

I was thinking about Python touch screen applications for industrial boards( 
computers).
If I have a touch screen  with that industrial board, what I must have 
installed to be able to 
write  touch screen applications in Python?


> On 11.07.2016 19:21, Jahn wrote:
> > Does anyone use Python for  developping  applications that  work with a 
> > touch screen?
> 
> Yes.
> 
> 
> You should probably specify the platform and the type of applications 
> that you're interested in.
> 
> Mobiles (Android, iOS, Sailfish OS)? Windows 10 Tablets? Ubuntu Touch? 
> Embedded systems?
> 
> 
> Regards,
> 
> Dietmar
> 
> -- 
> https://mail.python.org/mailman/listinfo/python-list



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Compression of random binary data

[jonas . thornvall]

Den tisdag 12 juli 2016 kl. 20:20:52 UTC+2 skrev Michael Torrie:
> On 07/12/2016 11:46 AM, jonas.thornv...@gmail.com wrote:
> > Well the algorithm start with looking up a suitable folding structure
> > "close enough to the number", then it works down the folding
> > structure finding the fold where the difference or sum between the
> > folds closest to zero.
> > 
> > You do the same prinicple with the remainder until zero is achieved.
> > 
> > So our first fold can either be bigger or smaller, and it seek a
> > configuration for the fold that close in max on the actual random
> > number. The second fold could be a fold that depending upon our first
> > fold was bigger or smaller than number either will add or subtract
> > lower layers of the fold.
> > 
> > There will come out a difference that need to be folded, the process
> > is repeated until there is nothing to fold.
> > 
> > It is basicly a search algorithm looking for suitable folding
> > structures.
> 
> Better patent it quickly then.  And you will win a noble prize for math
> if you could do what you say you could.

I doubt it i never got anyone before for my ideas.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Compression of random binary data

[jonas . thornvall]

Den tisdag 12 juli 2016 kl. 20:20:52 UTC+2 skrev Michael Torrie:
> On 07/12/2016 11:46 AM, jonas.thornv...@gmail.com wrote:
> > Well the algorithm start with looking up a suitable folding structure
> > "close enough to the number", then it works down the folding
> > structure finding the fold where the difference or sum between the
> > folds closest to zero.
> > 
> > You do the same prinicple with the remainder until zero is achieved.
> > 
> > So our first fold can either be bigger or smaller, and it seek a
> > configuration for the fold that close in max on the actual random
> > number. The second fold could be a fold that depending upon our first
> > fold was bigger or smaller than number either will add or subtract
> > lower layers of the fold.
> > 
> > There will come out a difference that need to be folded, the process
> > is repeated until there is nothing to fold.
> > 
> > It is basicly a search algorithm looking for suitable folding
> > structures.
> 
> Better patent it quickly then.  And you will win a noble prize for math
> if you could do what you say you could.

I must stress when i say number here i really mean +10 decimal digit. So i 
basicly search in on big numbers that i compress. So i divide the dataset into 
suitable sizes for compression.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Compression of random binary data

[jonas . thornvall]

Den tisdag 12 juli 2016 kl. 21:40:36 UTC+2 skrev jonas.t...@gmail.com:
> Den tisdag 12 juli 2016 kl. 20:20:52 UTC+2 skrev Michael Torrie:
> > On 07/12/2016 11:46 AM, jonas.thornv...@gmail.com wrote:
> > > Well the algorithm start with looking up a suitable folding structure
> > > "close enough to the number", then it works down the folding
> > > structure finding the fold where the difference or sum between the
> > > folds closest to zero.
> > > 
> > > You do the same prinicple with the remainder until zero is achieved.
> > > 
> > > So our first fold can either be bigger or smaller, and it seek a
> > > configuration for the fold that close in max on the actual random
> > > number. The second fold could be a fold that depending upon our first
> > > fold was bigger or smaller than number either will add or subtract
> > > lower layers of the fold.
> > > 
> > > There will come out a difference that need to be folded, the process
> > > is repeated until there is nothing to fold.
> > > 
> > > It is basicly a search algorithm looking for suitable folding
> > > structures.
> > 
> > Better patent it quickly then.  And you will win a noble prize for math
> > if you could do what you say you could.
> 
> I must stress when i say number here i really mean +10 decimal digit. So 
> i basicly search in on big numbers that i compress. So i divide the dataset 
> into suitable sizes for compression.

And the dataset chunks that comes out from the process can also be treated like 
a new datafile, so the compression is iterative down to a limit. 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Touch screen development in Python

[Dietmar Schwertberger]

On 12.07.2016 21:10, Jahn wrote:

I was thinking about Python touch screen applications for industrial boards( 
computers).
If I have a touch screen  with that industrial board, what I must have 
installed to be able to
write  touch screen applications in Python?
This could be any platform:  QNX, Android, Windows, Embedded Windows, 
Windows CE, Windows Mobile, Linux with X, Linux with Wayland, Linux 
command line and a display connected via SPI or whatever...
If you don't write which platform you actually have, you will probably 
not get answers that will help you.


Regards,

Dietmar

--
https://mail.python.org/mailman/listinfo/python-list

Re: Quick poll: gmean or geometric_mean

[Lawrence D’Oliveiro]

On Saturday, July 9, 2016 at 9:05:18 PM UTC+12, Peter Otten wrote:

> Life's too short for abbreviations.

Why is there no abbreviation for “abbreviation”?

Let me propose “brev”. Nice and ... um ... abbreviated.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Quick poll: gmean or geometric_mean

[Chris Angelico]

On Wed, Jul 13, 2016 at 8:13 AM, Lawrence D’Oliveiro
 wrote:
> On Saturday, July 9, 2016 at 9:05:18 PM UTC+12, Peter Otten wrote:
>
>> Life's too short for abbreviations.
>
> Why is there no abbreviation for “abbreviation”?
>
> Let me propose “brev”. Nice and ... um ... abbreviated.

abbr?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Quick poll: gmean or geometric_mean

[Lawrence D’Oliveiro]

On Monday, July 11, 2016 at 5:16:53 AM UTC+12, Ian wrote:

> For local variables I usually wouldn't bother with the units, but in
> general it's a good practice to help avoid crashing your orbiter into
> Mars.

The Mars Climate Orbiter fiasco wasn’t a problem with using the wrong units 
(dimensional analysis would have picked that up), but with using wrong unit 
_systems_.

Ironic to see a country that fought a war to liberate itself from an empire, 
still stay so wedded to “imperial” units...
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Quick poll: gmean or geometric_mean

[Lawrence D’Oliveiro]

On Monday, July 11, 2016 at 2:30:00 AM UTC+12, Rustom Mody wrote:

> Force is given by the negative of the universal_gravitational_constant times
> the mass_of_first_body times mass_of_second_body divided by the square of
> the distance_between_the_bodies
> 
> Cobol anyone?

Look at it this way: the ancients (Greeks, Babylonians etc) were doing their 
maths in the equivalent of Cobol.

The reason why mathematicians invented short names for things was because it 
made the structure easier to see. Being able to easily manipulate that 
structure is key to solving mathematical problems.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Compression of random binary data

[Ian Kelly]

On Tue, Jul 12, 2016 at 11:35 AM,   wrote:
>
> No it is only compressible down to a limit given by the algorithm.

Then your algorithm does not compress random data as you claimed.

For some input, determine the limiting output that it ultimately
compresses down to. Take that output and feed it through your
algorithm as if it were the original input. If the data are to be
considered random, then this input is just as probable as the
original. What output does the algorithm now create? If it just
returns the input unchanged, then how do you discern the original
input from this input when decompressing? If it returns a different
output of the same size, then repeat the process with the new output.
Now there are *two* outputs of that size that can't be repeated. There
are only finitely many possible outputs of that size, so eventually
you're going to have to get to one that either repeats an output -- in
which case your algorithm produces the same output for two different
inputs and is therefore incorrect -- or you will get to an input that
produces an output *larger* in size than the original.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Quick poll: gmean or geometric_mean

[alister]

On Tue, 12 Jul 2016 15:17:58 -0700, Lawrence D’Oliveiro wrote:

> On Monday, July 11, 2016 at 5:16:53 AM UTC+12, Ian wrote:
> 
>> For local variables I usually wouldn't bother with the units, but in
>> general it's a good practice to help avoid crashing your orbiter into
>> Mars.
> 
> The Mars Climate Orbiter fiasco wasn’t a problem with using the wrong
> units (dimensional analysis would have picked that up), but with using
> wrong unit _systems_.
> 
> Ironic to see a country that fought a war to liberate itself from an
> empire, still stay so wedded to “imperial” units...

The are not.

a US gallon is smaller than an Imperial Gallon
a US Mile is shorter than an Imperial mile
and probably most importantly (because it means they keep serving me 
short measures) a US pint is smaller than an Imperial Pint



-- 
Those who cannot remember the past are condemned to repeat it.
-- George Santayana
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How do you guys tackle a package with poorish documentation?

[Ben Finney]

"Veek. M"  writes:

> My question is: how do you guys deal with a situation like this? Do you 
> look through the source code? Do you switch to scapy? Do you now look 
> for books on scapy - there are quite a few, with chapters covering it.

Once you realise that there is significantly less incentive *for the
software maintainer* to spend the effort required in producing and
maintaining and distributing high-quality documentation, you necessarily
realise that someone must apply such an an incentive — otherwise the job
simply is not done.

With that realisation, it becomes immediately clear who has such an
incentive: newcomers to the library. Such as you and me.


So, when working through an unfamiliar library, make it a habit to
record the questions that are not immediately answered. Try to answer
them and record those answers in the same place.

Once you have enough understanding to know what works and what doesn't,
you will inevitably have a set of questions that were raised by trying
to learn the library, and were not answered in any obvious place.

Take those, file bug reports, make suggested patches to improve the
documentation.

All this assumes the project is community-maintained. If you come across
a library that is not community-maintained, walk away as soon as you
realise it; the hope of improvement is much lower.

> A lot of my time goes to the dogs browsing for stuff so I was
> wondering if that's the norm?

Until we make it the norm to *demand* better standards from each other,
and provide the example of doing that work with and for each other: yes.

-- 
 \“A free press is one where it's okay to state the conclusion |
  `\  you're led to by the evidence.” —Bill Moyers |
_o__)  |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Compression of random binary data

[jonas . thornvall]

Den onsdag 13 juli 2016 kl. 00:24:23 UTC+2 skrev Ian:
> On Tue, Jul 12, 2016 at 11:35 AM,   wrote:
> >
> > No it is only compressible down to a limit given by the algorithm.
> 
> Then your algorithm does not compress random data as you claimed.
> 
> For some input, determine the limiting output that it ultimately
> compresses down to. Take that output and feed it through your
> algorithm as if it were the original input. If the data are to be
> considered random, then this input is just as probable as the
> original. What output does the algorithm now create? If it just
> returns the input unchanged, then how do you discern the original
> input from this input when decompressing? If it returns a different
> output of the same size, then repeat the process with the new output.
> Now there are *two* outputs of that size that can't be repeated. There
> are only finitely many possible outputs of that size, so eventually
> you're going to have to get to one that either repeats an output -- in
> which case your algorithm produces the same output for two different
> inputs and is therefore incorrect -- or you will get to an input that
> produces an output *larger* in size than the original.

The dataset must have a certain size that is the only requirment, of course you 
can not compress something into nothing, at least the arithmetic ruleset need 
to be encoded but what would be the point to just compress something less than 
a couple of bytes. And of course the number of rounds you applied the algorithm 
must be stored. But that is no problem for small datasets.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Compression of random binary data

[jonas . thornvall]

Den onsdag 13 juli 2016 kl. 00:24:23 UTC+2 skrev Ian:
> On Tue, Jul 12, 2016 at 11:35 AM,   wrote:
> >
> > No it is only compressible down to a limit given by the algorithm.
> 
> Then your algorithm does not compress random data as you claimed.
> 
> For some input, determine the limiting output that it ultimately
> compresses down to. Take that output and feed it through your
> algorithm as if it were the original input. If the data are to be
> considered random, then this input is just as probable as the
> original. What output does the algorithm now create? If it just
> returns the input unchanged, then how do you discern the original
> input from this input when decompressing? If it returns a different
> output of the same size, then repeat the process with the new output.
> Now there are *two* outputs of that size that can't be repeated. There
> are only finitely many possible outputs of that size, so eventually
> you're going to have to get to one that either repeats an output -- in
> which case your algorithm produces the same output for two different
> inputs and is therefore incorrect -- or you will get to an input that
> produces an output *larger* in size than the original.

The later sounds reasonable that is start toggle between states.
-- 
https://mail.python.org/mailman/listinfo/python-list

Announcing PyBidi

[Lawrence D’Oliveiro]

Just thought I’d mention PyBidi , my
Python 3 wrapper for all the functionality in FriBidi that I could
usefully find, that I threw together over the weekend.

I’m impressed that FriBidi doesn’t just do bidirectional
logical-to-visual rearrangement, but it will also perform contextual
substitutions for Arabic ligatures, which look (to my nonexpert eyes)
like they might be good enough for day-to-day written text, without
having to resort to HarfBuzz, or Pango, or sophisticated stuff like
that.

(Feel free to point out I’m wrong; the only language I have any
familiarity with that uses, or used to use, Arabic script, is Malay
written in the old “Jawi” script.)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: how raspi-idle3 configure?

[Egon Mueller]

It is a little bit helpful and very interesting, but answers to my 
question isn't available.

I have to search again.


Am 12.07.2016 um 20:33 schrieb memilanuk:

Egon Mueller  online.de> writes:


Where can read a beginner so simple things about handling the python 3
idle3? I don't think about python programming, only about better
handling the ide.



This link might be of some help...

https://hkn.eecs.berkeley.edu/~DYOO/python/idle_intro/index.html

HTH,

Monte




--
https://mail.python.org/mailman/listinfo/python-list

Re: Were is a great place to Share your finished projects?

[Ben Finney]

Christian Gollwitzer  writes:

> Am 01.07.16 um 03:38 schrieb Ben Finney:
> > If one wants to avoid vendor lock-in, Github is not best: the
> > workflow tools (other than Git itself) are completely closed and not
> > available for implementation on another vendor's servers.
>
> Yes, but that is relevant only if the workflow (i.e. pull requests)

Pull requests. Code review. Issues. Integration with other services. All
the social information around all of those interactions, and more.

If *any* of that is valuable, then yes it's important that it not be
locked to any one vendor.

If *none* of that is valuable, then why prefer GitHub? Clearly people do
find those quite valuable, and it is disingenuous to pretend that the
code is the only valuable thing in a Github repository.

-- 
 \ “The cost of a thing is the amount of what I call life which is |
  `\   required to be exchanged for it, immediately or in the long |
_o__)   run.” —Henry David Thoreau |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: subprocess: xterm -c cat, need to send data to cat and have it displayed in the xterm window

[Lawrence D’Oliveiro]

On Tuesday, July 12, 2016 at 3:20:35 PM UTC+12, Veek. M wrote:
> I then need to get it translated which also works and then display in 
> XTerm using cat.


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Quick poll: gmean or geometric_mean

[Lawrence D’Oliveiro]

On Wednesday, July 13, 2016 at 10:58:14 AM UTC+12, alister wrote:

> a US gallon is smaller than an Imperial Gallon
> a US Mile is shorter than an Imperial mile
> and probably most importantly (because it means they keep serving me 
> short measures) a US pint is smaller than an Imperial Pint

I thought everything was bigger in the USA...
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Quick poll: gmean or geometric_mean

[Gene Heskett]

On Tuesday 12 July 2016 21:42:44 Lawrence D’Oliveiro wrote:

> On Wednesday, July 13, 2016 at 10:58:14 AM UTC+12, alister wrote:
> > a US gallon is smaller than an Imperial Gallon
> > a US Mile is shorter than an Imperial mile
> > and probably most importantly (because it means they keep serving me
> > short measures) a US pint is smaller than an Imperial Pint
>
> I thought everything was bigger in the USA...

Only the lies the pols tell us thru the mainsleaze media we loosely call 
news.  And although Texas is indeed pretty good sized, they still use 
the std definition for a foot, mile or gallon.  Been there, checked it 
out personally.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Quick poll: gmean or geometric_mean

[Steven D'Aprano]

On Wed, 13 Jul 2016 08:57 am, alister wrote:

> a US gallon is smaller than an Imperial Gallon
> a US Mile is shorter than an Imperial mile
> and probably most importantly (because it means they keep serving me
> short measures) a US pint is smaller than an Imperial Pint

That's okay, they charge you more to make up for it being smaller.




-- 
Steven
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Compression of random binary data

[Steven D'Aprano]

On Wed, 13 Jul 2016 03:35 am, jonas.thornv...@gmail.com wrote:

> No it is only compressible down to a limit given by the algorithm.

Right! Then there is data that you can't compress.

Suppose you have some data:

data = "ABABABABABAB...ABAB"

And you compress it "down to a limit":

x = compress(compress(compress(data)))
print(x)
=> prints "@nx7%k!b"

Now let's try again with something else:

data = "AABBB..."

And you compress it "down to a limit":

x = compress(compress(compress(compress(data
print(x)
=> prints "wu*$cS#k-pv32zx[&+r"


One more time:

data = "AABBAABBAABBAABBAABB"
x = compress(data)
print(x)
=> prints "g^x3@"


We agree on this. Now you say, "Give me some random data, anything at all,
and I'll compress it!", and I run a random number generator and out pops:

data = "@nx7%k!b"

or possibly:

data = "wu*$cS#k-pv32zx[&+r"

or:

data = "g^x3@"


and I say "Compress that!"

But we've already agreed that this is as compressed as you can possibly make
it. You can't compress it any more.

So there's *at least some* random data that you can't compress. Surely you
have to accept that. You don't get to say "Oh, I don't mean *that* data, I
mean only data that I can compress". Random data means its random, you
don't get to pick and choose between data you can compress and data that
you can't.

Now the tricky part is to realise that its not just short sequences of
random data that can't be compressed. The same applies for LONG sequences
to. If I give you a gigabyte of raw video, you can probably compress that a
fair bit. That's what things like x264 encoders do. The x265 encoder is
even better. But they're lossy, so you can't reverse them.

But if I give you a gigabyte of random data, you'll be lucky to find *any*
patterns or redundancies that allow compression. You might be able to
shrink the file by a few KB. And if you take that already compressed file,
and try to compress it again, well, you've already hit the limit of
compression. There no more redundancy left to remove.

It doesn't matter how clever you are, or what a "folding structure" is, or
how many times you iterate over the data. It's a matter of absolute
simplicity: the pigeonhole principle. You can't argue with the numbers.

If you start with a 100 digit decimal number, there are 10**100 different
pigeons. If you can compress down to a 6 digit decimal number, there are
10**6 pigeon holes. You cannot put 10*100 pigeons into 10**6 pigeon holes
without doubling up (which makes your compression lossly).

So either some numbers cannot be compressed, or some numbers are compressed
to the same result, and you can't tell which was the original. That's your
choice: a lossless encoder means some numbers can't be compressed, a lossy
encoder means you can't reverse the process exactly.





-- 
Steven
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Were is a great place to Share your finished projects?

[Chris Angelico]

On Wed, Jul 13, 2016 at 11:28 AM, Ben Finney  wrote:
> Pull requests. Code review. Issues. Integration with other services. All
> the social information around all of those interactions, and more.
>
> If *any* of that is valuable, then yes it's important that it not be
> locked to any one vendor.

Exactly how important? Not so important as to stop slabs of Python
from migrating to GitHub, including its pull request system. (Work in
progress; currently, PEPs are on GitHub, but the core interpreter
hasn't moved yet. See PEP 512.)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Were is a great place to Share your finished projects?

[Ben Finney]

Chris Angelico  writes:

> On Wed, Jul 13, 2016 at 11:28 AM, Ben Finney  
> wrote:
> > Pull requests. Code review. Issues. Integration with other services.
> > All the social information around all of those interactions, and
> > more.
> >
> > If *any* of that is valuable, then yes it's important that it not be
> > locked to any one vendor.
>
> Exactly how important? Not so important as to stop slabs of Python
> from migrating to GitHub, including its pull request system.

I maintain that it is important enough to stop that.

The migration happened anyway, because not everyone is convinced of the
importance of avoiding vendor lock-in of valuable data, over criteria
such as “this person happens to like Vendor-locked Solution Foo”.

There are other projects considering such a migration; I am hopeful they
can still be reasoned with.

-- 
 \  “Begin with false premises and you risk reaching false |
  `\   conclusions. Begin with falsified premises and you forfeit your |
_o__)  authority.” —Kathryn Schulz, 2015-10-19 |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Were is a great place to Share your finished projects?

[Chris Angelico]

On Wed, Jul 13, 2016 at 2:42 PM, Ben Finney  wrote:
> Chris Angelico  writes:
>
>> On Wed, Jul 13, 2016 at 11:28 AM, Ben Finney  
>> wrote:
>> > Pull requests. Code review. Issues. Integration with other services.
>> > All the social information around all of those interactions, and
>> > more.
>> >
>> > If *any* of that is valuable, then yes it's important that it not be
>> > locked to any one vendor.
>>
>> Exactly how important? Not so important as to stop slabs of Python
>> from migrating to GitHub, including its pull request system.
>
> I maintain that it is important enough to stop that.
>
> The migration happened anyway, because not everyone is convinced of the
> importance of avoiding vendor lock-in of valuable data, over criteria
> such as “this person happens to like Vendor-locked Solution Foo”.
>

Fine. You're welcome to take a 100% philosophical stance; I applaud
you for it. (I understand Richard Stallman is so adamant about not
using *any* non-free code - software or firmware - that he restricts
himself to a tiny selection of laptops that have free BIOSes.)
Personally, I believe practicality beats purity in computing
philosophy as well as API design, and I'll happily let GitHub carry my
software. What's the worst that can happen? I have to switch to
somewhere else, and I lose the issue tracker and pull requests. In the
case of CPython, they wouldn't even be lost - they're (to be) backed
up. In the meantime, I'm on a well-polished platform with a large
number of users. The same cannot be said for *many* other hosts, even
if they do use exclusively free software.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Ian Kelly]

On Mon, Jul 11, 2016 at 9:38 PM, Steven D'Aprano  wrote:
> For integers, printf and % interpret the so-called "precision" field of the
> format string not as a measurement precision (number of decimal places),
> but as the number of digits to use (which is different from the total field
> width). For example:
>
>
> py> "%10.8x" % 123
> '  007b'
>
> How anyone can possibly claim this makes no sense is beyond me! Is the
> difference between "number of digits" and "number of decimal places" really
> so hard to grok? I think not.

I never claimed it's not useful. I don't really have a problem with
format supporting it, either. But if it does, then don't call it
"precision". That's like writing a function that calculates a mean and
calling it "mean", except that if passed a bunch of complex numbers,
it just returns the sum instead. I don't know of anybody who would
consider that good design, and the "precision" field in printf-style
formatting isn't good design either. But it has history behind it, so
does that put it in the right?

> And it's clearly useful: with integers, particular if they represent
> fixed-size byte quantities, it is very common to use leading zeroes. To a
> programmer the hex values 7b, 007b and 007b have very different
> meanings: the first is a byte, the second may be a short int, and the third
> may be a long int.

And what about 0007b? After all, the very example that started this
thread wanted 5 hex digits, not a nice, even power of 2.

> Why shouldn't we use the "precision" field for this?

For the same reason that we shouldn't use the "mean" function to calculate sums.

 If you truly wanted to format the number with a precision
 of 5 digits, it would look like this:

 0x123.00
>>>
>>> Er, no, because its an integer.
>>
>> Which is why if you actually want to do this, you should convert it to
>> a decimal or a float first (of course, those don't support hexadecimal
>> output, so if you actually want hexadecimal output *and* digits after
>> the (hexa)decimal point, then I think you would just have to roll your
>> own formatting at that point).
>
> What? No no no. Didn't you even look at Lawrence's example? He doesn't want
> to format the number with decimal places at all.

I was referring to the example above. I'm completely aware that it's
not the same as what Lawrence wanted.

> Converting an integer to a float just to use the precision field is just
> wrong.

What if I've been doing my math with fixed-point integers (because I
don't know about or just don't like decimals), and now I want to
format them for output? Is this just wrong?

'{:.2f}'.format(int_value / 100)

> Now lets go the other way. How to you distinguish between a distance
> measured using an unmarked metre stick, giving us an answer of 123 metres,
> versus something measured with a 10km ruler(!) with one metre markings?
> Obviously with *leading* zeroes rather than trailing zeroes.

Fair enough, but I still wouldn't call that "precision".

> It *does* matter for measuring curves, but paradoxically the bigger the
> measuring stick (the more leading zeroes) the worse your measurement is
> likely to be. This is the problem of measuring coastlines and is related to
> fractal dimension. Suppose I lay my 10km long measuring stick along some
> piece of coastline, and measure it as 00123 metres. (It's a *thought
> experiment*, don't hassle me about the unfeasibly large stick. Divide
> everything by a thousand and call it a 10m stick marked in millimetres if
> you like.) Chances are that if I used a 1 metre measuring stick, and
> followed the contour of the coast more closely, I'd get a different number.
> So the more leading zeroes, the less accurate your measurement is likely to
> be. But interesting as this is, for most purposes either we're not
> measuring a curve, or we are but pretend we're not and ignore the fractal
> dimension.

If you use a 1 meter stick to measure the coastline, you'll go mad as
the tide keeps ruining your careful measurements. Best to just use the
10 km stick and get it over with.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Were is a great place to Share your finished projects?

[Steven D'Aprano]

On Wednesday 13 July 2016 15:11, Chris Angelico wrote:

> You're welcome to take a 100% philosophical stance

It's not a philosophical stance to avoid vendor lockin, nor to avoid incipient 
monopolies, nor to avoid rewarding companies that behave badly.

It's not for philosophical reasons that we should avoid tendencies to band-
wagon jumping and monopoly building. Its for REAL, PRACTICAL reasons that the 
short-term gain will invariably be overwhelmed by the long-term loss.

You just need to value more than the immediate right here, right now, and not 
discount future risks excessively.

There are people who plan and plant great gardens which they will never see 
completed, trees taking many decades to reach maturity. And there are those who 
think that doing the washing on the weekend so they'll have clothes to wear on 
Tuesday counts as "long term planning".

People over-estimate the costs of technical competition and under-estimate the 
costs of monopolies and the single-network effect. They jump on the bandwagon 
of "but everyone else is using IBM/Windows/Word/iPhones/Facebook/Github/
whatever" and then wonder why conditions slowly get worse. Its boiling frogs 
everywhere.

Even if Github was 100% open source with no proprietary extensions, and the 
*technical* cost of leaving was low, the single-network effect would still lock 
you in, which leaves you (to some degree) at the mercy of Github's management. 
Don't like the fact that they run their servers on electricity made from 
burning puppies and the tears of little children? Too bad, what are you going 
to do, move your project to some backwater VCS where nobody ever goes? You 
might as well be on AOL for all anyone will ever find your project.

It boggles my mind that even devs who are the most socially aware and are all 
for diversity and codes of conduct and building a better world have such a 
blind eye when it comes to jumping on bandwagons and blindly following trends.


Time-to-read-Connie-Willis'-"Bellwether"-again-ly y'rs,



-- 
Steve

-- 
https://mail.python.org/mailman/listinfo/python-list