Re: can't add variables to instances of built-in classes

[Peter Otten]

Lawrence D’Oliveiro wrote:

> On Monday, July 18, 2016 at 3:04:13 AM UTC+12, Steven D'Aprano wrote:
> 
>> __slots__ is not obsolete, but 99% of the time you shouldn't bother with
>> it.
> 
> I find __slots__ very useful. I have them right through my Qahirah classes
> , for example.

When you remove them, does your library stop working? Is there a significant 
increase of memory consumption? Or is there something I didn't think of that 
makes them useful for you?

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

Re: Python code change

[alister]

On Sun, 17 Jul 2016 12:00:58 -0700, tsanchez117.ts wrote:

> Im trying to run a Python application but im stuck on a problem. The
> application requires a log in and password to run the application. The
> only problem that I'm having is that the code was written to connect to
> a data base and from there it sees the username and password that is
> linked to the data base. The file application was in .pyc, I already
> uncompyled to py.  I was wondering if there is any way that I can change
> the code to where the log in and username are in the code and not in the
> database with the same outcome of course. I can send you the code if
> that'll be helpful? Thank you.

talk to the system administrator

if you are authorised to have this information they will be able to 
provide it



-- 
"The combination of a number of things to make existence 
worthwhile."
"Yes, the philosophy of 'none,' meaning 'all.'"
-- Spock and Lincoln, "The Savage Curtain", stardate 
5906.4
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What exactly is "exact" (was Clean Singleton Docstrings)

