[Python-Dev] Releasemanager, please approve #1532975

[Thomas Heller]

Approval requested for patch:
http://python.org/sf/1532975

Thanks,

Thomas

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Rounding float to int directly ...

[Nick Maclaren]

Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> You should NOT be using binary floats for money
> in the first place.

Or floating-point at all, actually.  But binary floating-point is
definitely unsuited for such a use.

> Pseudo-rounding to decimal places is not
> the right way to do that. The right way is
> to compare the difference to a tolerance.

Right.  Where the tolerance should be a combination of relative
and absolute accuracy.  1.0e-300 should usually be 'similar' to 0.0.


Simon Burton <[EMAIL PROTECTED]> wrote:
>
> It's not even clear to me that int(round(x)) is always the
> nearest integer to x.

There is a sense in which this is either true or overflow occurs.

> Is it always true that float(some_int)>=some_int ?  (for positive values).
>
> (ie. I am wondering if truncating the float representation
> of an int always gives back the original int).

No.

Consider 'standard' Python representations on a 64-bit system.  There
are only 53 bits in the mantissa, but an integer can have up to 63.
Very large integers need to be rounded, and can be rounded up or down.


Please note that I am not arguing against an int_rounded() function.
There is as much reason to want one as an int_truncated() one, but
there is no very good reason to to want more than one of the two.
int_expanded() [i.e. ceiling] is much less useful.

For people interested in historical trivia, the dominance of the
truncating form of integer conversion over the rounding form seems to
be yet another side-effect of the Fortran / IBM 370 dominance over
the Algol / other hardware, despite the fact that most modern
languages are rooted in CPL rather than Fortran.  I am unaware of
any technical grounds to prefer one over the other (i.e. the reasons
for wanting each are equally balanced).

It all comes down to the simple question "Do we regard a single
primitive for int(round()) as important enough to provide?"

I abstain :-)


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email:  [EMAIL PROTECTED]
Tel.:  +44 1223 334761Fax:  +44 1223 334679
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Rounding float to int directly ...

[Michael Chermside]

Greg Ewing writes:
> [I propose for Py3k that] builtin round()
> to return an int, and have something somewhere
> else, such as math.fround(), for round-to-float.

+1.

The need to convert float to int is pervasive. The need to round (binary)
floats to integer (or other decimal) floats is _much_ less common.
Furthermore, the need for "round to nearest int" is much more common
than the need for "integer floor" (although as pointed out, each could
be defined in terms of the other except for certain rules for rounding
exact halves). And most telling of all, if I were to stop 10 random
programmers on the street, most of them not familiar with Python, and
ask them to guess what the function named "round" did, I'm guessing
the majority would think of float-to-int. It's a nice feature of Python
that "it just works".


Marc-Andre Lemburg writes:
> You often have a need for controlled rounding when doing
> financial calculations or [other reason snipped]

Hmm. Not in the banks _I_ have worked at! We *never* use binary
floating point for money. The decimal class is fairly useful in
that regard.

Nick Maclaren write:
> Decimal doesn't even help people who care about accuracy.

Not true! The float class is incapable of maintaining 700 digits of
precision, but Decimal handles it just fine. (Why you would WANT
more than around 53 bits of precision is a different question, but
Decimal handles it.)

> People who care about the accuracy of calculations prefer binary,
> as it is a more accurate model.

Huh? That doesn't even make sense! A model is not inherently accurate
or inaccurate, it is only an accurate or inaccurate representation
of some "real" system. Neither binary nor decimal is a better
representation of either rational or real numbers, the first
candidates for "real" system I thought of. Financial accounting rules
tend to be based on paper-and-pencil calculations for which
decimal is usually a far better representation.

If you had said that binary floats squeeze out more digits of
precision per bit of storage than decimal floats, or that binary
floats are faster because they are supported by specialized hardware,
then I'd go along, but they're not a "better model".

-- Michael Chermside



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] FW: using globals

[Werkhoven J.P. van (Sjaak)]

