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 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
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
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,
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
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
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
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
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
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
25 matches
Mail list logo