[Steven D'Aprano]

On Monday 18 July 2016 14:16, Rustom Mody wrote:

> On Saturday, July 16, 2016 at 3:16:48 PM UTC+5:30, Steven D'Aprano wrote:

>> But that's *wrong*. Numbers are never inexact. (You can have interval
>> arithmetic using "fuzzy numbers", but they're ALWAYS inexact.) It is
>> calculations which are exact or inexact, not numbers. There's no a priori
>> reason to expect that 0.49 is "inexact" while 0.5 is "exact", you need
>> to know the calculation that generated it:
> 
> Heh! Did you check what scheme has to say about this before holding forth?
> I suggest a tool called google. It can make one seem profound

Emphasis on the "seem" rather than "actually be" *wink*


> Here are the first couple of hits it gives (me) for “scheme exact number”
[...]
> | The motivation for this behavior is that the inexactness of a number
> | should not be lost silently. 

I appreciate the motivation, but I don't think the Scheme, er, scheme is well-
thought out or meaningful. "Exact" or "inexact" is too blunt an instrument to 
be of much use. If you do a bunch of calculations, and get a result of 1.0, all 
that tells you is that the "true" (i.e. infinitely precise) value is something 
possibly centered at 1 with an unknown, not necessarily small, error.

So now you know that *at least one* calculation was inexact, but not which 
ones, or the magnitude of the errors introduced.

The Scheme system is effectively the same as a really poor interval arithmetic 
system, where numbers can be recorded in two forms:

x ± 0  # exact
x ± ∞  # inexact

and nothing in between.


> AIUI…
> There are two almost completely unrelated notions of exact
> 
> 1. ⅓ in decimal cannot be exactly represented though 0.3 0.33 etc are
> approximations.
>We could call these inexact forms of ⅓

But 0.3 is an exact representation of 3/10, 0.1 + 0.2, 0.6/2, etc.


> 2. Measurement and observation produces numbers.  These are inexact
> inherently.
> 
> Scheme's notion of exact is towards capturing the second notion.

I don't see anything in the Guile documentation you linked to which supports 
that interpretation.


> According to which
> “There were 20,000 people in the stadium” would be an inexact integer
> [Yeah note Inexact INTEGER]

Without a bound on the error ("between 0 and 7 billion people, but probably 
20,000") that's of very little use.


> whereas
> √2, e, π are all exact.  Just that they dont have finite decimal/continued
> fraction and of course float representations.

There are computer algebra systems capable of treating irrationals like √2, e 
and π as exact numbers, but I'm pretty sure Guile is not one of them.


> In short one could think of inexact and exact — in scheme's intended
> semantics — as better called scientific (or science-ic) and mathematic
> numbers.

I don't think so. "Science" uses both experimentally-derived numbers (e.g. G, 
c, the mass of the electron) and numbers known exactly (√2, e, π).

I think one could better think of Scheme's semantics as a poorly-thought out 
hybrid between traditional numerics and a vague approximation to interval 
arithmetic.



-- 
Steve

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

Re: What exactly is "exact" (was Clean Singleton Docstrings)

[Marko Rauhamaa]

Steven D'Aprano :

> I think one could better think of Scheme's semantics as a
> poorly-thought out hybrid between traditional numerics and a vague
> approximation to interval arithmetic.

Python programmers (among others) frequently run into issues with
surprising results in floating-point arithmetics. For better or worse,
Scheme has tried to abstract the concept. You don't need to explain the
ideas of IEEE 64-bit floating-point numbers or tie the hands of the
implementation. Instead, what you have is "reliable" arithmetics and
"best-effort" arithmetics, a bit like TCP is "reliable" and UDP is
"best-effort".

"Inexact" means there's a possibility of rounding errors. "Exact" means
no rounding errors were introduced by the limitations of the hardware or
the algorithms. How inexact the inexact results is a complicated topic
for numeric programming.


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

Re: What exactly is "exact" (was Clean Singleton Docstrings)

[Rustom Mody]

On Monday, July 18, 2016 at 2:59:56 PM UTC+5:30, Steven D'Aprano wrote:
> On Monday 18 July 2016 14:16, Rustom Mody wrote:

> > AIUI…
> > There are two almost completely unrelated notions of exact
> > 
> > 1. ⅓ in decimal cannot be exactly represented though 0.3 0.33 etc are
> > approximations.
> >We could call these inexact forms of ⅓
> 
> But 0.3 is an exact representation of 3/10, 0.1 + 0.2, 0.6/2, etc.
> 
> 
> > 2. Measurement and observation produces numbers.  These are inexact
> > inherently.
> > 
> > Scheme's notion of exact is towards capturing the second notion.
> 
> I don't see anything in the Guile documentation you linked to which supports 
> that interpretation.

Exact example :: index operations into data structures may need to know the 
index exactly, as may some operations on polynomial coefficients in a symbolic 
algebra system.
Inexact example :: the results of measurements are inherently inexact, and 
irrational numbers may be approximated by rational and therefore inexact 
approximations.

[from the Scheme standard http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-6.html ]

I believe the two clauses:
- measurements inherently inexact
- rational approximations to irrationals

The first represents the basic intention
The second represents the fact that pragmatically we are stuck with things like
floating point as the same chapter indicates at start:


|| This chapter describes Scheme's model for numbers. It is important to
|| distinguish between the mathematical numbers, the Scheme objects that
|| attempt to model them, the machine representations used to implement
|| the numbers, and notations used to write numbers. In this report, the
|| term number refers to a mathematical number, and the term number
|| object refers to a Scheme object representing a number. This report
|| uses the types complex, real, rational, and integer to refer to both
|| mathematical numbers and number objects. The fixnum and flonum types
|| refer to special subsets of the number objects, as determined by
|| common machine representations, as explained below.
||  
||  Numbers may be arranged into a tower of subsets in which each level is a 
subset of the level above it:
||  
|| number
|| complex
|| real
|| rational
|| integer
||  
|| For example, 5 is an integer. Therefore 5 is also a rational, a real,
|| and a complex. The same is true of the number objects that model 5.
||  
|| There is no simple relationship between the subset that contains a
|| number and its representation inside a computer. For example, the
|| integer 5 may have several represen || operations treat number objects as 
abstract data, as independent of
|| their representation as possible. Although an implementation of Scheme
|| may use many different representations for numbers, this should not be
|| apparent to a casual programmer writing simple programs.

Whether scheme achieves all these laudable and lofty goals of
representation independence, genuine mathematical subsetting (unlike
the usual programming story where float and int are disjoint) etc,
I will along with Marko say: “Cant say if it has turned out practicable”

Practicability has of course many variables
floating point h/w induces floating point languages perpetuates the h/w
perpetuates the languages… etc

Are viable alternatives possible?? Dunno…
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What exactly is "exact" (was Clean Singleton Docstrings)

[Chris Angelico]

On Mon, Jul 18, 2016 at 8:00 PM, Marko Rauhamaa  wrote:
> Python programmers (among others) frequently run into issues with
> surprising results in floating-point arithmetics. For better or worse,
> Scheme has tried to abstract the concept. You don't need to explain the
> ideas of IEEE 64-bit floating-point numbers or tie the hands of the
> implementation. Instead, what you have is "reliable" arithmetics and
> "best-effort" arithmetics, a bit like TCP is "reliable" and UDP is
> "best-effort".

The problem with that is that failing to explain IEEE floating point
and just calling it "inexact" scares people off unnecessarily. I've
seen a lot of very intelligent people who think that you should never
compare floats with the == operator, because floats randomly introduce
"inaccuracy". And then you get these sorts of functions:

EPSILON = 0.01 # Adjust to control numeric accuracy
def is_equal(f1, f2, epsilon=EPSILON):
if abs(f1) > abs(f2):
f1, f2 = f2, f1
return abs(f2-f1) < f1*epsilon

and interminable debates about how to pick an epsilon, whether it
should be relative to the smaller value (as here) or the larger (use
f2 instead), or maybe should be an absolute value, or maybe it should
be relative to the largest/smallest value that was ever involved in
the calculation, or

Floating point numbers are a representation of real numbers that
involves a certain amount of precision. They're ultimately no
different from grade-school arithmetic where you round stuff off so
you don't need an infinite amount of paper, except that they work with
binary rather than decimal, so people think "0.1 + 0.2 ought to be
exactly 0.3, why isn't it??", and blame floats.

Explain what they REALLY do and how they work, and you'll find they're
not so scary.

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

Re: What exactly is "exact" (was Clean Singleton Docstrings)

[Rustom Mody]

On Monday, July 18, 2016 at 3:45:26 PM UTC+5:30, Chris Angelico wrote:
> On Mon, Jul 18, 2016 at 8:00 PM, Marko Rauhamaa  wrote:
> > Python programmers (among others) frequently run into issues with
> > surprising results in floating-point arithmetics. For better or worse,
> > Scheme has tried to abstract the concept. You don't need to explain the
> > ideas of IEEE 64-bit floating-point numbers or tie the hands of the
> > implementation. Instead, what you have is "reliable" arithmetics and
> > "best-effort" arithmetics, a bit like TCP is "reliable" and UDP is
> > "best-effort".
> 
> The problem with that is that failing to explain IEEE floating point
> and just calling it "inexact" scares people off unnecessarily. I've
> seen a lot of very intelligent people who think that you should never
> compare floats with the == operator, because floats randomly introduce
> "inaccuracy". And then you get these sorts of functions:
> 
> EPSILON = 0.01 # Adjust to control numeric accuracy
> def is_equal(f1, f2, epsilon=EPSILON):
> if abs(f1) > abs(f2):
> f1, f2 = f2, f1
> return abs(f2-f1) < f1*epsilon
> 
> and interminable debates about how to pick an epsilon, whether it
> should be relative to the smaller value (as here) or the larger (use
> f2 instead), or maybe should be an absolute value, or maybe it should
> be relative to the largest/smallest value that was ever involved in
> the calculation, or
> 

I dont know what point you are trying to make
Here is behavior.  Should one use == ??

Python 2.7.11+ (default, Apr 17 2016, 14:00:29) 
[GCC 5.3.1 20160413] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> .1+.1+.1 == .3
False

EPSILON = 0.01 # Adjust to control numeric accuracy
def is_equal(f1, f2, epsilon=EPSILON):
if abs(f1) > abs(f2):
f1, f2 = f2, f1
return abs(f2-f1) < f1*epsilon 
>>> ... ... ... ... 

>>> is_equal(.1+.1+.1, .3)
True
>>> 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What exactly is "exact" (was Clean Singleton Docstrings)

[Chris Angelico]

On Mon, Jul 18, 2016 at 8:24 PM, Rustom Mody  wrote:
> I dont know what point you are trying to make
> Here is behavior.  Should one use == ??
>
> Python 2.7.11+ (default, Apr 17 2016, 14:00:29)
> [GCC 5.3.1 20160413] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
 .1+.1+.1 == .3
> False
>
> EPSILON = 0.01 # Adjust to control numeric accuracy
> def is_equal(f1, f2, epsilon=EPSILON):
> if abs(f1) > abs(f2):
> f1, f2 = f2, f1
> return abs(f2-f1) < f1*epsilon
 ... ... ... ...
>
 is_equal(.1+.1+.1, .3)
> True


Sure, simple equality hasn't given you an "intuitive" result - but
that's because your source code is in decimal. So you need to properly
understand it. If you work with something that can be represented
precisely in binary, you have no problems with equality:

>>> 7/4 + 9/4 + 11/4 + 13/4 == 10
True

It's only the repeating values that have that problem. And if you
disassemble your example, it's obvious why you get False:

>>> dis.dis(lambda: .1+.1+.1 == .3)
  1   0 LOAD_CONST   4 (0.30004)
  2 LOAD_CONST   2 (0.3)
  4 COMPARE_OP   2 (==)
  6 RETURN_VALUE

Of course those two values aren't the same. And it'd be just as
obvious if you looked at them in binary. It'd look like this in
decimal:

0.6667 + 0.6667 + 0.6667 == 2.0

Well, duh, all those intermediate values are rounded up, so you're
getting the sum of the rounding, and of course it's not equal. That's
why you need to get some comprehension of floating-point and how it
*really* functions.

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

Re: What exactly is "exact" (was Clean Singleton Docstrings)

[Marko Rauhamaa]

Chris Angelico :
> you don't need an infinite amount of paper, except that they work with
> binary rather than decimal, so people think "0.1 + 0.2 ought to be
> exactly 0.3, why isn't it??", and blame floats.

Oh, if we only had eight fingers on our hand...

Scheme, though doesn't force the implementation to use binary. It could
use trinary or sexagesimal for all Scheme cares. The application
shouldn't care, either.


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

Re: What exactly is "exact" (was Clean Singleton Docstrings)

[Peter Otten]

Marko Rauhamaa wrote:

> Chris Angelico :
>> you don't need an infinite amount of paper, except that they work with
>> binary rather than decimal, so people think "0.1 + 0.2 ought to be
>> exactly 0.3, why isn't it??", and blame floats.
> 
> Oh, if we only had eight fingers on our hand...

We already have one nibble and a carry bit, and it didn't help...

> 
> Scheme, though doesn't force the implementation to use binary. It could
> use trinary or sexagesimal for all Scheme cares. The application
> shouldn't care, either.
> 
> 
> Marko


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

Re: can't add variables to instances of built-in classes

[Ethan Furman]

On 07/17/2016 04:50 AM, Wilson Ong wrote:


Use this feature sparingly, only when you know that there are going to be
many (millions rather than thousands) of Test instances.


Why use it sparingly? Is it for extensibility? What if I'm pretty sure that
 my class is going to have exactly these attributes only?


One of the very nice things about Python is being able to fiddle with objects, 
both
for debugging and for extending.  One of the ways that's accomplished is by 
adding
attributes to instances, but when __slots__ is defined that ability is lost, 
which
can make using/debugging those types of objects harder.

__slots__ is a memory optimization, and like most optimazations you shouldn't 
use
it until you know you need it.

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

Re: What exactly is "exact" (was Clean Singleton Docstrings)

[Random832]

On Mon, Jul 18, 2016, at 00:46, Ben Finney wrote:
> What is “those”? The measurement is imprecise, the observations are
> inexact.
> 
> It makes no sense to say that a number is inexact. Exactness is not a
> property of a number.

There's no reason it shouldn't be a property of an object of a numeric
type available in a programming environment though.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What exactly is "exact" (was Clean Singleton Docstrings)

[Random832]

On Mon, Jul 18, 2016, at 01:37, Rustom Mody wrote:
> The INTENTION is that in addition to capturing the usual number tower
> ℕ ⊂ ℤ ⊂ ℝ (or parts therefore)

Well, ℚ. You hardly ever see representations of numbers that are in ℝ-ℚ.

> scheme also captures ORTHOGONALLY (word in the docs) the (in)exactness
> attribute
>
> In the realization, the designers need to (over)load these different
> attributes onto numeric constants. So the ruse chosen is that fraction-
> constants by default are exact Decimal constants are inexact And one
> can override any of these by suitable a function [At least that's my
> understanding]

The other thing you're missing is that implementations are free to
choose any representation they want (such as an IEEE binary float, or a
rational of bounded denominator) for inexact numbers, no matter how they
were written, because they're not required to preserve the exact value.
The fact that an implementation *could* also use an IEEE binary float to
represent an exact rational number whose denominator happens to be power
of two is immaterial to this discussion.

It's not required to actually be "orthogonal" in the sense that you're
imagining - i.e. being able to have inexact numbers whose machine
representations are big integers, big rationals, etc. An implementation
could choose to represent *all* inexact numbers as floats.
-- 
https://mail.python.org/mailman/listinfo/python-list

COM Server - COMTYPES / PYTHONCOM

[Kasper Jepsen]

Hello all,

I have some major problems with something i am not good at :(

I have come to a situation where i have to add a COM server in my python code 
the get access to it from Labview Teststand.

Firs i have tried with pythoncom/wincom and got it almost working, it 
registered and i could look it up in the windows COM data list.
But this combination do not register coclasses:
Coclasses are not registered (that is, RegisterTypeLib does not write any 
values to the CLSID key of the coclass).
http://docs.activestate.com/activepython/2.6/pywin32/pythoncom__RegisterTypeLib_meth.html

IDL File:
http://pastebin.com/WGCMmzHv

And here the code:
http://pastebin.com/44t45tPj

my reference: 
https://chromium.googlesource.com/chromium/deps/python_26/+/cd4a3da8f0f0806bec98a40d80484f2362908250/Lib/site-packages/win32com/test/pippo_server.py
-

Then i started by using COMTYPES, but this do not at all register into the COM 
catalog on windows - both solutions i can connect to from another python.

here is my code - IDL is the same.
http://pastebin.com/ke5V5ZbY

How do i continue so i can use this server from Teststand or any other windows 
program??

I really hope some can give me an example or help me in what is wrong - i think 
it is quite close...

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

Re: What exactly is "exact" (was Clean Singleton Docstrings)

[Ian Kelly]

On Mon, Jul 18, 2016 at 3:29 AM, Steven D'Aprano
 wrote:
> On Monday 18 July 2016 14:16, Rustom Mody wrote:
>> In short one could think of inexact and exact — in scheme's intended
>> semantics — as better called scientific (or science-ic) and mathematic
>> numbers.
>
> I don't think so. "Science" uses both experimentally-derived numbers (e.g. G,
> c, the mass of the electron) and numbers known exactly (√2, e, π).

Off-topic, c being a fundamental constant is actually in the latter
category. Its *exact* value is 299792458 m/s.

The length of the meter, on the other hand, is defined as the distance
traveled by light in a vacuum in 1/299792458 seconds and is subject to
the precision of measurements.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What exactly is "exact" (was Clean Singleton Docstrings)

[Marko Rauhamaa]

Ian Kelly :

> Off-topic, c being a fundamental constant is actually in the latter
> category. Its *exact* value is 299792458 m/s.
>
> The length of the meter, on the other hand, is defined as the distance
> traveled by light in a vacuum in 1/299792458 seconds and is subject to
> the precision of measurements.

Since both c and the second are exact magnitudes, so is the meter.

   The second [...] is quantitatively defined in terms of exactly
   9,192,631,770 periods of a certain frequency of radiation from the
   caesium atom: a so-called atomic clock.
   https://en.wikipedia.org/wiki/Second>


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

Re: What exactly is "exact" (was Clean Singleton Docstrings)

[Marko Rauhamaa]

Marko Rauhamaa :

> Ian Kelly :
>> Off-topic, c being a fundamental constant is actually in the latter
>> category. Its *exact* value is 299792458 m/s.
>>
>> The length of the meter, on the other hand, is defined as the distance
>> traveled by light in a vacuum in 1/299792458 seconds and is subject to
>> the precision of measurements.
>
> Since both c and the second are exact magnitudes, so is the meter.
>
>The second [...] is quantitatively defined in terms of exactly
>9,192,631,770 periods of a certain frequency of radiation from the
>caesium atom: a so-called atomic clock.
>https://en.wikipedia.org/wiki/Second>

Which would became immediately apparent if you programmed in Scheme. One
meter is equal to the wavelength of said magnitude times:

   9192631770/299792458
   ==> 656616555/21413747
   (exact? 9192631770/299792458)
   ==> #t


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

Re: What exactly is "exact" (was Clean Singleton Docstrings)

[Ian Kelly]

On Mon, Jul 18, 2016 at 9:55 AM, Marko Rauhamaa  wrote:
> Marko Rauhamaa :
>
>> Ian Kelly :
>>> Off-topic, c being a fundamental constant is actually in the latter
>>> category. Its *exact* value is 299792458 m/s.
>>>
>>> The length of the meter, on the other hand, is defined as the distance
>>> traveled by light in a vacuum in 1/299792458 seconds and is subject to
>>> the precision of measurements.
>>
>> Since both c and the second are exact magnitudes, so is the meter.
>>
>>The second [...] is quantitatively defined in terms of exactly
>>9,192,631,770 periods of a certain frequency of radiation from the
>>caesium atom: a so-called atomic clock.
>>https://en.wikipedia.org/wiki/Second>
>
> Which would became immediately apparent if you programmed in Scheme. One
> meter is equal to the wavelength of said magnitude times:

Okay, so how is that wavelength defined?

If you needed to mark a meter stick, and all you had was the
definition of c and the second, how would you do it without measuring
anything?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What exactly is "exact" (was Clean Singleton Docstrings)

[Marko Rauhamaa]

Ian Kelly :

> Okay, so how is that wavelength defined?
>
> If you needed to mark a meter stick, and all you had was the
> definition of c and the second, how would you do it without measuring
> anything?

I wouldn't be measuring a meter stick. To measure, say, the height of a
desk, I would bring in some caesium and shine its radiation from the
desk level down to the floor. By counting the ebbs and flows of the
radiation as it leaves the nozzle and strikes the wooden floor I make
the approximage height measurement.

However, I know *exactly* how long a meter is without making a
measurement.


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

Re: Request for help

[Eric kago]

Hi Pythoners

I need help in understanding hoe to put up the code to the following command


   - Create a constructor that takes in an integer and assigns this to a
   `balance` property




Regards,

Eric Kago
+254(0)714249373
Nairobi
Kenya
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Request for help

[alister]

On Mon, 18 Jul 2016 12:50:04 +0300, Eric kago wrote:

> Hi Pythoners
> 
> I need help in understanding hoe to put up the code to the following
> command
> 
> 
>- Create a constructor that takes in an integer and assigns this to a
>`balance` property
> 
> 
> 
> 
> Regards,
> 
> Eric Kago +254(0)714249373 Nairobi Kenya

I suggest next time you stay awake during lessons.




-- 
I treasure this strange combination found in very few persons: a fierce
desire for life as well as a lucid perception of the ultimate futility of
the quest.
-- Madeleine Gobeil
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: can't add variables to instances of built-in classes

[Lawrence D’Oliveiro]

On Monday, July 18, 2016 at 7:39:09 PM UTC+12, Peter Otten wrote:
> Lawrence D’Oliveiro wrote:
> 
>> I find __slots__ very useful. I have them right through my Qahirah classes
>> , for example.
> 
> Or is there something I didn't think of that makes them useful for you?

When you have lots of read/write properties, I find __slots__ to be a good idea.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What exactly is "exact" (was Clean Singleton Docstrings)

[Ben Finney]

Random832  writes:

> On Mon, Jul 18, 2016, at 00:46, Ben Finney wrote:
> > What is “those”? The measurement is imprecise, the observations are
> > inexact.
> > 
> > It makes no sense to say that a number is inexact. Exactness is not
> > a property of a number.
>
> There's no reason it shouldn't be a property of an object of a numeric
> type available in a programming environment though.

Yes. Because the object is not a number, it is a representation of a
number :-)