> Hi,
> 
> I have got a problem with importing global variables. For instance I have
> got two files:
> 
> # t1.py   #t2.py
> 
> counter = 1   
> 
> def counter_adder(filenr):def
> show_adder():
>global counter import
> t1
>counter+= 1
> print("adder is %d" % t1.counter)
>if filenr == 1:
>   show_adder()
>else:
>   import t2
>   t2.show_adder()
> 
> def show_adder():
>print("adder is %d" % counter)
> 
> >>counter_adder(1)
> adder is 2
> >>counter_adder(2)
> adder is 1
> 
> When I look at the outcome of two function calls I expected no differences
> but much to my surprise it goes wrong when the global variable is
> imported. It doesn't give the updated value but the value it get when
> instantiated. Who come? What should I do to get the updated value
> 
> greetings,
> 
> Sjaak van Werkhoven
>  
> 


DISCLAIMER***
Deze e-mail is uitsluitend bestemd voor de geadresseerde(n). Verstrekking aan 
en gebruik door anderen is niet toegestaan. Fortis sluit iedere 
aansprakelijkheid uit die voortvloeit uit electronische verzending. 

This e-mail is intended exclusively for the addressee(s), and may not be passed 
on to, or made available for use by any person other than the addressee(s). 
Fortis rules out any and every liability resulting from any electronic 
transmission. 
**
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Rounding float to int directly ...

[Nick Maclaren]

Michael Chermside <[EMAIL PROTECTED]> wrote:
>
> > Decimal doesn't even help people who care about accuracy.
>
> Not true! The float class is incapable of maintaining 700 digits of
> precision, but Decimal handles it just fine. (Why you would WANT
> more than around 53 bits of precision is a different question, but
> Decimal handles it.)

Oh, yes, the CURRENT decimal class is potentially more accurate than
the CURRENT floating class, but that has nothing to do with the
intrinsic differences in the base.

> > People who care about the accuracy of calculations prefer binary,
> > as it is a more accurate model.
> 
> Huh? That doesn't even make sense! A model is not inherently accurate
> or inaccurate, it is only an accurate or inaccurate representation
> of some "real" system. Neither binary nor decimal is a better
> representation of either rational or real numbers, the first
> candidates for "real" system I thought of. Financial accounting rules
> tend to be based on paper-and-pencil calculations for which
> decimal is usually a far better representation.
> 
> If you had said that binary floats squeeze out more digits of
> precision per bit of storage than decimal floats, or that binary
> floats are faster because they are supported by specialized hardware,
> then I'd go along, but they're not a "better model".

No, that isn't true.  The "wobbling precision" effect may be overstated,
but is real, and gets worse the larger the base is.  To the best of my
knowledge, that is almost the only way in which binary is more accurate
than decimal, in absolute terms, and it is a marginal difference.  Note
that I said "prefer", not "require" :-)

For example, calculating the relative difference between two close
numbers is sensitive to whether you are using the numbers in their
normal or inverse forms (by a factor on N in base N), and this is a
common cause of incorrect answers.  A factor of 2 is better than one
of 10.


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email:  [EMAIL PROTECTED]
Tel.:  +44 1223 334761Fax:  +44 1223 334679
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Rounding float to int directly ...

[Michael Chermside]

Nick Maclaren:
> The "wobbling precision" effect may be overstated,
> but is real, and gets worse the larger the base is.  To the best of my
> knowledge, that is almost the only way in which binary is more accurate
> than decimal, in absolute terms, and it is a marginal difference.

Okay, that makes sense.

However, if I understand "wobbling precision" correctly (and it's a BIG
if) then it refers to the fact that interpolating from the last digit of
precision doesn't work so well (intentionally vague phrase). So I
would think (but could be wrong) that it is always trumped by adding
another digit of precision to your numbers / lookup tables / whatever.
If so, then even more credit needs to be given to the system that
supports adjustable precision (the Decimal module).

-- Michael Chermside

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] FW: using globals

[Ronald Oussoren]

 
On Wednesday, August 02, 2006, at 01:02PM, Werkhoven J.P. van (Sjaak) <[EMAIL 
PROTECTED]> wrote:

>> Hi,
>> 
>> I have got a problem with importing global variables. For instance I have
>> got two files:

Your message is off-topic for python-dev, this list is for the development OF 
python, not development WITH python. You're much likier to get an answer on 
python-list or comp.lang.python (which are the same).

