Nick, I didn't write that; Tim did. If you're going to enter into a
pedantic discussion, at least get your attributions right,
On 1/26/07, Nick Maclaren <[EMAIL PROTECTED]> wrote:
> "Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> >
> > "(int)float_or_double" truncates in C (even in K&R C) /provide
"Tim Peters" <[EMAIL PROTECTED]> wrote:
>
> OTOH, I am a fan of analyzing FP operations as if the inputs were in
> fact exactly what they claim to be, which 754 went a long way toward
> popularizing. That largely replaced mountains of idiosyncratic
> "probabilistic arguments" (and where it seemed
[Tim Peters]
>> ...
>> [it would be possible for float.__divmod__ to return the exact
>> quotient], but who would have a (sane) use for a possibly 2000-bit
>> quotient?
[Nick Maclaren]
> Well, the 'exact rounding' camp in IEEE 754 seem to think that there
> is one :-)
>
> As you can gather, I can'
"Tim Peters" <[EMAIL PROTECTED]> wrote:
>
> [Tim (misattributed to Guido)]
Apologies to both!
> > C90 is unclear about its intent,
>
> But am skeptical of that. I don't have a copy of C90 here, but before
> I wrote that I checked Kernighan & Ritchie's seminal C book, Harbison
> & Steele's genera
[Tim (misattributed to Guido)]
>> "(int)float_or_double" truncates in C (even in K&R C) /provided that/
>> the true result is representable as an int. Else behavior is
>> undefined (may return -1, may cause a HW fault, ...).
[Nick Maclaren]
> Actually, I have used Cs that didn't, but haven't seen
"Tim Peters" <[EMAIL PROTECTED]> wrote:
>
> It could, but who would have a (sane) use for a possibly 2000-bit quotient?
Well, the 'exact rounding' camp in IEEE 754 seem to think that there
is one :-)
As you can gather, I can't think of one. Floating-point is an inherently
inaccurate representati
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
>
> "(int)float_or_double" truncates in C (even in K&R C) /provided that/
> the true result is representable as an int. Else behavior is
> undefined (may return -1, may cause a HW fault, ...).
Actually, I have used Cs that didn't, but haven't seen any
[Tim Peters]
>> ...
>> Maybe we could introduce "%" as a unary prefix operator, where
>> %x means "the fractional part of x" ;-)
[Anders J. Munch]
> What'ya talking about? Obviously it should be a suffix operator ;-)
Na -- that would be confusing ;-)
...
>> time.sleep(1.0 - math.fmod(now,
[Armin Rigo]
>> Thanks for the clarification. Yes, it makes sense that __mod__,
>> __divmod__ and __floordiv__ on float and decimal would eventually follow
>> the same path as for complex (where they make even less sense and
>> already raise a DeprecationWarning).
[Nick Maclaren]
> Yes. Though t
...
[Tim]
>> fractional part of x == fmod(x, 1.0) == modf(x)[0], so you could use
>> either.
[Anders J. Munch]
> Actually, on the off chance that time.time() is negative, he can use
> neither. It has to be math.ceil, float.__mod__ or divmod.
If time.time() is negative, I expect this would be th
[Armin]
> Thanks for the clarification. Yes, it makes sense that __mod__,
> __divmod__ and __floordiv__ on float and decimal would eventually follow
> the same path as for complex (where they make even less sense and
> already raise a DeprecationWarning).
This truly has nothing to do with complex
[Guido]
> ...
> I don't care about the speed, but having to import math (which I
> otherwise almost never need) is a distraction, and (perhaps more so) I
> can never remember whether it's modf() or fmod() that I want.
fractional part of x == fmod(x, 1.0) == modf(x)[0], so you could use
either. Si
On 1/25/07, Tim Peters <[EMAIL PROTECTED]> wrote:
> [Guido]
> > The only thing I would miss about this is that I am used to write
> > certain timing loops that like to sync on whole seconds, by taking
> > time.time() % 1.0 which nicely gives me the milliseconds in the
> > current second. E.g.
> >
>
[Guido]
> The only thing I would miss about this is that I am used to write
> certain timing loops that like to sync on whole seconds, by taking
> time.time() % 1.0 which nicely gives me the milliseconds in the
> current second. E.g.
>
> while True:
> do_something_expensive_once_a_second_on_the_s
The only thing I would miss about this is that I am used to write
certain timing loops that like to sync on whole seconds, by taking
time.time() % 1.0 which nicely gives me the milliseconds in the
current second. E.g.
while True:
do_something_expensive_once_a_second_on_the_second()
now = time.
Armin Rigo <[EMAIL PROTECTED]> wrote:
>
> Thanks for the clarification. Yes, it makes sense that __mod__,
> __divmod__ and __floordiv__ on float and decimal would eventually follow
> the same path as for complex (where they make even less sense and
> already raise a DeprecationWarning).
Yes. Tho
Hi Tim,
On Tue, Jan 23, 2007 at 05:14:29PM -0500, Tim Peters wrote:
> For some reason `decimal` implemented __mod__ as the proposed
> standard's "remainder" operation. That's the immediate source of your
> surprise. IMO `decimal` should not have implemented __mod__ at all,
> as Python's number-t
On Wednesday 24 January 2007 10:20, Alexey Borzenkov wrote:
> > > I think that's the right thing to do, because that is mathematically
> > > correct. j is just an imaginary number with a property that j*j = -1.
> > > So
> > >
> > > (a+bj) + (c+dj)j = (a-d) + (b+c)j.
> >
> > Yes, thanks, I know wha
On 1/24/07, Gareth McCaughan <[EMAIL PROTECTED]> wrote:
[Alexey:]
> I think that's the right thing to do, because that is mathematically
> correct. j is just an imaginary number with a property that j*j = -1. So
> (a+bj) + (c+dj)j = (a-d) + (b+c)j.
Yes, thanks, I know what j is, and I know how
On Wednesday 24 January 2007 08:39, Alexey Borzenkov wrote:
[me, about complex():]
> > It seems pretty clear what it thinks it's doing -- namely,
> > defining complex(a,b) = a + ib even when a,b are complex.
> > And half of why it does that is clear: you want complex(a)=a
> > when a is complex. Wh
On 1/24/07, Gareth McCaughan <[EMAIL PROTECTED]> wrote:
> >>> complex(complex(1.0, 2.0), complex(10.0, 20.0))
>
> (-19+12j)
>
> WTF? In any case, that's also what's destroying the sign of the
> imaginary part in complex(1.0, -0.0).
It seems pretty clear what it thinks it's doing -- namely,
def
On Tuesday 23 January 2007 07:01, Tim Peters wrote:
> complex_new() ends with:
>
> cr.real -= ci.imag;
> cr.imag += ci.real;
>
> and I have no idea what that thinks it's doing. Surely this isn't
intended?!:
> >>> complex(complex(1.0, 2.0), complex(10.0, 20.0))
>
> (-19+12j)
>
> WTF?
[Armin]
>>> BTW - isn't that case in contradiction with the general Python rule that
>>> if b > 0, then a % b should return a number between 0 included and b
>>> excluded?
[Tim]
>> Sure.
[Armin]
> You're not addressing my point, though, so I was probably not clear
> enough.
"Sure" is the answer
"Jim Jewett" <[EMAIL PROTECTED]> wrote:
>
> >... I can work with and teach almost any model,
> > and have done so with some pretty weird ones.
>
> I think python's model is "Whatever your other tools use. Ask them."
> And I think that is a reasonable choice.
Answer: It's undefined. Just because
Nick Maclaren wrote:
>... I can work with and teach almost any model,
> and have done so with some pretty weird ones.
I think python's model is "Whatever your other tools use. Ask them."
And I think that is a reasonable choice.
For sensible input, the various models all work the same.
For dubio
[Tim Peters]
> [Anders J. Munch]
> > I did read the whole thread, and I saw your -1%1e100 example. Mixing
> > floating-point numbers of very different magnitude can get you in
> > trouble - e.g. -1+1e100==1e100. I don't think -1%1e100 is all that
> > worse.
>
> Except that it's very easy to retu
Hi Tim,
On Sun, Jan 21, 2007 at 09:08:18PM -0500, Tim Peters wrote:
> >BTW - isn't that case in contradiction with the general Python rule that
> >if b > 0, then a % b should return a number between 0 included and b
> >excluded?
>
> Sure.
You're not addressing my point, though, so I was probably
Tim Peters wrote:
> Which "Spec"? For example, floor division isn't mentioned at all in
> IBM's proposed decimal standard, or in PEP 327, or in the Python
Oops, you're right. My fault, sorry.
> Library Reference section on `decimal`. It's an artifact of trying to
> extend Python's integer mod
On Tuesday 23 January 2007 22:27, Tim Peters wrote:
> Which is why I don't want binary or decimal floats to support
> infix "%" as a spelling in P3K. I don't believe floating mod is
> heavily used, and if so there's scant need for a one-character
> spelling -- and if there's a method or function n
A generic comment. Many of my postings seem to be being misunderstood.
I hold no brief for ANY particular floating-point religion, sect or
heresy, except insofar as it affects robustness and portability (i.e.
"software engineering"). I can work with and teach almost any model,
and have done so w
[Tim Peters]
>> Please read the whole thread. Maybe you did, but you said nothing
>> here that indicated you had. The issues aren't about tiny integers
>> that happen to be in float format, where the result is exactly
>> representable as a float too. Those don't create problems for any
>> defini
Tim Peters wrote:
> Please read the whole thread. Maybe you did, but you said nothing
> here that indicated you had. The issues aren't about tiny integers
> that happen to be in float format, where the result is exactly
> representable as a float too. Those don't create problems for any
> defini
[Guido]
>>> I guess the conjugate() function could also just return self (although I see
>>> that conjugate() for a complex with a zero imaginary part returns
>>> something whose imaginary part is -0; is that intentional?
[TIm Peters]
>> That's wrong, if true: it should return something with the
Tim> For example, floor division isn't mentioned at all in IBM's
Tim> proposed decimal standard, or in PEP 327, or in the Python Library
Tim> Reference section on `decimal`. It's an artifact of trying to
Tim> extend Python's integer mod definition to floats, and for reasons
Ti
[Anders J. Munch]
> What design error? float.__mod__ works perfectly.
>
> >>> -1 % 50
> 49
> >>> -1.0 % 50.0
> 49.0
> >>>
Please read the whole thread. Maybe you did, but you said nothing
here that indicated you had. The issues aren't about tiny integers
that happen to be in float format, where
"Tim Peters" <[EMAIL PROTECTED]> wrote:
>
> > I guess the conjugate() function could also just return self (although I see
> > that conjugate() for a complex with a zero imaginary part returns
> > something whose imaginary part is -0; is that intentional?
>
> That's wrong, if true: it should retu
Tim Peters wrote:
> Do note that this discussion is only about Python 3. Under the view
> that it was a (minor, but real) design error to /try/ extending
> Python's integer mod definition to floats, if __mod__, and __divmod__
> and __floordiv__ go away for binary floats in P3K they should
> certai
[Guido]
>> The ints aren't really embedded in Decimal, so we don't have to do
>> that there (but we could).
[Facundo Batista]
> -0.
>
> If we can't achieve it without disturbing the rest of Python, I'll try
> as much as possible to keep what the Spec proposes.
Which "Spec"? For example, floor di
[Guido]
>> That really sucks, especially since the whole point of making int
>> division return a float was to make the integers embedded in the
>> floats... I think the best solution would be to remove the definition
>> of % (and then also for divmod()) for floats altogether, deferring to
>> math.
[Guido]
> ...
> So you are proposing that Decimal also rip out the % and // operators
> and __divmod__? WFM, but I don't know what Decimal users say (I'm not
> one).
Yes: it's just as much a floating type as HW binary floats, and all
the same issues come up. For example, decimal floats are just
Guido van Rossum wrote:
> The ints aren't really embedded in Decimal, so we don't have to do
> that there (but we could).
-0.
If we can't achieve it without disturbing the rest of Python, I'll try
as much as possible to keep what the Spec proposes.
Regards,
--
. Facundo
.
Blog: http://www.t
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
>
> That really sucks, especially since the whole point of making int
> division return a float was to make the integers embedded in the
> floats... I think the best solution would be to remove the definition
> of % (and then also for divmod())
On 1/21/07, Tim Peters <[EMAIL PROTECTED]> wrote:
> [Tim]
> >> It's just a fact that different definitions of mod are most useful
> >> most often depending on data type. Python's is good for integers and
> >> often sucks for floats. The C99 and `decimal` definition(s) is/are
> >> good for floats
...
[Tim]
>> It's just a fact that different definitions of mod are most useful
>> most often depending on data type. Python's is good for integers and
>> often sucks for floats. The C99 and `decimal` definition(s) is/are
>> good for floats and often suck(s) for integers. Trying to pretend
>> t
On 1/21/07, Tim Peters <[EMAIL PROTECTED]> wrote:
> It's just a fact that different definitions of mod are most useful
> most often depending on data type. Python's is good for integers and
> often sucks for floats. The C99 and `decimal` definition(s) is/are
> good for floats and often suck(s) fo
[Tim Peters]
>> ...
>> >>> decimal.Decimal(-1) % decimal.Decimal("1e100")
>> Decimal("-1")
[Armin Rigo]
> BTW - isn't that case in contradiction with the general Python rule that
> if b > 0, then a % b should return a number between 0 included and b
> excluded?
Sure.
> We try hard to do that for
Hi Tim,
On Fri, Jan 19, 2007 at 08:33:23PM -0500, Tim Peters wrote:
> >>> decimal.Decimal(-1) % decimal.Decimal("1e100")
> Decimal("-1")
BTW - isn't that case in contradiction with the general Python rule that
if b > 0, then a % b should return a number between 0 included and b
excluded? We try
[Raymond Hettinger]
> I bumped into an oddity today:
>
> 6.0 // 0.001 != math.floor(6.0 / 0.001)
>
> In looking at Objects/floatobject.c, I was surprised to find that
> float_floor_division() is implemented in terms of float_divmod(). Does anyone
> know why it takes such a circuitous path? I
Probably because I tend not to know what I'm doing when numerics are
concerned. :-(
On 1/19/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> I bumped into an oddity today:
>
> 6.0 // 0.001 != math.floor(6.0 / 0.001)
>
> In looking at Objects/floatobject.c, I was surprised to find that
> floa
I bumped into an oddity today:
6.0 // 0.001 != math.floor(6.0 / 0.001)
In looking at Objects/floatobject.c, I was surprised to find that
float_floor_division() is implemented in terms of float_divmod(). Does anyone
know why it takes such a circuitous path? I had expected something simpler
50 matches
Mail list logo