-- 
 \   “Truth is stranger than fiction, but it is because fiction is |
  `\ obliged to stick to possibilities, truth isn't.” —Mark Twain, |
_o__)  _Following the Equator_ |
Ben Finney

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

Re: What exactly is "exact" (was Clean Singleton Docstrings)

[Rustom Mody]

On Tuesday, July 19, 2016 at 12:28:36 AM UTC+5:30, Marko Rauhamaa wrote:
> Ian Kelly :
> 
> > Okay, so how is that wavelength defined?
> >
> > If you needed to mark a meter stick, and all you had was the
> > definition of c and the second, how would you do it without measuring
> > anything?
> 
> I wouldn't be measuring a meter stick. To measure, say, the height of a
> desk, I would bring in some caesium and shine its radiation from the
> desk level down to the floor. By counting the ebbs and flows of the
> radiation as it leaves the nozzle and strikes the wooden floor I make
> the approximage height measurement.
> 
> However, I know *exactly* how long a meter is without making a
> measurement.

I recollect — school physics textbook so sorry no link —
that in the Newton gravitation law
f = -GMm/r²

there was a discussion about the exponent of r ie  2
And that to some 6 decimal places it had been verified that it was
actually 2.02

I dont remember all the details
Just that something so obviously to a layman mathematic/analytic as 2
for a physicist may be something calling for experimental verification
ie synthetic/scienceic:
http://plato.stanford.edu/entries/analytic-synthetic/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: can't add variables to instances of built-in classes

[Lawrence D’Oliveiro]

On Tuesday, July 19, 2016 at 11:12:52 AM UTC+12, bream...@gmail.com wrote:
>
> On Monday, July 18, 2016 at 10:48:15 PM UTC+1, Lawrence D’Oliveiro wrote:
>>
>> 
>> When you have lots of read/write properties, I find __slots__ to be a good
>> idea.
> 
> Please explain why, thank you.

I was trying something like

ctx.dashes = ((0.1, 0.03, 0.03, 0.03), 0)

and wondering why it wasn’t working...
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What exactly is "exact" (was Clean Singleton Docstrings)

[Steven D'Aprano]

On Tue, 19 Jul 2016 01:25 am, Ian Kelly wrote:

> On Mon, Jul 18, 2016 at 3:29 AM, Steven D'Aprano
>  wrote:
>> On Monday 18 July 2016 14:16, Rustom Mody wrote:
>>> In short one could think of inexact and exact — in scheme's intended
>>> semantics — as better called scientific (or science-ic) and mathematic
>>> numbers.
>>
>> I don't think so. "Science" uses both experimentally-derived numbers
>> (e.g. G, c, the mass of the electron) and numbers known exactly (√2, e,
>> π).
> 
> Off-topic, c being a fundamental constant is actually in the latter
> category. Its *exact* value is 299792458 m/s.
> 
> The length of the meter, on the other hand, is defined as the distance
> traveled by light in a vacuum in 1/299792458 seconds and is subject to
> the precision of measurements.

You're right, of course, but that's a post-facto redefinition of both c and
the metre. Historically, the metre was defined first, then people spent a
lot of time measuring the speed of light (I believe it was Galileo who made
the first known attempt). Eventually, physicists decided that it was easier
to declare by fiat that c = 299792458 m/s EXACTLY, and use that definition
to imply a standard metre, rather than keep a standard metre and use that
to measure c.

That makes it a matter of convenience and practicality rather than purity.
It also reflects the current theoretical paradigm that sees c as a constant
and both distance and time subject to distortion. Had special and general
relativity been disproven, or never invented, it's unlikely that we would
have declared c to be more fundamental than distance.

(We haven't declared that G is exactly such-and-such a value, and used that
to define the kilogram.)



-- 
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: Request for help

[Steven D'Aprano]

On Tue, 19 Jul 2016 06:20 am, alister wrote:

> I suggest next time you stay awake during lessons.

That's an uncalled for nasty comment. You don't know the O.P's issues or why
he is having difficulty.



-- 
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 exactly is "exact" (was Clean Singleton Docstrings)

[Steven D'Aprano]

On Tue, 19 Jul 2016 10:36 am, Rustom Mody wrote:

> I recollect — school physics textbook so sorry no link —
> that in the Newton gravitation law
> f = -GMm/r²
> 
> there was a discussion about the exponent of r ie  2
> And that to some 6 decimal places it had been verified that it was
> actually 2.02

Because gravitational forces are so weak, it is very difficult to
experimentally distinguish (say) an exponent of 1.99 from 2.02 from
2 exactly.

Most physicists would say that an experimental result of 2.02 is pretty
good confirmation that the theoretical power of 2 is correct. Only a very
few would think that the experiment was evidence that both Newtonian and
Einsteinian gravitational theory is incorrect.

(Newton, for obvious reasons; but also general relativity, since Newton's
law can be derived from the "low mass/large distance" case of general
relativity.)

But it's an interesting hypothetical: what if the power wasn't 2 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: What exactly is "exact" (was Clean Singleton Docstrings)

[Steven D'Aprano]

On Mon, 18 Jul 2016 11:25 pm, Random832 wrote:

> On Mon, Jul 18, 2016, at 00:46, Ben Finney wrote:
>> What is “those”? The measurement is imprecise, the observations are
>> inexact.
>> 
>> It makes no sense to say that a number is inexact. Exactness is not a
>> property of a number.
> 
> There's no reason it shouldn't be a property of an object of a numeric
> type available in a programming environment though.

Yes, there is a reason.

Objects of numeric types in programming environments are intended to model
numbers. Since numbers are not "exact" or "inexact" (but only
calculations), then adding an "exact" attribute to the number makes as much
sense as adding attributes "colour", "weight", or "flavour".



-- 
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 exactly is "exact" (was Clean Singleton Docstrings)

[Rustom Mody]

On Tuesday, July 19, 2016 at 8:46:44 AM UTC+5:30, Steven D'Aprano wrote:
> On Tue, 19 Jul 2016 10:36 am, Rustom Mody wrote:
> 
> > I recollect — school physics textbook so sorry no link —
> > that in the Newton gravitation law
> > f = -GMm/r²
> > 
> > there was a discussion about the exponent of r ie  2
> > And that to some 6 decimal places it had been verified that it was
> > actually 2.02
> 
> Because gravitational forces are so weak, it is very difficult to
> experimentally distinguish (say) an exponent of 1.99 from 2.02 from
> 2 exactly.
> 
> Most physicists would say that an experimental result of 2.02 is pretty
> good confirmation that the theoretical power of 2 is correct. Only a very
> few would think that the experiment was evidence that both Newtonian and
> Einsteinian gravitational theory is incorrect.

Yes this was — if memory is right — the conclusion, viz.:
Experimentally it looks like 2.02 (or whatever)
This is as good as we can measure
So concluding its 2 seems to be reasonable with that 0.02 relegated to
experimental error

Nevertheless my main point was that such a math (aka analytic to a layman) 
looking entity like 2, may for a physicist be a quantity for synthetic 
verification

> 
> (Newton, for obvious reasons; but also general relativity, since Newton's
> law can be derived from the "low mass/large distance" case of general
> relativity.) 
> 
> But it's an interesting hypothetical: what if the power wasn't 2 exactly?

May be related to the margin of error for G being quite high
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What exactly is "exact" (was Clean Singleton Docstrings)

[Steven D'Aprano]

On Mon, 18 Jul 2016 08:15 pm, Chris Angelico wrote:

> On Mon, Jul 18, 2016 at 8:00 PM, Marko Rauhamaa  wrote:
>> Python programmers (among others) frequently run into issues with
>> surprising results in floating-point arithmetics. For better or worse,
>> Scheme has tried to abstract the concept. You don't need to explain the
>> ideas of IEEE 64-bit floating-point numbers or tie the hands of the
>> implementation. Instead, what you have is "reliable" arithmetics and
>> "best-effort" arithmetics, a bit like TCP is "reliable" and UDP is
>> "best-effort".
> 
> The problem with that is that failing to explain IEEE floating point
> and just calling it "inexact" scares people off unnecessarily. I've
> seen a lot of very intelligent people who think that you should never
> compare floats with the == operator, because floats randomly introduce
> "inaccuracy". 

Yes, this. "Never compare floats for equality" is a pernicious myth that
won't die.


> And then you get these sorts of functions: 
> 
> EPSILON = 0.01 # Adjust to control numeric accuracy
> def is_equal(f1, f2, epsilon=EPSILON):
> if abs(f1) > abs(f2):
> f1, f2 = f2, f1
> return abs(f2-f1) < f1*epsilon
> 
> and interminable debates about how to pick an epsilon, whether it
> should be relative to the smaller value (as here) or the larger (use
> f2 instead), or maybe should be an absolute value, or maybe it should
> be relative to the largest/smallest value that was ever involved in
> the calculation, or

Your code is buggy. Consider:

py> is_equal(-1.0, -1.0)
False



> Floating point numbers are a representation of real numbers that
> involves a certain amount of precision. They're ultimately no
> different from grade-school arithmetic where you round stuff off so
> you don't need an infinite amount of paper, except that they work with
> binary rather than decimal, so people think "0.1 + 0.2 ought to be
> exactly 0.3, why isn't it??", and blame floats.

Well, kinda... yes, ultimately deep down you're right. There's nothing
mysterious about floats. The lack of fundamental properties associativity:

(a+b)+c = a+(b+c)

and distributivity:

a×(b+c) = a×b + a×c

are due to numbers being recorded in finite precision, which means that some
calculations are inexact. But the *consequences* of that simple fact are
quite profound, and difficult. Earlier you mentioned "interminable debates
about how to pick an epsilon", but the reason for that is that it is
really, really hard to pick an epsilon in any systematic, objective way.

In the statistics module, I have run into this problem. Where possible, and
surprisingly often, I can test for exact equality. For example, here are a
couple of tests for geometric mean:


def test_multiply_data_points(self):
# Test multiplying every data point by a constant.
c = 111
data = [3.4, 4.5, 4.9, 6.7, 6.8, 7.2, 8.0, 8.1, 9.4]
expected = self.func(data)*c
result = self.func([x*c for x in data])
self.assertEqual(result, expected)

def test_doubled_data(self):
# Test doubling data from [a,b...z] to [a,a,b,b...z,z].
data = [random.uniform(1, 500) for _ in range(1000)]
expected = self.func(data)
actual = self.func(data*2)
self.assertApproxEqual(actual, expected, rel=1e-13)


I didn't hand-tune the constants in test_multiply_data_points, but nor can I
guarantee that if you replace them with other constants of similar
magnitude the assertEqual test will still be appropriate.

In the test_doubled_data case, rounding errors accumulate faster, and cancel
less often, so I use an inexact comparison. Why do I check for a relative
error of 1e-13, rather than 1e-12 or 2.5e-14? *shrug* I can't give an
objective reason for it. It just seems right to me: if the relative error
was much bigger, I'd say that the geometric mean function was too
inaccurate. If it were much smaller, it's too hard for me to have the tests
pass.




-- 
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 exactly is "exact" (was Clean Singleton Docstrings)

[Rustom Mody]

On Tuesday, July 19, 2016 at 9:12:57 AM UTC+5:30, Steven D'Aprano wrote:
> On Mon, 18 Jul 2016 08:15 pm, Chris Angelico wrote:
> 
> > On Mon, Jul 18, 2016 at 8:00 PM, Marko Rauhamaa wrote:
> >> Python programmers (among others) frequently run into issues with
> >> surprising results in floating-point arithmetics. For better or worse,
> >> Scheme has tried to abstract the concept. You don't need to explain the
> >> ideas of IEEE 64-bit floating-point numbers or tie the hands of the
> >> implementation. Instead, what you have is "reliable" arithmetics and
> >> "best-effort" arithmetics, a bit like TCP is "reliable" and UDP is
> >> "best-effort".
> > 
> > The problem with that is that failing to explain IEEE floating point
> > and just calling it "inexact" scares people off unnecessarily. I've
> > seen a lot of very intelligent people who think that you should never
> > compare floats with the == operator, because floats randomly introduce
> > "inaccuracy". 
> 
> Yes, this. "Never compare floats for equality" is a pernicious myth that
> won't die.

In this context, I asked Chris:
> I dont know what point you are trying to make
> Here is behavior.  Should one use == ?? 

As often happens between me and Chris I ask a ‘why’ (in this case ‘what’) 
question. And he gives a ‘how’ answer

So I again ask: You say «"Never compare floats for equality" is a pernicious
myth»

Given that for Chris’ is_equal we get
is_equal(.1+.1+.1, .3) is True
whereas for python builtin == its False

What (non)myth do you suggest for replacement?

[Note I am not arguing for the goodness of his is_equal]

Analogy: 
Mutable default parameters are a source of problem and confusion.

No A says. One can use them to simulate statics

No B says No problem as long as you make sure there is no mutation to the 
mutable, either inside or outside the function.

Sure thats all true. However
"Module-globals” is a simpler answer than A
And “DON’T” is simpler than B

So awaiting your preferred myth-ology…
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What exactly is "exact" (was Clean Singleton Docstrings)

[Chris Angelico]

On Tue, Jul 19, 2016 at 1:42 PM, Steven D'Aprano  wrote:
>> And then you get these sorts of functions:
>>
>> EPSILON = 0.01 # Adjust to control numeric accuracy
>> def is_equal(f1, f2, epsilon=EPSILON):
>> if abs(f1) > abs(f2):
>> f1, f2 = f2, f1
>> return abs(f2-f1) < f1*epsilon
>>
>> and interminable debates about how to pick an epsilon, whether it
>> should be relative to the smaller value (as here) or the larger (use
>> f2 instead), or maybe should be an absolute value, or maybe it should
>> be relative to the largest/smallest value that was ever involved in
>> the calculation, or
>
> Your code is buggy. Consider:
>
> py> is_equal(-1.0, -1.0)
> False

Duh, I got the < and <= bug! Shows how easy it is to get this kind of
function wrong. (Even more so, it shows how easy it is to get code
wrong when you type straight into an email and never test it.)

> Earlier you mentioned "interminable debates
> about how to pick an epsilon", but the reason for that is that it is
> really, really hard to pick an epsilon in any systematic, objective way.

Yeah, and that's the problem. If you're working with some concept of
measurement error, what you actually mean is that every number in your
calculation is actually a range centered on that number; which means
that "equality" really means "overlapping ranges". Epsilon-based
equality is just that, only with a global epsilon instead of one that
actually cares about the real error value. How can that NOT be doomed
to failure?

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

Re: What exactly is "exact" (was Clean Singleton Docstrings)

[Chris Angelico]

On Tue, Jul 19, 2016 at 2:58 PM, Rustom Mody  wrote:
> Analogy:
> Mutable default parameters are a source of problem and confusion.
>
> No A says. One can use them to simulate statics
>
> No B says No problem as long as you make sure there is no mutation to the 
> mutable, either inside or outside the function.
>
> Sure thats all true. However
> "Module-globals” is a simpler answer than A
> And “DON’T” is simpler than B
>
> So awaiting your preferred myth-ology…

Preferred: Understand what's going on. Unless you're talking to a
novice/student programmer (in which case "Oh, don't do that - ask me
about it later when we're not busy fixing this problem" is a valid
response), it's best that people understand what they're working with.

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

an error

[WePlayGames WeEnjoyIt]

while True:
 for event in pygame.event.get():
  if event.type==pygame.QUIT:
   pygame.quit()
   sys.exit()
 pygame1.blit(image1,(0,0))
 print ("choose from 0-8")
 p1=int(input())
 while p1>8 or p1<0 or list_b[p1]=="X" or list_b[p1]=="O":
print ("wtf bro")
p1=int(input())
 list_b[p1]="X"
 if p1==0:
  pygame1.blit(image2,(31,36))
 elif p1==1:
  pygame1.blit(image2,(90,36))
 elif p1==2:
  pygame1.blit(image2,(143,36))
 elif p1==3:
 pygame1.blit(image2,(31,90))
 elif p1==4:
 pygame.blit(image2,(90,90))
 elif p1==5:
  pygame1.blit(image2,(143,90))
 elif p1==6:
  pygame1.blit(image2,(31,146))
 elif p1==7:
  pygame1.blit(image2,(90,146))
 elif p1==8:
  pygame1.blit(image2,(143,146))

 total+=1
 print ("choose from 0-8")
 p2=int(input())
 while p2>8 or p2<0 or list_b[p2]=="X" or list_b[p2]=="O":
print ("wtf bro")
p2=int(input())
 list_b[p2]=="O"
 if p2==0:
  pygame1.blit(image3,(31,36))
 elif p2==1:
   pygame1.blit(image3,(90,36))
 elif p2==2:
   pygame1.blit(image3,(143,36))
 elif p2==3:
   pygame1.blit(image3,(31,90))
 elif p2==4:
   pygame1.blit(image3,(90,90))
 elif p2==5:
   pygame1.blit(image3,(143,90))
 elif p2==6:
   pygame1.blit(image3,(31,146))
 elif p2==7:
   pygam1e.blit(image3,(90,146))
 elif p2==8:
   pygame1.blit(image3,(143,146)
 total+=1
 fps=40
 clockfps.tick(fps)
 pygame.display.update()


the problem with this is that i get an syntax error at the very end at the 
TOTAL+=1 when i delete this it tells me that there is an error at the 
clockfps.tick(fps) thing what the heck is going on :p
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: an error

[Chris Angelico]

On Tue, Jul 19, 2016 at 4:07 PM, WePlayGames WeEnjoyIt
 wrote:
> the problem with this is that i get an syntax error at the very end at the 
> TOTAL+=1 when i delete this it tells me that there is an error at the 
> clockfps.tick(fps) thing what the heck is going on :p
>

When you get an error, Python gives you a very useful error message
(and traceback, although that doesn't apply to syntax errors like
this). Copy and paste that here. There are many possible syntax
errors, and Python will tell you which one.

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

Re: an error

[Ian Kelly]

On Tue, Jul 19, 2016 at 12:07 AM, WePlayGames WeEnjoyIt
 wrote:
>pygame1.blit(image3,(143,146)

This line is missing a closing parenthesis.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: an error

[WePlayGames WeEnjoyIt]

Τη Τρίτη, 19 Ιουλίου 2016 - 9:20:20 π.μ. UTC+3, ο χρήστης Chris Angelico έγραψε:
> On Tue, Jul 19, 2016 at 4:07 PM, WePlayGames WeEnjoyIt
>  wrote:
> > the problem with this is that i get an syntax error at the very end at the 
> > TOTAL+=1 when i delete this it tells me that there is an error at the 
> > clockfps.tick(fps) thing what the heck is going on :p
> >
> 
> When you get an error, Python gives you a very useful error message
> (and traceback, although that doesn't apply to syntax errors like
> this). Copy and paste that here. There are many possible syntax
> errors, and Python will tell you which one.
> 
> ChrisA

thanks chris for responding, it doesnt say anything else just syntax error
it have seen this error again when im using the for loop and it seems like when 
i delete everything after total+=1 i get a different error called UNEXPECTED 
EOF WHILE PARSING
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: an error

[Chris Angelico]

On Tue, Jul 19, 2016 at 4:26 PM, WePlayGames WeEnjoyIt
 wrote:
> thanks chris for responding, it doesnt say anything else just syntax error
> it have seen this error again when im using the for loop and it seems like 
> when i delete everything after total+=1 i get a different error called 
> UNEXPECTED EOF WHILE PARSING

Are you sure it says nothing else? Copy and paste exactly what happens
when you type "python3 yourgamename.py".

Exactly what happens.

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

Re: an error

[WePlayGames WeEnjoyIt]

Τη Τρίτη, 19 Ιουλίου 2016 - 9:32:34 π.μ. UTC+3, ο χρήστης Chris Angelico έγραψε:
> On Tue, Jul 19, 2016 at 4:26 PM, WePlayGames WeEnjoyIt
>  wrote:
> > thanks chris for responding, it doesnt say anything else just syntax error
> > it have seen this error again when im using the for loop and it seems like 
> > when i delete everything after total+=1 i get a different error called 
> > UNEXPECTED EOF WHILE PARSING
> 
> Are you sure it says nothing else? Copy and paste exactly what happens
> when you type "python3 yourgamename.py".
> 
> Exactly what happens.
> 
> ChrisA

ITS OK the problem was solved i forgot to close the thingy like ian said but 
now i got more problems ( not errors however). like i know how to load and blit 
a picture in my pygame window but i dont know why it wont work in this code, 
like nothing is actually appearing in my screen. long story short what i want 
to happend is image1 to appear in but it doesnt
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: an error

[Chris Angelico]

On Tue, Jul 19, 2016 at 4:37 PM, WePlayGames WeEnjoyIt
 wrote:
> Τη Τρίτη, 19 Ιουλίου 2016 - 9:32:34 π.μ. UTC+3, ο χρήστης Chris Angelico 
> έγραψε:
>> On Tue, Jul 19, 2016 at 4:26 PM, WePlayGames WeEnjoyIt
>>  wrote:
>> > thanks chris for responding, it doesnt say anything else just syntax error
>> > it have seen this error again when im using the for loop and it seems like 
>> > when i delete everything after total+=1 i get a different error called 
>> > UNEXPECTED EOF WHILE PARSING
>>
>> Are you sure it says nothing else? Copy and paste exactly what happens
>> when you type "python3 yourgamename.py".
>>
>> Exactly what happens.
>>
>> ChrisA
>
> ITS OK the problem was solved i forgot to close the thingy like ian said but 
> now i got more problems ( not errors however). like i know how to load and 
> blit a picture in my pygame window but i dont know why it wont work in this 
> code, like nothing is actually appearing in my screen. long story short what 
> i want to happend is image1 to appear in but it doesnt
>

It's important not just to solve your problem, but to learn *how* to
solve problems. Learning to read tracebacks is essential to being a
Python programmer.

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