BTW. The formatting of the source-code in you're e-mail was such that I have no 
idea how it is supposed to look :-(

Regards,
  Ronald
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Rounding float to int directly ...

[Nick Coghlan]

Michael Chermside wrote:
> Greg Ewing writes:
>> [I propose for Py3k that] builtin round()
>> to return an int, and have something somewhere
>> else, such as math.fround(), for round-to-float.
> 
> +1.
> 
> The need to convert float to int is pervasive. The need to round (binary)
> floats to integer (or other decimal) floats is _much_ less common.
> Furthermore, the need for "round to nearest int" is much more common
> than the need for "integer floor" (although as pointed out, each could
> be defined in terms of the other except for certain rules for rounding
> exact halves). And most telling of all, if I were to stop 10 random
> programmers on the street, most of them not familiar with Python, and
> ask them to guess what the function named "round" did, I'm guessing
> the majority would think of float-to-int. It's a nice feature of Python
> that "it just works".

The potential issue with accidentally triggering truncating division also goes 
away in Py3k, so that's another point in favour of switching round() to return 
an integer result.

Another option would be to provide this as a method of float objects (similar 
to decimal).


> Nick Maclaren write:
>> Decimal doesn't even help people who care about accuracy.
> 
> Not true! The float class is incapable of maintaining 700 digits of
> precision, but Decimal handles it just fine. (Why you would WANT
> more than around 53 bits of precision is a different question, but
> Decimal handles it.)

The decimal module's default settings actually provide 93 bits or so of 
precision (28 decimal digits).

Sure, there may still be cases where you have to care about dynamic range, but 
if two numbers are separated by 28 orders of magnitude the smaller one really 
is pretty damn close to zero as far as the second one is concerned (in a fixed 
point system, the second one usually *would* be zero).

Cheers,
Nick.


-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Rounding float to int directly (Re: struct module and coercing floats to integers)

[M.-A. Lemburg]

Greg Ewing wrote:
> M.-A. Lemburg wrote:
> 
>> You often have a need for controlled rounding when doing
>> financial calculations 
> 
> You should NOT be using binary floats for money
> in the first place.

Believe me: you have to if you want to do more
advanced calculus related to pricing and risk
analysis of derivatives.

>> or in situations where you want to
>> compare two floats with a given accuracy,
> 
> Pseudo-rounding to decimal places is not
> the right way to do that. The right way is
> to compare the difference to a tolerance.

This is not the same: if you round both value
and then compare, you test a different interval
than by taking the difference and applying
a tolerance value comparison:

>>> x = 1.12
>>> y = 1.124999
>>> round(x,2) == round(y,2)
True
>>> abs(x-y) < 1e-2
True

yet:

>>> y = 1.1275
>>> round(x,2) == round(y,2)
False
>>> abs(x-y) < 1e-2
True

>> e.g. to work
>> around rounding problems ;-)
> 
> As Tim Peters has pointed out many times,
> you can't fix binary/decimal representation
> problems by rounding. There are always cases
> that give a different result than you would
> want.

Right, but in most real-world cases it works :-)

>> Hmm, looks like a YAGNI to me,
> 
> In all my programming so far I've found
> numerous uses for round-to-int, and exactly
> zero uses for round-binary-float-to-decimal-
> places. So from my point of view, the YAGNI
> applies to the *current* behavour of round()!

Most typical uses of round() don't use the
optional argument, true, but I still fail
to see what returning an integer instead of
a float would buy you.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 02 2006)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] TRUNK FREEZE 2006-07-03, 00:00 UTC for 2.5b3

[Anthony Baxter]

The trunk is FROZEN from 00:00 UTC/GMT on 03 July 2006. That's in about 12 
hours from now. This is for the third (and final, hopefully!) beta of 2.5. 

Please help the release team out by not making checkins on the trunk after 
that time until I send out an email that the release is done. 

Thanks,
Anthony
-- 
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] TRUNK FREEZE 2006-07-03, 00:00 UTC for 2.5b3

[Jean-Paul Calderone]

On Wed, 2 Aug 2006 22:29:44 +1000, Anthony Baxter <[EMAIL PROTECTED]> wrote:
>The trunk is FROZEN from 00:00 UTC/GMT on 03 July 2006. That's in about 12
>hours from now. This is for the third (and final, hopefully!) beta of 2.5.
>
>Please help the release team out by not making checkins on the trunk after
>that time until I send out an email that the release is done.

Does this mean that there is no further opportunity to resolve regressions
such as 
,
 or will changes be allowed between b3 and final?

