Tim Peters wrote:
> can wait a couple months, I'd be happy to own it. A possible saving
> grace for ln() is that while the mathematical function is one-to-one,
I'm working right now in making the old operation to pass the new tests
ok.
Soon I'll cut a branch to work publicly on this (good idea
"Tim Peters" <[EMAIL PROTECTED]> wrote:
>
> One low-effort approach is to use a general root-finding algorithm and
> build ln(x) on top of exp() via (numerically) solving the equation
> exp(ln(x)) == x for ln(x). ...
Not a general one, please! At least use one that assumes the continuity
of seco
On 4/13/07, Tim Peters <[EMAIL PROTECTED]> wrote:
> One low-effort approach is to use a general root-finding algorithm and
> build ln(x) on top of exp() via (numerically) solving the equation
> exp(ln(x)) == x for ln(x). That appears to be what Don Peterson did
> in his implementation of transcend
[Raymond Hettinger]
> ...
> Likewise, consider soliciting Tim's input on how to implement the ln()
> operation. That one will be tricky to get done efficiently and correctly.
One low-effort approach is to use a general root-finding algorithm and
build ln(x) on top of exp() via (numerically) solvi
Raymond Hettinger wrote:
> As promised in the decimal.py header, the spec
> updates should all be considered as bugs and backported at some point
> after they are fully tested and we're happy with them all around.
> Also, as promised, the module should continue to run on Py2.3.
Ok. So far, I'm
Now that the checkin is done, I don't think it needs to be reverted. But, in
general, we should probably abstain from making wholesale revisions that add
zero value for the users.
The stylistic change from:
ValueError, 'foo'
ValueError('foo')
is fine.
Changing MockThreading to subcla
