Dynamic query in mongodb and variable

[MG]

Ciao,
I have this function:


def lockup_info(refer):
info = []
amb = CONN.db..find({"reference": refer}
for a in amb:
print a



How can I pass this value { "$exists": False } and tell python to not consider 
it as a string?

var = '{ "$exists": False }'
lockup_info(var)



The code above doesn't work. A variable so defined is considered a string.
Thanks
-- 
https://mail.python.org/mailman/listinfo/python-list

Program outlining

[Rustom Mody]

Ive been trying to figure out the best outlining that emacs can give for
programs.

Outline-mode seems to be more for text than code

Outshine mode inspired by above+org-mode seemed promising in that it seems to
make org mode's wonderful TAB-behavior work for code.
But I couldn’t get it to work

So hideshow…
But hideshow keystrokes are clumsy

Even with the suggestions of 
http://stackoverflow.com/questions/791539/how-can-i-have-folds-for-c-java-in-emacs
to do

(add-hook 'c-mode-common-hook
  (lambda()
(local-set-key (kbd "C-c ") 'hs-show-block)
(local-set-key (kbd "C-c ")  'hs-hide-block)
(local-set-key (kbd "C-c ")'hs-hide-all)
(local-set-key (kbd "C-c ")  'hs-show-all)
(hs-minor-mode t)))

its better than the builtin defaults but not nearly as neat as org's
all-purpose TAB and Shift-TAB.

Is it so hard to do org's TAB cycling 
ie hs-show-block and hs-hide-block on the same key in cycle?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Program outlining

[Rustom Mody]

On Monday, July 11, 2016 at 6:26:01 PM UTC+5:30, Rustom Mody wrote:
> Ive been trying to figure out the best outlining that emacs can give for
> programs.

Oops sorry! Wrong list!!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Dynamic query in mongodb and variable

[Chris Angelico]

On Mon, Jul 11, 2016 at 10:52 PM, MG  wrote:
> Ciao,
> I have this function:
>
>
> def lockup_info(refer):
> info = []
> amb = CONN.db..find({"reference": refer}
> for a in amb:
> print a
>
>
>
> How can I pass this value { "$exists": False } and tell python to not 
> consider it as a string?
>
> var = '{ "$exists": False }'
> lockup_info(var)
>
>
>
> The code above doesn't work. A variable so defined is considered a string.

What do you want it to be, if not a string? Do you want to pass a
dictionary? Then do - just pass it in directly.

(Side point: I think you mean "lookup_info", not "lockup_info".)

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

Re: Curious Omission In New-Style Formats

[Ian Kelly]

On Sun, Jul 10, 2016 at 6:34 PM, Lawrence D’Oliveiro
 wrote:
> On Sunday, July 10, 2016 at 7:22:42 PM UTC+12, Ian wrote:
>> On Sat, Jul 9, 2016 at 11:54 PM, Lawrence D’Oliveiro wrote:
>>> In printf-style formats, you can specify the number of digits for an
>>> integer separately from the field width. E.g.
>>>
>>> >>> "%#0.5x" % 0x123
>>> '0x00123'
>>>
>> except perhaps that precision doesn't really make sense for integers
>> in the first place.
>
> Except that it does make sense, as I showed in my example.

Your example showed a 3-digit number being formatted with a requested
precision of 5 digits. The way this was done was by left-padding the
number with 0s until there were 5 digits, but still only 3 digits of
precision. If you truly wanted to format the number with a precision
of 5 digits, it would look like this:

0x123.00

It may happen to do what you want in the printf-style format, but
calling the field "precision" is at best misleading, and there are
other ways to accomplish the same result.

> 

Well, str.format does not use the same syntax as printf.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Steven D'Aprano]

On Tue, 12 Jul 2016 01:04 am, Ian Kelly wrote:

> On Sun, Jul 10, 2016 at 6:34 PM, Lawrence D’Oliveiro
>  wrote:
>> On Sunday, July 10, 2016 at 7:22:42 PM UTC+12, Ian wrote:
>>> On Sat, Jul 9, 2016 at 11:54 PM, Lawrence D’Oliveiro wrote:
 In printf-style formats, you can specify the number of digits for an
 integer separately from the field width. E.g.

 >>> "%#0.5x" % 0x123
 '0x00123'

>>> except perhaps that precision doesn't really make sense for integers
>>> in the first place.
>>
>> Except that it does make sense, as I showed in my example.
> 
> Your example showed a 3-digit number being formatted with a requested
> precision of 5 digits. The way this was done was by left-padding the
> number with 0s until there were 5 digits, 

Right.

> but still only 3 digits of precision.

Er, what? I count *five* digits in "00123", not three.

You seem to be assuming that "precision" can only refer to digits after the
decimal place, but that's a dubious proposition. That might be the way
printf interprets the precision for *floats*, but its not the way it
interprets the precision for *ints*, and who is to say that one way is
right and the other is wrong?


> 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.

Now, if I remember what I was told in my physics class circa 1985 correctly:

12345678 written with a precision of five digits is 12346000;

12345678 written with a precision of five decimal places is 12345678.0.

How should we extrapolate to the case where the precision *in digits* is
greater than the number of digits available? Well, for the "decimal places"
case, we add zeroes to the right. So for the digits case, we ought to add
zeroes to the left, which brings us back to the printf usage:

123 with five digits of precision is "00123".


And we can combine that with the overall length to pad the result with
spaces as well.

It seems to me that it would be reasonable to support this for format() too.


> It may happen to do what you want in the printf-style format, but
> calling the field "precision" is at best misleading, and there are
> other ways to accomplish the same result.

Naturally. So why bother to have .format() or % in the first place? There's
always other ways to accomplish the same result.





-- 
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: Curious Omission In New-Style Formats

[Ethan Furman]

On 07/11/2016 09:28 AM, Steven D'Aprano wrote:

On Tue, 12 Jul 2016 01:04 am, Ian Kelly wrote:



Er, what? I count *five* digits in "00123", not three.

You seem to be assuming that "precision" can only refer to digits after the
decimal place, but that's a dubious proposition.


I will readily admit to not having a maths degree, and so of course to 
me saying the integer 123 has a precision of 5, 10, or 99 digits seems 
like hogwash to me.


But I'm always willing to learn.  So please explain what 123 with a 
precision of five integer digits means, and what to do we gain by saying 
such a thing?


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

Touch screen development in Python

[Jahn]

Hi ,
Does anyone use Python for  developping  applications that  work with a touch 
screen?


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

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

Compression of random binary data

[jonas . thornvall]

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

I only know that Shanon theorised it could not be done, but were there any 
proof? 

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. 

Now the inpretator or program must know the rules. And i have very good rules 
to make it happen. 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Compression of random binary data

[Joonas Liik]

On 11 July 2016 at 20:52,   wrote:
> What kind of statistic law or mathematical conjecture  or is it even a 
> physical law is violated by compression of random binary data?
>
> I only know that Shanon theorised it could not be done, but were there any 
> proof?

Compression relies on some items in the dataset being more frequent
than others, if you have some dataset that is completely random it
would be hard to compress as most items have very similar number of
occurrances.

> 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.

A square root may be smaller numerically than a number but it
definitely is not smaller in terms of entropy.

lets try to compress the number 2 for instance using square roots.
sqrt(2) = 1.4142
the square root actually takes more space in this case even tho it is
a smaller number. so having the square root would have negative
compression in this case.
with some rounding back and forth we can probably get around the fact
that sqrt(2) would take an infinite amout of memory to accurately
represent but that neccesarily means restricting the values we are
possible of encoding.

for sqrt(2) to not have worse space consumprion than the number 2
itself we basically have to trow away precision so sqrt(2) ~= 1
now i challenge you to get that 2 back out of that 1..
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Touch screen development in Python

[Wildman via Python-list]

On Mon, 11 Jul 2016 19:21:56 +0200, Jahn wrote:

> Hi ,
> Does anyone use Python for  developping  applications that  work with a touch 
> screen?
> 

http://www.technolabsz.com/2011/08/how-to-make-touch-screen-user-interface.html

-- 
 GNU/Linux user #557453
The cow died so I don't need your bull!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Compression of random binary data

[jonas . thornvall]

Den måndag 11 juli 2016 kl. 20:09:39 UTC+2 skrev Waffle:
> On 11 July 2016 at 20:52,   wrote:
> > What kind of statistic law or mathematical conjecture  or is it even a 
> > physical law is violated by compression of random binary data?
> >
> > I only know that Shanon theorised it could not be done, but were there any 
> > proof?
> 
> Compression relies on some items in the dataset being more frequent
> than others, if you have some dataset that is completely random it
> would be hard to compress as most items have very similar number of
> occurrances.
> 
> > 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.
> 
> A square root may be smaller numerically than a number but it
> definitely is not smaller in terms of entropy.
> 
> lets try to compress the number 2 for instance using square roots.
> sqrt(2) = 1.4142
> the square root actually takes more space in this case even tho it is
> a smaller number. so having the square root would have negative
> compression in this case.
> with some rounding back and forth we can probably get around the fact
> that sqrt(2) would take an infinite amout of memory to accurately
> represent but that neccesarily means restricting the values we are
> possible of encoding.
> 
> for sqrt(2) to not have worse space consumprion than the number 2
> itself we basically have to trow away precision so sqrt(2) ~= 1
> now i challenge you to get that 2 back out of that 1..

Well who it to say different kind of numbers isn't treated differently, i mean 
all numbers isn't squares. All numbers isn't naturals.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Compression of random binary data

[MRAB]

On 2016-07-11 18:52, 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?

I only know that Shanon theorised it could not be done, but were there any 
proof?

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.

Now the inpretator or program must know the rules. And i have very good rules 
to make it happen.


If you want a challenge:

The Enduring Challenge of Compressing Random Data
http://www.drdobbs.com/architecture-and-design/the-enduring-challenge-of-compressing-ra/240049914

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

Re: Compression of random binary data

[jonas . thornvall]

Den måndag 11 juli 2016 kl. 20:24:37 UTC+2 skrev jonas.t...@gmail.com:
> Den måndag 11 juli 2016 kl. 20:09:39 UTC+2 skrev Waffle:
> > On 11 July 2016 at 20:52,   wrote:
> > > What kind of statistic law or mathematical conjecture  or is it even a 
> > > physical law is violated by compression of random binary data?
> > >
> > > I only know that Shanon theorised it could not be done, but were there 
> > > any proof?
> > 
> > Compression relies on some items in the dataset being more frequent
> > than others, if you have some dataset that is completely random it
> > would be hard to compress as most items have very similar number of
> > occurrances.
> > 
> > > 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.
> > 
> > A square root may be smaller numerically than a number but it
> > definitely is not smaller in terms of entropy.
> > 
> > lets try to compress the number 2 for instance using square roots.
> > sqrt(2) = 1.4142
> > the square root actually takes more space in this case even tho it is
> > a smaller number. so having the square root would have negative
> > compression in this case.
> > with some rounding back and forth we can probably get around the fact
> > that sqrt(2) would take an infinite amout of memory to accurately
> > represent but that neccesarily means restricting the values we are
> > possible of encoding.
> > 
> > for sqrt(2) to not have worse space consumprion than the number 2
> > itself we basically have to trow away precision so sqrt(2) ~= 1
> > now i challenge you to get that 2 back out of that 1..
> 
> Well who it to say different kind of numbers isn't treated differently, i 
> mean all numbers isn't squares. All numbers isn't naturals.

But it could be all numbers are foldable. Both the integer parts and the real 
parts.And be expressed by the folding differences.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Ian Kelly]

On Mon, Jul 11, 2016 at 10:28 AM, Steven D'Aprano  wrote:
> On Tue, 12 Jul 2016 01:04 am, Ian Kelly wrote:
>> Your example showed a 3-digit number being formatted with a requested
>> precision of 5 digits. The way this was done was by left-padding the
>> number with 0s until there were 5 digits,
>
> Right.
>
>> but still only 3 digits of precision.
>
> Er, what? I count *five* digits in "00123", not three.
>
> You seem to be assuming that "precision" can only refer to digits after the
> decimal place, but that's a dubious proposition. That might be the way
> printf interprets the precision for *floats*, but its not the way it
> interprets the precision for *ints*, and who is to say that one way is
> right and the other is wrong?

In what way do the leading zeroes in "00123" add to the precision of
the number? 00123 is the same quantity as 123 and represents no more
precise a measurement. Neither does 000123 for "ten" digits of
precision. We could just keep adding zeroes ad nauseam and then claim
that 123 has infinite precision.

Clearly, that's wrong.

>> 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).

>> It may happen to do what you want in the printf-style format, but
>> calling the field "precision" is at best misleading, and there are
>> other ways to accomplish the same result.
>
> Naturally. So why bother to have .format() or % in the first place? There's
> always other ways to accomplish the same result.

I think it's just a case of purity winning out over practicality. As I
said before, I don't really know why the decision was made to not
support or allow it. What I've written above was my best guess.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Compression of random binary data

[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.




-- 
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: Curious Omission In New-Style Formats

[Terry Reedy]

On 7/11/2016 1:24 PM, Ethan Furman wrote:

On 07/11/2016 09:28 AM, Steven D'Aprano wrote:

On Tue, 12 Jul 2016 01:04 am, Ian Kelly wrote:



Er, what? I count *five* digits in "00123", not three.

You seem to be assuming that "precision" can only refer to digits
after the
decimal place, but that's a dubious proposition.


I will readily admit to not having a maths degree, and so of course to
me saying the integer 123 has a precision of 5, 10, or 99 digits seems
like hogwash to me.


I do have an undergraduate degree in math and a career in statistics, 
and I cannot remember seen 'precision' used in relation to integers.  So 
I would call it a 'non-standard extension' of the notion.



But I'm always willing to learn.  So please explain what 123 with a
precision of five integer digits means,


What it could mean is that we have an count selected from the range 
0 to 9 inclusive.  But what I just said is the usual way of 
saying that, as it does not limit the lower and upper limits to 0s and 9s.



and what to do we gain by saying such a thing?


Confusion.

Precision is usually used in reference to measurement, and while 
measurement is based on counting, it is not the same thing.  If 123 is a 
count, then its precision is 1 count, not k digits.  Or one could say 
that all digits are precise. What is ambiguous without context is 
whether counts with trailing 0s, like 120 or 100 are exact or rounded. 
100, as a cound, could have a precision of 1, 2, or 3 (significant) 
digits.  Context sometimes says things like 'to the nearest hundred 
thousand'.


In any case, I think it an improvement to say that '0x00123' has a field 
width of 7 rather than a 'precision' of 5.


>>> '{:#07x}'.format(0x123)  # specifiy field width
'0x00123'
>>> "%#0.5x" % 0x123  # specify int precision
'0x00123'

Thus, my title for a post noting the same change might be "Upgrade in 
new-style formats".

(format and If one want leading 0s,

--
Terry Jan Reedy

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

Re: Compression of random binary data

[MRAB]

On 2016-07-11 19:30, MRAB wrote:

On 2016-07-11 18:52, 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?

I only know that Shanon theorised it could not be done, but were there any 
proof?

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.

Now the inpretator or program must know the rules. And i have very good rules 
to make it happen.


If you want a challenge:

The Enduring Challenge of Compressing Random Data
http://www.drdobbs.com/architecture-and-design/the-enduring-challenge-of-compressing-ra/240049914

It turns out there's a newsgroup for compression, and they're used to 
getting claims about compressing random data. In fact, so much so that 
it's in their FAQ:


comp.compression Frequently Asked Questions (part 1/3)
Section - [9] Compression of random data (WEB, Gilbert and others)
http://www.faqs.org/faqs/compression-faq/part1/section-8.html

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

Re: Compression of random binary data

[Nobody]

On Mon, 11 Jul 2016 10:52:08 -0700, jonas.thornvall wrote:

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

You can't create an invertable mapping between a set with 2^N elements
(e.g. the set of all N-bit binary sequences) and any set with fewer than
2^N elements (e.g. the set of all M-bit binary sequences for Mhttps://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Ian Kelly]

On Mon, Jul 11, 2016 at 12:54 PM, Terry Reedy  wrote:
> In any case, I think it an improvement to say that '0x00123' has a field
> width of 7 rather than a 'precision' of 5.
>
 '{:#07x}'.format(0x123)  # specifiy field width
> '0x00123'
 "%#0.5x" % 0x123  # specify int precision
> '0x00123'

It occurs to me now that this does create a challenge if the format is
meant to support negative numbers as well:

>>> '%#0.5x' % -0x123
'-0x00123'
>>> '{:#07x}'.format(-0x123)
'-0x0123'
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Compression of random binary data

[Terry Reedy]

On 7/11/2016 2:09 PM, Joonas Liik wrote:

On 11 July 2016 at 20:52,   wrote:

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


Off-topic, but...  It is unclear whether you mean 'random' in the 
technical sense of 'unpredictable' or the common sense that adds 'of 
equal probability'.


Bell engineers discovered that physical communication channels have a 
finite information transmission capacity that could be formalized as 
bits per second.  You should be able to find good articles on the web, 
and I suggest you read some.


If every message could be compressed, than every message could be 
compressed to 0 or 1, which is absurd.



I only know that Shanon [Shannon] theorised it could not be done, but were
there any proof?


Shannon meant random in the technical sense and explicitly considered 
unequal probabilities.  Random bit streams with unequal probabilities 
*can* be compressed by recoding.



Compression relies on some items in the dataset being more frequent
than others,


Perhaps better to say that compression relies on removing redundancy, 
*if there is any*.  The two ideas are related.



if you have some dataset that is completely random it
would be hard to compress as most items have very similar number of
occurrances.


Assuming equal bit probabilities.  Uncorrelated bits of unequal 
probability results in blocks of whatever size having unequal 
probabilites and redundancy that can be removed by replacing blocks with 
coded blocks.  Huffman encoding does this by replacing blocks of equal 
size with code blocks of unequal size, with the size related to the 
probability of the block replaced.


--
Terry Jan Reedy

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

Re: Touch screen development in Python

[Dietmar Schwertberger]

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

Re: Curious Omission In New-Style Formats

[Michael Torrie]

On 07/11/2016 01:27 PM, Ian Kelly wrote:
> On Mon, Jul 11, 2016 at 12:54 PM, Terry Reedy  wrote:
>> In any case, I think it an improvement to say that '0x00123' has a field
>> width of 7 rather than a 'precision' of 5.
>>
> '{:#07x}'.format(0x123)  # specifiy field width
>> '0x00123'
> "%#0.5x" % 0x123  # specify int precision
>> '0x00123'
> 
> It occurs to me now that this does create a challenge if the format is
> meant to support negative numbers as well:
> 
 '%#0.5x' % -0x123
> '-0x00123'
 '{:#07x}'.format(-0x123)
> '-0x0123'

I'm not sure I've ever seen a negative hex number in the wild. Usually
when I view a number in hex I am wanting the raw representation.  -0x123
with a width of 7 would be 0xFFEDD



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

Re: Curious Omission In New-Style Formats

[Random832]

On Mon, Jul 11, 2016, at 16:06, Michael Torrie wrote:
> I'm not sure I've ever seen a negative hex number in the wild. Usually
> when I view a number in hex I am wanting the raw representation.  -0x123
> with a width of 7 would be 0xFFEDD

There's nothing "raw" about python int objects. To get what you want,
you need to do x & 0xf

If you have "5" as a parameter, you can get the desired constant as (1
<< x*4) - 1.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: EuroPython 2016: Last day to get tickets at regular rate

[Moritz Neeb]

Actually this was not your last chance! I am offering one spare regular
rate student ticket (120,-). Please contact me if interested.

Cheers,
Moritz

On 07/07/2016 09:35 AM, M.-A. Lemburg wrote:
> We will be switching to the on-desk rates for tickets tomorrow, so
> today is your last chance to get tickets at the regular rate, which is
> about 30% less than the on-desk rate:
> 
> 
>EuroPython 2016 Registration
> 
> *** https://ep2016.europython.eu/registration/ ***
> 
> 
> 
> Day Passes
> --
> 
> As in the past, we will also sell day passes at the conference venue.
> 
> To make things more affordable especially for students and other
> people who want to attend the Beginners’ Day or the sprints, we have
> split the day pass prices into ones valid from Monday-Friday for the
> main conference days and ones for the weekend days.
> 
> Day passes for the first Sunday (Beginners’ Day) and the sprints
> weekend (valid for the day when they are purchased):
> 
>  * Student weekend day pass: EUR 25.00
>  * Personal weekend day pass: EUR 70.00
>  * Business weekend day pass: EUR 110.00
> 
> Day passes for the main conference (valid for the day when they are
> purchased):
> 
>  * Student conference day pass: EUR 50.00
>  * Personal conference day pass: EUR 140.00
>  * Business conference day pass: EUR 225.00
> 
> All prices include 10% Spanish VAT. Please see the registration page
> for full details of what is included in the ticket price.
> 
> 
> With gravitational regards,
> --
> EuroPython 2016 Team
> http://ep2016.europython.eu/
> http://www.europython-society.org/
> 
> 
> PS: Please forward or retweet to help us reach all interested parties:
> https://twitter.com/europython/status/750955219975016448
> Thanks.
> 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Terry Reedy]

On 7/11/2016 3:27 PM, Ian Kelly wrote:

On Mon, Jul 11, 2016 at 12:54 PM, Terry Reedy  wrote:

In any case, I think it an improvement to say that '0x00123' has a field
width of 7 rather than a 'precision' of 5.


'{:#07x}'.format(0x123)  # specifiy field width

'0x00123'

"%#0.5x" % 0x123  # specify int precision

'0x00123'


It occurs to me now that this does create a challenge if the format is
meant to support negative numbers as well:


'%#0.5x' % -0x123

'-0x00123'


This expands the field from 7 to 8 chars.  In running text, this is 
alright.  In formatted table columns, it is not.



'{:#07x}'.format(-0x123)

'-0x0123'


Multiple alternatives

>>> '{: #08x} {: #08x}'.format(0x123, -0x123)
' 0x00123 -0x00123'
>>> '{:+#08x} {:+#08x}'.format(0x123, -0x123)
'+0x00123 -0x00123'
>>> '{0:#0{1}x} {2:+#0{3}x}'.format(0x123, 7, -0x123, 8)
'0x00123 -0x00123'
>>> n1, n2, w = 0x123, -0x123, 7
>>> '{0:#0{1}x} {2:+#0{3}x}'.format(n1, w+(n1<0), n2, w+(n2<0))
'0x00123 -0x00123'

In running text, I ight go with '+','-' prefix.

--
Terry Jan Reedy

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

What is precision of a number representation? (was: Curious Omission In New-Style Formats)

[Ben Finney]

Ethan Furman  writes:

> I will readily admit to not having a maths degree, and so of course to
> me saying the integer 123 has a precision of 5, 10, or 99 digits seems
> like hogwash to me.

Precision is not a property of the number. It is a property of the
*representation* of that number.

The representation “1×10²” has a precision of one digit.
The representation “100” has a precision of three digits.
The representation “00100” has a precision of five digits.
The representation “100.00” also has a precision of five digits.

Those can all represent the same number; or maybe some of them represent
“one hundred” and others represent “one hundred and a millionth”.

The representation is only an approximation of the actual number, and
the precision tells us how fuzzy the approximation is.

None of these say how *accurate* the representation is; if those are
representations of the number “seven thousand” they are not very
accurate, while they might be passably accurate for the number “one
hundred and seventy”.

> But I'm always willing to learn.  So please explain what 123 with a
> precision of five integer digits means, and what to do we gain by
> saying such a thing?

We gain clarity of speech: we distinguish the different aspects (how
many digits of this representation are actually claimed to represent the
number?) communicated by a representation.

-- 
 \“… no testimony can be admitted which is contrary to reason; |
  `\   reason is founded on the evidence of our senses.” —Percy Bysshe |
_o__)Shelley, _The Necessity of Atheism_, 1811 |
Ben Finney

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

Re: What is precision of a number representation?

[Ethan Furman]

On 07/11/2016 01:56 PM, Ben Finney wrote:


Precision is not a property of the number. It is a property of the
*representation* of that number.

The representation “1×10²” has a precision of one digit.
The representation “100” has a precision of three digits.
The representation “00100” has a precision of five digits.
The representation “100.00” also has a precision of five digits.


Your first, second, and fourth example have zeroes to the right, and I 
understand them just fine.


Your third example has zeroes to the left, and you haven't explained how 
00100 is more precise than 100.  I mean, if somebody told me that one 
hundred was closer to one hundred than it was to ten thousand I would 
have to say "D'oh!"



We gain clarity of speech: we distinguish the different aspects (how
many digits of this representation are actually claimed to represent the
number?) communicated by a representation.


Nope, still not clear to me.  :(

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

Re: Touch screen development in Python

[Laurent Pointal]

Jahn wrote:

> Hi ,
> Does anyone use Python for  developping  applications that  work with a
> touch screen?

You should take a look at Kivy: https://kivy.org/

A+
L.Pointal.

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

Re: What is precision of a number representation? (was: Curious Omission In New-Style Formats)

[Chris Angelico]

On Tue, Jul 12, 2016 at 6:56 AM, Ben Finney  wrote:
> Precision is not a property of the number. It is a property of the
> *representation* of that number.
>
> The representation “1×10²” has a precision of one digit.
> The representation “100” has a precision of three digits.
> The representation “00100” has a precision of five digits.
> The representation “100.00” also has a precision of five digits.
>
> Those can all represent the same number; or maybe some of them represent
> “one hundred” and others represent “one hundred and a millionth”.
>

Yep. Precision is also a property of a measurement, the same way that
a unit is. If I pace out the length of the main corridor in my house,
I might come up with a result of thirty meters. The number is "30";
the unit is "meters", the precision is two significant digits, and the
accuracy depends on how good I am at pacing distance.

This is why it's important to be able to record precisions of
arbitrary numbers. If I then measure the width of this corridor with a
laser, I could get an extremely precise answer - say, 2,147
millimeters, with a precision of four significant digits, and
excellent accuracy. But if I multiply those numbers together to
establish the floor area of the corridor, the result does NOT have
four significant figures. It would be 64 square meters (not 64.41),
and the accuracy would be pretty low (effectively, the *in*accuracies
of both measurements get combined). But on the other hand, if you want
to know whether your new fridge will fit, you could measure it with
the same laser and come up with a figure of 1,973 mm (four sig fig),
which would mean your clearance is 174mm (four sig fig). How do you
record this? Is it 174.0? 0174? "174 with four significant figures"?

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

Re: What is precision of a number representation?

[Ethan Furman]

On 07/11/2016 02:51 PM, Chris Angelico wrote:

On Tue, Jul 12, 2016 at 6:56 AM, Ben Finney wrote:



Precision is not a property of the number. It is a property of the
*representation* of that number.

The representation “1×10²” has a precision of one digit.
The representation “100” has a precision of three digits.
The representation “00100” has a precision of five digits.
The representation “100.00” also has a precision of five digits.

Those can all represent the same number; or maybe some of them represent
“one hundred” and others represent “one hundred and a millionth”.



Yep. Precision is also a property of a measurement, the same way that
a unit is. If I pace out the length of the main corridor in my house,
I might come up with a result of thirty meters. The number is "30";
the unit is "meters", the precision is two significant digits, and the
accuracy depends on how good I am at pacing distance.

This is why it's important to be able to record precisions of
arbitrary numbers. If I then measure the width of this corridor with a
laser, I could get an extremely precise answer - say, 2,147
millimeters, with a precision of four significant digits, and
excellent accuracy. But if I multiply those numbers together to
establish the floor area of the corridor, the result does NOT have
four significant figures. It would be 64 square meters (not 64.41),
and the accuracy would be pretty low (effectively, the *in*accuracies
of both measurements get combined). But on the other hand, if you want
to know whether your new fridge will fit, you could measure it with
the same laser and come up with a figure of 1,973 mm (four sig fig),
which would mean your clearance is 174mm (four sig fig). How do you
record this? Is it 174.0? 0174? "174 with four significant figures"?


174.0, because those last tenths of a millimeter could be very 
important, while knowledge that there are no thousands of millimeters is 
already present.


So, so far there is no explanation of why leading zeroes make a number 
more precise.


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

Re: What is precision of a number representation?

[Ethan Furman]

On 07/11/2016 03:17 PM, Ethan Furman wrote:


So, so far there is no explanation of why leading zeroes make a number
more precise.


An example of what I mean:

174 with a precision of 3 tells us that the tenths place could be any of 
0-9, or, put another way, the actual number could be anywhere between 
174.0 to 174.9 (or maybe 173.5 to 174.5).  If we have 174 with four 
digits of precision, then the representation should be 174.0 and it's 
the hundreths we are unsure of.


So my question is: if we write 174 when could the thousands /ever/ be 
anything besides 0?


--
~Ethan~

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

Re: What is precision of a number representation?

[Ben Bacarisse]

Ben Finney  writes:

> Ethan Furman  writes:
>
>> I will readily admit to not having a maths degree, and so of course to
>> me saying the integer 123 has a precision of 5, 10, or 99 digits seems
>> like hogwash to me.
>
> Precision is not a property of the number. It is a property of the
> *representation* of that number.
>
> The representation “1×10²” has a precision of one digit.
> The representation “100” has a precision of three digits.
> The representation “00100” has a precision of five digits.
> The representation “100.00” also has a precision of five digits.

What is your source for the third one?  I've never seen the term used
in this way so I'm curious about how widely it's used.  (I disagree with
the second one, too, but that's an old argument that does not need
resurrecting.)

> Those can all represent the same number; or maybe some of them represent
> “one hundred” and others represent “one hundred and a millionth”.

So 00100 represents the range [99.995, 100.005] just like 100.00?
That's new to me.  It is more than a Python thing?


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

Re: What is precision of a number representation? (was: Curious Omission In New-Style Formats)

[Jan Coombs]

On Tue, 12 Jul 2016 07:51:23 +1000
Chris Angelico  wrote:

[snip]
> 
> Yep. Precision is also a property of a measurement, the same
> way that a unit is. If I pace out the length of the main
> corridor in my house, I might come up with a result of thirty
> meters. The number is "30"; the unit is "meters", the
> precision is two significant digits, and the accuracy depends
> on how good I am at pacing distance.
> 
> This is why it's important to be able to record precisions of
> arbitrary numbers. If I then measure the width of this
> corridor with a laser, I could get an extremely precise answer
> - say, 2,147 millimeters, with a precision of four significant
> digits, and excellent accuracy. But if I multiply those
> numbers together to establish the floor area of the corridor,
> the result does NOT have four significant figures. It would be
> 64 square meters (not 64.41), and the accuracy would be pretty
> low (effectively, the *in*accuracies of both measurements get
> combined). But on the other hand, if you want to know whether
> your new fridge will fit, you could measure it with the same
> laser and come up with a figure of 1,973 mm (four sig fig),
> which would mean your clearance is 174mm (four sig fig). How
> do you record this? Is it 174.0? 0174? "174 with four
> significant figures"?

Thees all look good, but you may get into trouble if you trust a
PC with them!

If the language/PC uses floating point representation then it
will assign a fixed number of bits for the fractional part, and
this will be left aligned in all/most hardware. 

This fraction might be 52 bits long. Your example number has
about 11 bits of precision. The floating point representation
will then have ~40 bits appended which imply a precision
which does not exist. Your program may still know that only 11
bits are significant, but the representation implies that 52
bits are significant, and provides no indication otherwise. 

Good news!:  Unum is an alternate numeric representation that
does indicate the precision of a number [1].  It also resolves
other problems of current float representation.

Bad news?:In doing so unums becomes incompatible with current
hardware floating point engines. 

Jan Coombs
-- 
[1] slides:
http://sites.ieee.org/scv-cs/files/2013/03/Right-SizingPrecision1.pdf
RichReport 54 minute interview:
https://youtu.be/jN9L7TpMxeA

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

Re: Curious Omission In New-Style Formats

[Gregory Ewing]

I seem to remember Guido stating once that a design principle of
the new formatting system was for the part after the colon to
be the same as what you would put in an equivalent %-format,
to make it easy for people to switch between them.

If that principle still stands, then this would seem to be
a bug.

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

Re: Curious Omission In New-Style Formats

[Gregory Ewing]

Ethan Furman wrote:
I will readily admit to not having a maths degree, and so of course to 
me saying the integer 123 has a precision of 5, 10, or 99 digits seems 
like hogwash to me.


Seems to me insisting that the number after the dot be
called "precision" in all cases is imposing a foolish
consistency.

There's a third thing that %-formats use it for as well:
for a string it means the maximum number of characters
to include.

To my way of thinking, the format string just lets you
specify uop to two numbers, the interpratation or wnich
is up to toe format concerned.

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

Re: What is precision of a number representation? (was: Curious Omission In New-Style Formats)

[Chris Angelico]

On Tue, Jul 12, 2016 at 9:14 AM, Jan Coombs
 wrote:
> Thees all look good, but you may get into trouble if you trust a
> PC with them!
>
> If the language/PC uses floating point representation then it
> will assign a fixed number of bits for the fractional part, and
> this will be left aligned in all/most hardware.

PCs don't necessarily use floating point. Just check out Python's own
decimal.Decimal class, or roll your own if you need to.

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

Re: Curious Omission In New-Style Formats

[Ethan Furman]

On 07/11/2016 04:47 PM, Gregory Ewing wrote:

Ethan Furman wrote:



I will readily admit to not having a maths degree, and so of course to
me saying the integer 123 has a precision of 5, 10, or 99 digits seems
like hogwash to me.


Seems to me insisting that the number after the dot be
called "precision" in all cases is imposing a foolish
consistency.


That isn't what I said.


To my way of thinking, the format string just lets you
specify up to two numbers, the interpretation or which
is up to to format concerned.


Agreed.

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

Re: Compression of random binary data

[Michael Selik]

On Mon, Jul 11, 2016, 10:56 AM  wrote:

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

If you get lucky, you might be able to achieve very good compression.

> http://dilbert.com/strip/2001-10-25

Or are you asking about an algorithm that reliably compresses random data
by a fairly constant percent?

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

Re: Curious Omission In New-Style Formats

[Ian Kelly]

On Mon, Jul 11, 2016 at 5:47 PM, Gregory Ewing
 wrote:
> Ethan Furman wrote:
>>
>> I will readily admit to not having a maths degree, and so of course to me
>> saying the integer 123 has a precision of 5, 10, or 99 digits seems like
>> hogwash to me.
>
>
> Seems to me insisting that the number after the dot be
> called "precision" in all cases is imposing a foolish
> consistency.
>
> There's a third thing that %-formats use it for as well:
> for a string it means the maximum number of characters
> to include.
>
> To my way of thinking, the format string just lets you
> specify uop to two numbers, the interpratation or wnich
> is up to toe format concerned.

The builtin types strive for consistency with each other and with
printf-style formats, but ultimately the parsing of the format spec is
entirely at the whim of the __format__ method of the type being
formatted. You could make it a Turing-complete mini-language if you
liked.

py> class Foo:
... def __format__(self, spec):
... return str(eval(spec)(self))
...
py> '{:id}'.format(Foo())
'139869336090384'
py> '{:repr}'.format(Foo())
'<__main__.Foo object at 0x7f35de17b7b8>'
py> '{:lambda x: x == 42}'.format(Foo())
'False'
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What is precision of a number representation?

[Chris Angelico]

On Tue, Jul 12, 2016 at 8:17 AM, Ethan Furman  wrote:
>> This is why it's important to be able to record precisions of
>> arbitrary numbers. If I then measure the width of this corridor with a
>> laser, I could get an extremely precise answer - say, 2,147
>> millimeters, with a precision of four significant digits, and
>> excellent accuracy. But if I multiply those numbers together to
>> establish the floor area of the corridor, the result does NOT have
>> four significant figures. It would be 64 square meters (not 64.41),
>> and the accuracy would be pretty low (effectively, the *in*accuracies
>> of both measurements get combined). But on the other hand, if you want
>> to know whether your new fridge will fit, you could measure it with
>> the same laser and come up with a figure of 1,973 mm (four sig fig),
>> which would mean your clearance is 174mm (four sig fig). How do you
>> record this? Is it 174.0? 0174? "174 with four significant figures"?
>
>
> 174.0, because those last tenths of a millimeter could be very important,
> while knowledge that there are no thousands of millimeters is already
> present.
>

But I never measured it to tenths of a millimeter. The display on my
laser measurer (I don't actually have one, by the way, so all this is
complete fabrication for the sake of the example) displays integer
millimeters, with an implicit "+/- 0.5 mm".

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

Re: Compression of random binary data

[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?
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Veek. M]

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.

I could cat << named_pipe but I was wondering if this was the only way?
Could I juggle fd's instead?


#!/usr/bin/python
# -*- coding: utf-8 -*-

import sys, time

import shlex
import codecs, subprocess

import goslate
from textblob.blob import TextBlob


def cmd_exec(cmd, wait=True, shell=True):
print cmd

cmd_line = shlex.split(cmd)
retobj = subprocess.Popen(cmd_line, shell, cwd='/tmp', 
stdin=subprocess.PIPE)

if wait:
retobj.wait()

return retobj

def get_text_and_process(skip=False):
if skip: return
cmd_exec('import /tmp/x.png')
cmd_exec('convert /tmp/x.png -resize 200% /tmp/x.resize.png')
cmd_exec('tesseract /tmp/x.resize.png /tmp/tao -l chi_sim')


get_text_and_process(skip=True)

fh = codecs.open('/tmp/tao.txt', encoding='utf-8')
fd = cmd_exec('xterm -en utf-8 -geometry 50x20+0+0 -e /bin/bash -c "cat 
-"', shell=False, wait=False)
fd.communicate('test\n') #how do i communicate with cat and not xterm
sys.exit() #I EXIT HERE


#This stuff doesn't run (but works) - sys.exit above
for line in fh.readlines():
try:
print >>fd.stdout, line.encode('utf-8')

blob = TextBlob(line)
print >>fd.stdout, blob.detect_language()
print >>fd.stdin, blob.translate(to='en') 
except UnicodeDecodeError, TranslatorError:
pass

fh.close()
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Steven D'Aprano]

On Tue, 12 Jul 2016 04:38 am, Ian Kelly wrote:

> In what way do the leading zeroes in "00123" add to the precision of
> the number? 00123 is the same quantity as 123 and represents no more
> precise a measurement. 

You guys... next you're going to tell me that 1.23 and 1.2300 are the same
quantity and represent no more precise a measurement :-) And keep adding
zeroes 1.23000... and claim infinite precision.

That's not now "precision" works. Its true that *mathematically* leading
zeroes don't change the number, but neither do trailing zeroes.
Nevertheless, we *interpret* them as having meaning, as indicators of the
precision of measurement in the mathematical sense.

In a moment, I'm going to attempt to justify a reasonable meaning for
leading zeroes. But that's actually not relevant. printf (and Python's %
string operator) interprets the precision field in the mathematical sense
for floats, but that's not the only sense possible. The word "precise" has
a number of meanings, including:

- exactness
- accurate
- strict conformity to a rule
- politeness and nicety
- the quality of being reproducible


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.

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.

Why shouldn't we use the "precision" field for this? It doesn't mean what
scientists mean by precision, but so what? That's not important. Scientists
don't usually have to worry about leading zeroes, but programmers do, and
its useful to distinguish between the *total* width (padded with spaces)
and the *number* width (padded with zeroes).

I think that printf and % get this right, and format() gets it wrong.


[...]
>>> 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.

Converting an integer to a float just to use the precision field is just
wrong. That's like saying that "1234".upper() doesn't make sense because
digits don't have uppercase forms, and if you really want to convert "1234"
to uppercase you should spell it out in words first:

"onetwothreefour".upper()



Earlier, I said that I would attempt to give a justification for leading
zeroes in terms of measurement too. As I said, this is strictly irrelevant,
but I thought it was interesting and so I'm going to share. You can stop
reading now if you prefer.

If you measure something with a metre ruler marked in centimetres, getting
1.23 metres, that's quite different from measuring it with a ruler marked
in tenths of a millimetres and getting 1.2300. That's basic usage for
precision in terms of number of decimal places and I'm sure we all agree
about that.

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. If I lay out
the one metre stick 123 times, then I write the measurement as 123. If I
lay out my 10km ruler and note the position, I measure:

zero tens of kilometres;
zero kilometres;
three hundreds-of-metres;
two tens-of-metres;
three metres;

giving 00123 metres of course. Simple!

Of course, it's rare that we do that. Why would we bother to distinguish the
two situations? And who the hell has a 10km long measuring stick?

If I'm a scientist, I'll probably write them both as 123m and not care about
the size of the measuring stick, only about the smallest marking on it. At
least for measuring straight-line distances, the size of the measuring
stick generally doesn't matter.

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 

Re: What is precision of a number representation?

[Ben Finney]

Ethan Furman  writes:

> On 07/11/2016 01:56 PM, Ben Finney wrote:
>
> > Precision is not a property of the number. It is a property of the
> > *representation* of that number.
> >
> > The representation “1×10²” has a precision of one digit.
> > The representation “100” has a precision of three digits.
> > The representation “00100” has a precision of five digits.
> > The representation “100.00” also has a precision of five digits.
>
> […] you haven't explained how 00100 is more precise than 100.

I haven't made any claim about “more precise” in the above.

But if you want such claims, here are comparable representations in
increasing order of precision:

* “0 ×10²” has one digit of precision.
* “0.0 ×10²” has two digits of precison.
* “0.01 ×10²” has three digits of precision.
* “0.010 ×10²” has four digits of precision.
* “0.0100 ×10²” has five digits of precision.
* “0.01000 ×10²” has six digits of precision.

Again, these might all be representations of the same number or of
different numbers; the representation claims only to represent a number
within a range of tolerance.


In decimal notation, some of the above can't be written with the same
precision. I could invent a representation — e.g. show “?” as a
place-holder for a digit not within the precision level. In that system,
the equivalent representations would be:

* “0”
* “00???”
* “001??”
* “0010?”
* “00100”
* “00100.0”

Each of these claims to represent a quantity beginning at the
ten-thousands place, with increasing levels of precision in the claim.

So the comparison that invites is to show where the range of tolerance
for the representation ends. The fewer digits of precision, the less
precise the representation claims to be.

-- 
 \  “I find the whole business of religion profoundly interesting. |
  `\ But it does mystify me that otherwise intelligent people take |
_o__)it seriously.” —Douglas Adams |
Ben Finney

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

Re: What is precision of a number representation?

[Terry Reedy]

On 7/11/2016 5:51 PM, Chris Angelico wrote:


This is why it's important to be able to record precisions of
arbitrary numbers. If I then measure the width of this corridor with a
laser, I could get an extremely precise answer - say, 2,147
millimeters, with a precision of four significant digits, and
excellent accuracy. But if I multiply those numbers together to
establish the floor area of the corridor, the result does NOT have
four significant figures. It would be 64 square meters (not 64.41),
and the accuracy would be pretty low (effectively, the *in*accuracies
of both measurements get combined). But on the other hand, if you want
to know whether your new fridge will fit, you could measure it with
the same laser and come up with a figure of 1,973 mm (four sig fig),
which would mean your clearance is 174mm (four sig fig).


Wrong as to the last point. 2147 - 1973 = 174 has only 3 sig. figures. 
2147 - 2144 = 3 has 1 significant figure.  Subtraction of nearly equal 
numbers can cancel sig. figures.


> How do you

record this? Is it 174.0? 0174? "174 with four significant figures"?


None of these.

--
Terry Jan Reedy

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

Re: What is precision of a number representation?

[Terry Reedy]

On 7/11/2016 6:17 PM, Ethan Furman wrote:

On 07/11/2016 02:51 PM, Chris Angelico wrote:



This is why it's important to be able to record precisions of
arbitrary numbers. If I then measure the width of this corridor with a
laser, I could get an extremely precise answer - say, 2,147
millimeters, with a precision of four significant digits, and
excellent accuracy. But if I multiply those numbers together to
establish the floor area of the corridor, the result does NOT have
four significant figures. It would be 64 square meters (not 64.41),
and the accuracy would be pretty low (effectively, the *in*accuracies
of both measurements get combined). But on the other hand, if you want
to know whether your new fridge will fit, you could measure it with
the same laser and come up with a figure of 1,973 mm (four sig fig),
which would mean your clearance is 174mm (four sig fig). How do you
record this? Is it 174.0? 0174? "174 with four significant figures"?


174.0,


A common fallacy.  There are only 3 significant figures because one, the 
first, was cancelled by subtracting close numbers.  The same is true of 
adding numbers of opposite signs.


--
Terry Jan Reedy

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

Re: What is precision of a number representation? (was: Curious Omission In New-Style Formats)

[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.



-- 
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: Touch screen development in Python

[Paul Rubin]

"Jahn"  writes:
> Does anyone use Python for developping applications that work with a
> touch screen?

I've done it on a system where the touch screen events were treated the
same way as mouse events.  Coding works out about the same way.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What is precision of a number representation? (was: Curious Omission In New-Style Formats)

[Chris Angelico]

On Tue, Jul 12, 2016 at 2:19 PM, Steven D'Aprano  wrote:
> 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.

Exactly my point. Granted, I mucked up my example (subtraction doesn't
maintain sig figs - apologies, my bad), but there are other ways to
end up with numbers close to zero with more sig figs than nonzero
digits.

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

[RELEASE] Python 3.6.0a3 is now available

[Ned Deily]

On behalf of the Python development community and the Python 3.6 release
team, I'm happy to announce the availability of Python 3.6.0a3.
3.6.0a3 is the third of four planned alpha releases of Python 3.6,
the next major release of Python.  During the alpha phase, Python 3.6
remains under heavy development: additional features will be added
and existing features may be modified or deleted.  Please keep in mind
that this is a preview release and its use is not recommended for
production environments.

You can find Python 3.6.0a3 here:

https://www.python.org/downloads/release/python-360a3/ 

The next release of Python 3.6 will be 3.6.0a4, currently scheduled for
2016-08-15.

--Ned

--
  Ned Deily
  n...@python.org -- []

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

Re: What is precision of a number representation?

[Steven D'Aprano]

On Tuesday 12 July 2016 08:17, Ethan Furman wrote:

> So, so far there is no explanation of why leading zeroes make a number
> more precise.


Obviously it doesn't, just as trailing zeroes doesn't make a number more 
precise. Precision in the sense used by scientists is a property of how the 
measurement was done, not of the number itself. We can arbitrarily add zeroes 
to the end of 0.5 until the cows come home, and its still just a half, no more, 
no less.

But scientists have a useful convention that you can indicate the measurement 
precision by showing trailing zeroes:

0.5 is short-hand for 0.5 ± 0.05;

0.50 is short-hand for 0.5 ± 0.005;

0.5000 is short-hand for 0.5 ± 0.5;


etc. That's just a convention, although its a useful one. But its not the only 
useful convention:

01 is a byte with value 1;

0001 is a double-byte quantity (short int?) with value 1;

0001 is a 32-bit quantity with value 1;

etc. We say that these examples differ in their "number of digits" instead of 
"number of decimal places", so the difference doesn't quite map to the 
scientist's meaning of the word "precision". But why should we let that stop us 
from using the "precision" field of a format string to represent number of 
digits?

If not, then what are the alternatives? Using str.format, how would you get the 
same output as this?


py> "%8.4d" % 25
'0025'



-- 
Steve

-- 
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

[Steven D'Aprano]

On Tuesday 12 July 2016 16:27, 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
> 


Oopsm, accidentally doubled the URL.

http://porkmail.org/era/unix/award.html

-- 
Steve
-- 
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

[Steven D'Aprano]

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

-- 
Steve

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