Jean-Paul
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] TRUNK FREEZE 2006-07-03, 00:00 UTC for 2.5b3

[skip]

>> Please help the release team out by not making checkins on the trunk
>> after that time until I send out an email that the release is done.

Jean-Paul> Does this mean that there is no further opportunity to
Jean-Paul> resolve regressions such as
Jean-Paul> 
,
Jean-Paul> or will changes be allowed between b3 and final?

The latter.  One would hope bugfixes only.

Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Rounding float to int directly ...

[M.-A. Lemburg]

Michael Chermside wrote:
> Marc-Andre Lemburg writes:
>> You often have a need for controlled rounding when doing
>> financial calculations or [other reason snipped]
> 
> Hmm. Not in the banks _I_ have worked at! We *never* use binary
> floating point for money. The decimal class is fairly useful in
> that regard.

For accounting, I agree - banks would rather not lose too many
cents :-)

However, banks also tend to do more exotic things, esp. in investment
banking, where prices are not determined by taking the sum of a list
of values, but rather turn out to be the result of some calculus.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 02 2006)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Rounding float to int directly (Re: struct module and coercing floats to integers)

[BJörn Lindqvist]

On 8/2/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> Greg Ewing wrote:
> > In all my programming so far I've found
> > numerous uses for round-to-int, and exactly
> > zero uses for round-binary-float-to-decimal-
> > places. So from my point of view, the YAGNI
> > applies to the *current* behavour of round()!
>
> Most typical uses of round() don't use the
> optional argument, true, but I still fail
> to see what returning an integer instead of
> a float would buy you.

One hundred and sixty two type conversions!

http://www.google.se/search?hl=sv&q=filetype%3Apy+%22int%28round%22&btnG=S%C3%B6k&meta=

-- 
mvh Björn
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] TRUNK FREEZE 2006-07-03, 00:00 UTC for 2.5b3

[Neal Norwitz]

This looks like it needs to be fixed as it's a regression.  As Skip
said, bug fixes are allowed.  There will still be at least one release
candidate.  It's looking like c1 will be around Aug 18 and final
around Sept 12.  I'll update the PEP when I get a chance and confirm
all the dates.

n
--

On 8/2/06, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
> On Wed, 2 Aug 2006 22:29:44 +1000, Anthony Baxter <[EMAIL PROTECTED]> wrote:
> >The trunk is FROZEN from 00:00 UTC/GMT on 03 July 2006. That's in about 12
> >hours from now. This is for the third (and final, hopefully!) beta of 2.5.
> >
> >Please help the release team out by not making checkins on the trunk after
> >that time until I send out an email that the release is done.
>
> Does this mean that there is no further opportunity to resolve regressions
> such as 
> ,
>  or will changes be allowed between b3 and final?
>
> Jean-Paul
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/nnorwitz%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Bad interaction of __index__ and sequence repeat

[Guido van Rossum]

All, please decide without me.

On 8/1/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Nick Coghlan wrote:
> > Travis Oliphant wrote:
> >>> Probably the most interesting thing now would be for Travis to review
> >>> it, and see whether it makes things easier to handle for the Numeric
> >>> scalar types (given the amount of code the patch deleted from the
> >>> builtin and standard library data types, hopefully the benefits to
> >>> Numeric will be comparable).
> >>
> >> I noticed most of the checks for PyInt where removed in the patch.  If I
> >> remember correctly, I left these in for "optimization."   Other than
> >> that, I think the patch is great.
> >
> > You're right - there was a fast path based on PyInt_Check in
> > _PyEval_SliceIndex that got lost, which I'll add back in. I'll also add
> fast
> > paths for PyInt_Check to the functions in abstract.c, too.
> >
> > The other PyInt_Check's (in slot_nb_index and instance_index) were there
> to
> > check that __index__ returned the right thing. The check was still there
> in
> > slot_nb_index, but I'd incorrectly removed it from instance_index. I'll
> add
> > that one back in, too.
> >
> > Once that's done, I'll update the tracker item and reassign to Tim for a
> review.
>
> Aside from the 'assign to Tim' part, this is done now (pep357-fix-v3 on the
> tracker item). I also tweaked the clipping version of the C API to
> optionally
> expose the overflow flag that abstract.c was using internally so the client
> code can find out whether or not clipping actually occurred.
>
> The patch also updates the index unit tests to:
>- cover the various type errors that Travis picked up
>- actually run the full set of unit tests under -O
>- only run the basic sequence independent tests once (instead of once per
> sequence type)
>
> Neal also had a number of questions that I responded to in the tracker
> comments.
>
> The most significant question related to the API signature, which Neal
> considered potentially confusing:
>PyNumber_Index(PyObject *item, int *is_index)
>
> I added the is_index flag to the function signatures instead of providing a
> separate PyNumber_IndexCheck function in order to avoid doing the same type
> check twice in the typical mp_subscript implementation cases.
>
> One possibility would be to invert the sense of that flag and call it
> "typeerror", which probably more accurately reflects what it's intended for
> -
> it's a way of telling the function "if this object does not have the correct
> type, tell me by setting this flag instead of by setting the Python error
> state".
>
> Regards,
> Nick.
>
> --
> Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
> ---
>  http://www.boredomandlaziness.org
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>


