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:15mark.dickinsonsetspambayes_score: 0.00385769 -> 0.0038576904
recipients: + mark.dickinson, gvanrossum, tim.peters, Rhamphoryncus, christian.heimes, gmcastil
2008-01-21 14:53:15mark.dickinsonsetspambayes_score: 0.00385769 -> 0.00385769
messageid: <1200927195.69.0.767753890342.issue1640@psf.upfronthosting.co.za>
2008-01-21 14:53:14mark.dickinsonlinkissue1640 messages
2008-01-21 14:53:13mark.dickinsoncreate