James Y Knight wrote:
> And it does in C because C doesn't have arbitrary size integers, so if
> round returned integers, round(1e+308) couldn't work.
Also, in C you can use the result directly in an int
context without complaint. In Python these days, that
is usually disallowed.
--
Greg
_
On Tue, Aug 01, 2006, Ron Adam wrote:
>
> I'm -1 on implicitly converting to an int when rounding.
>
> One reason is if your rounded (to int type) number is then used in an
> equation you my end up with a integer result when you wanted a floating
> point result.
>
> >>> 23.5/5.2
> 4.5192307692
On Aug 3, 2006, at 2:34 AM, Greg Ewing wrote:
> 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 nobo
M.-A. Lemburg wrote:
> If you are eventually rounding to say 2 decimal
> places in the end of the calculation, you won't
> want to find yourself presenting the user 1.12
> and 1.13 as equal values :-)
Even if, before rounding, they were actually
1.124 and 1.1251? And if the
differ
Nick Coghlan wrote:
> Ron Adam wrote:
>> Consider an example where you are combining data that had different
>> number of significant digits. Keeping all the digits of your answer
>> gives a false since of accuracy. The extra digits are meaningless
>> because the margin of error is greater tha
Ronald Oussoren <[EMAIL PROTECTED]> wrote:
>
> > There are algorithms where the operation of rounding (or truncation)
> > is needed, but where the value may be larger than can be held in an
> > integer, and that is not an error.
>
> Is that really true for python? Python integers are unbounded in
On Aug 3, 2006, at 9:43 PM, Nick Maclaren wrote:
Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
That's my experience as well. In my opinion, the purpose of round()
is most commonly described as "to make an integer". So it should
yield an integer.
Grrk. No, that logic is flawed.
There are algori
Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
>
> That's my experience as well. In my opinion, the purpose of round()
> is most commonly described as "to make an integer". So it should
> yield an integer.
Grrk. No, that logic is flawed.
There are algorithms where the operation of rounding (or truncat
On Thu, 3 Aug 2006, Greg Ewing wrote:
> 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.
That's my experience as well. In my opinion, the purpose of round()
is most commonly described as "to make an integer".
Greg Ewing wrote:
> 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.
Or, more accurately, they *should* involve an int
afterwards, but often
Ron Adam wrote:
> Consider an example where you are combining data that had different
> number of significant digits. Keeping all the digits of your answer
> gives a false since of accuracy. The extra digits are meaningless
> because the margin of error is greater than any of the digits that
Nick Maclaren <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Christian Tanzer) wrote:
> > 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?
> >
> > G
James Y Knight <[EMAIL PROTECTED]> wrote:
>
> I'd be happy to see floats lose their __int__ method entirely,
> replaced by an explicit truncate function.
Come back Algol - all is forgiven :-) Yes, indeed. I have favoured
that view for 35 years - anything that can lose information quietly
shoul
Greg Ewing wrote:
> 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 argume
Greg Ewing wrote:
> 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,
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
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
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
>> 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 buil
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
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.
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
econom
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'
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 expres
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
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 i
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
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 intege
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 make
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 differ
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_ le
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 wa
On Sat, 29 Jul 2006 15:44:33 +1200
Greg Ewing <[EMAIL PROTECTED]> wrote:
> Michael Urman wrote:
> > The fact that
> > round returns a float rather than an int, while intentional, does not
> > feature prominently in one's mine when the first version yielded the
> > expected results.
>
> As an asid
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.
> or in situations where you want to
> compare two floats with a given accuracy,
Pseudo-rounding to decimal places is n
Nick Maclaren wrote:
> "M.-A. Lemburg" <[EMAIL PROTECTED]> wrote:
>> You often have a need for controlled rounding when doing
>> financial calculations or in situations where you want to
>> compare two floats with a given accuracy, e.g. to work
>> around rounding problems ;-)
>
> The latter is a c
Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>
> Hogwash. The only issues with decimal are ease-of-use and speed.
I suggest that you get hold of a good 1960s or 1970s book on computer
arithmetic, and read up about "wobbling precision". While it is not
a big deal, it was regarded as such, and is
Nick Maclaren wrote:
Well, maybe. There are other approaches, too, and Decimal has its
problems with that. In particular, when people need precisely
defined decimal rounding, they ALWAYS need fixed-point and not
floating-point.
The decimal spec was designed to encompass both floating-
Aahz <[EMAIL PROTECTED]> wrote:
> On Tue, Aug 01, 2006, M.-A. Lemburg wrote:
> >
> > You often have a need for controlled rounding when doing financial
> > calculations or in situations where you want to compare two floats
> > with a given accuracy, e.g. to work around rounding problems ;-)
> >
> >
On Tue, Aug 01, 2006, M.-A. Lemburg wrote:
>
> You often have a need for controlled rounding when doing financial
> calculations or in situations where you want to compare two floats
> with a given accuracy, e.g. to work around rounding problems ;-)
>
> The usual approach is to use full float accur
"M.-A. Lemburg" <[EMAIL PROTECTED]> wrote:
>
> You often have a need for controlled rounding when doing
> financial calculations or in situations where you want to
> compare two floats with a given accuracy, e.g. to work
> around rounding problems ;-)
The latter is a crude hack, and was traditiona
Greg Ewing wrote:
> M.-A. Lemburg wrote:
>
>> I suppose you don't know about the optional argument
>> to round that lets you round up to a certain decimal ?!
>
> Yes, I know about, but I rarely if ever use it.
> Rounding a binary float to a number of decimal
> places seems a fundamentally ill-con
M.-A. Lemburg wrote:
> I suppose you don't know about the optional argument
> to round that lets you round up to a certain decimal ?!
Yes, I know about, but I rarely if ever use it.
Rounding a binary float to a number of decimal
places seems a fundamentally ill-considered thing
to do anyway. What
Greg Ewing wrote:
> Raymond Hettinger wrote:
>
>> I think this would harm more than it would help. It more confusing to
>> have several rounding-thingies to choose from than it is have an
>> explicit two-step.
>
> But is it more confusing enough to be worth forcing
> everyone to pay two functi
Raymond Hettinger wrote:
> I think this would harm more than it would help. It more confusing to
> have several rounding-thingies to choose from than it is have an
> explicit two-step.
But is it more confusing enough to be worth forcing
everyone to pay two function calls instead of one
in the
Greg Ewing wrote:
>As an aside, does anyone else think that it would be
>useful to have a builtin which rounds and converts to
>an int in one go? Whenever I use round(), I almost
>always want the result as an int, and making me do
>it in two steps seems unnecessarily bothersome.
>
>
I think this
Michael Urman wrote:
> The fact that
> round returns a float rather than an int, while intentional, does not
> feature prominently in one's mine when the first version yielded the
> expected results.
As an aside, does anyone else think that it would be
useful to have a builtin which rounds and con
46 matches
Mail list logo
