This issue tracker has been migrated to GitHub ,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
| Author | mark.dickinson |
|---|---|
| Recipients | Rhamphoryncus, christian.heimes, gmcastil, gvanrossum, mark.dickinson, tim.peters |
| Date | 2008年01月21日.14:53:13 |
| SpamBayes Score | 0.0038576904 |
| Marked as misclassified | No |
| Message-id | <1200927195.69.0.767753890342.issue1640@psf.upfronthosting.co.za> |
| In-reply-to |
| Content | |
|---|---|
Christian: I'm definitely not proposing atanh(1) = inf: it should raise
ValueError. I'm proposing that we follow Tim's rules for now; this means no
change for finite inputs.
The new thing here is that since you've made inf and nan more accessible and
consistent across platforms, I think we should make sure that the math functions
do the right thing for an *input* of +/-inf or nan. I'm almost sure that the
current behavior of e.g. exp(float("inf")) is more-or-less accidental rather
than designed.
I think I'm missing the point of your math.atanh(.999...) example.
.99999999999999999 *is* already exactly equal to 1.0, so you're just proving
that math.atanh(1.0) currently gives a ValueError. (Which, again, I think is
the right thing to do.)
>>> x = .99999999999999999
>>> x == 1.0
True
The atanh0022 result is definitely a bug: it looks like either asinh or log1p
is buggy. I'll try to figure it out. |
|
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2008年01月21日 14:53:15 | mark.dickinson | set | spambayes_score: 0.00385769 -> 0.0038576904 recipients: + mark.dickinson, gvanrossum, tim.peters, Rhamphoryncus, christian.heimes, gmcastil |
| 2008年01月21日 14:53:15 | mark.dickinson | set | spambayes_score: 0.00385769 -> 0.00385769 messageid: <1200927195.69.0.767753890342.issue1640@psf.upfronthosting.co.za> |
| 2008年01月21日 14:53:14 | mark.dickinson | link | issue1640 messages |
| 2008年01月21日 14:53:13 | mark.dickinson | create | |