-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Bad interaction of __index__ and sequence repeat

[Travis Oliphant]

Nick Coghlan wrote:
> 
> 
> One possibility would be to invert the sense of that flag and call it 
> "typeerror", which probably more accurately reflects what it's intended for - 
> it's a way of telling the function "if this object does not have the correct 
> type, tell me by setting this flag instead of by setting the Python error 
> state".

+1 on changing the name (type_error might be a better spelling)

-Travis

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Rounding float to int directly (Re: struct module and coercing floats to integers)

[Simon Burton]

On Wed, 2 Aug 2006 07:21:02 -0400
"Chermside, Michael" <[EMAIL PROTECTED]> wrote:

> 
> You wrote:
> > (ie. I am wondering if truncating the float representation
> > of an int always gives back the original int).
> 
> Yes it does, because all integers that can be expressed as floats
> can be expressed EXACTLY as floats.

Yes, OK this makes sense.

My point is that, regardless of this answer, as a python user I should not
be worried by such details. At least: the doc string for round() should be
expanded to mention the int(round(x)) use case.

Simon.

-- 
Simon Burton, B.Sc.
Licensed PO Box 8066
ANU Canberra 2601
Australia
Ph. 61 2 6249 6940
http://arrowtheory.com 
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Rounding float to int directly ...

[Greg Ewing]

Nick Maclaren wrote:
> I am unaware of
> any technical grounds to prefer one over the other (i.e. the reasons
> for wanting each are equally balanced).

If they're equally balanced in the sense of there
being equal numbers of use cases for both, that
would seem to be a reason to *have* both.

What's the feeling about this? If, e.g. int()
were changed in Py3k to round instead of truncate,
would it cause anyone substantial pain?

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Rounding float to int directly ...

[Greg Ewing]

Michael Chermside wrote:
> (Why you would WANT
> more than around 53 bits of precision is a different question, but
> Decimal handles it.)

You can't have travelled far beyond Alpha Centauri
recently. The major interstellar banking corporations
need *quite* a lot of bits for dealing with the
economy of a medium-sized galaxy. The Decimal module
has been a godsend to them -- they were all making
do with long integers until that came along.

Of course they've had to make some modifications
to handle the number bases used by some of the
more unusual species out there, such as the
13-fingered Quezorpians, but that's just a simple
matter of programming.

Always remember where your towel is,
Zaphod
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Rounding float to int directly ...

[Greg Ewing]

Nick Coghlan wrote:

> Another option would be to provide this as a method of float objects 
> (similar to decimal).

That wouldn't be so good. Either kind of rounding ought to be
a function that you can apply without knowing what kind of
number you've got -- int, float, Decimal, or something else.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Rounding float to int directly (Re: struct module and coercing floats to integers)

[Greg Ewing]

M.-A. Lemburg wrote:

> Believe me: you have to if you want to do more
> advanced calculus related to pricing and risk
> analysis of derivatives.

When you do things like that, you're treating
money as though it were a continuous quantity.
This is an approximation, so you can tolerate
having small inaccuracies in the result.

But when adding up actual, real amounts of
money, where the result must be exact, using
binary fractions is a very bad idea.

> This is not the same: if you round both value
> and then compare, you test a different interval
> than by taking the difference and applying
> a tolerance value comparison:

That's exactly my point. Chopping decimal
places is not a substitute for doing tolerance
testing properly.

> Most typical uses of round() don't use the
> optional argument, true, but I still fail
> to see what returning an integer instead of
> a float would buy you.

It saves you a function call in the vast
majority of cases, where an int is what
you ultimately want.

--
Greg


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] struct module and coercing floats to integers

[Bob Ippolito]

On Jul 28, 2006, at 1:35 PM, Bob Ippolito wrote:

> It seems that the pre-2.5 struct module has some additional
> undocumented behavior[1] that didn't percolate into the new version:
> http://python.org/sf/1530559
>
> Python 2.4 and previous will coerce floats to integers when necessary
> as such without any kind of complaint:
>
> $ python2.4 -c "import struct; print repr(struct.pack('>H',
> 0.))"
> '\x00\x00'
>
> Python 2.5 refuses to coerce float to int:
>
> $ python2.5 -c "import struct; print repr(struct.pack('>H',
> 0.))"
> Traceback (most recent call last):
>File "", line 1, in 
>File "/Users/bob/src/python/Lib/struct.py", line 63, in pack
>  return o.pack(*args)
> TypeError: unsupported operand type(s) for &: 'float' and 'long'
>
> The available options are to:
>
> 1. Reinstate the pre-2.5 weirdness
> 2. Reinstate the pre-2.5 weirdness with a DeprecationWarning
> 3. Break existing code that relies on undocumented behavior (seems
> more like a bug than lack of specification)

There's a patch in the tracker for 2. It should get applied when the  
trunk freeze is over.

-bob

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Rounding float to int directly (Re: struct module and coercing floats to integers)

[Raymond Hettinger]

>> Most typical uses of round() don't use the
>> optional argument, true, but I still fail
>> to see what returning an integer instead of
>> a float would buy you.
>
>
> It saves you a function call in the vast
> majority of cases, where an int is what
> you ultimately want.
>

-1 on an extra built-in just to save the time for function call -- this 
is a false optimization, one that is unlikely to ever be the bottleneck 
in any real program's running time.  If it isn't time you care about but 
just hate writing it, what's wrong with a simple helper function like:   
rndint=lambda x:  int(round(x)) ?  There are no shortage of possible 
function pairs that could be proposed (perhaps list(set(x)) or 
int(abs(x)) for example).  Of course, it would be silly to make new 
builtins for them.  IMHO, the case is weak for adding a new variant of 
round().

Also, -10 on changing the semantics of int() to round instead of 
truncate.  The truncating version is found is so many other languages 
and book examples, that it would be a disaster for us to choose a 
different meaning.


Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Rounding float to int directly (Re: struct module and coercing floats to integers)

[James Y Knight]

On Aug 2, 2006, at 11:26 PM, Raymond Hettinger wrote:
> Also, -10 on changing the semantics of int() to round instead of
> truncate.  The truncating version is found is so many other languages
> and book examples, that it would be a disaster for us to choose a
> different meaning.

I'd be happy to see floats lose their __int__ method entirely,  
replaced by an explicit truncate function.

I've always thought it quite a hack that python floats have implicit  
truncation to ints, and then a random smattering of APIs go to extra  
lengths to explicitly prevent float.__int__ from being called because  
people thought "passing a float makes no sense!". That's right, it  
doesn't, and it _never_ should happen implicitly, not just in those  
particular few cases. Explicit is better than implicit.

James

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Rounding float to int directly (Re: struct module and coercing floats to integers)

[Greg Ewing]

Raymond Hettinger wrote:

> -1 on an extra built-in just to save the time for function call

The time isn't the main issue. The main issue
is that almost all the use cases for round()
involve doing an int() on it afterwards. At
least nobody has put forward an argument to
the contrary yet.

Sure you can define your own function to do
this. But that's still a considerable burden
when you add up the effort over all the
programs that use int(round()).

--
Greg


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Rounding float to int directly ...

[Christian Tanzer]

Greg Ewing <[EMAIL PROTECTED]> wrote:

> What's the feeling about this? If, e.g. int()
> were changed in Py3k to round instead of truncate,
> would it cause anyone substantial pain?

Gratuitous breakage!

I shudder at the thought of checking hundreds of int-calls to see if
they'd still be correct under such a change.

-- 
Christian Tanzerhttp://www.c-tanzer.at/

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com