Tim Peters <[EMAIL PROTECTED]> writes:
> [Tim]
> >> Ah, but as I've said before, virtually all C compilers on 754 boxes
> >> support _some_ way to get at this stuff. This includes gcc before C99
> >> and fenv.h -- if the platforms represented in fpectlmodule.c were
> >> happy to use gcc, they all
[Michael Hudson]
> In what way does C99's fenv.h fail? Is it just insufficiently
> available, or is there some conceptual lack?
[Tim Peters]
Just that it's not universally supported. Look at fpectlmodule.c for
a sample of the wildly different ways it _is_ spelled across some
>>
[Steven D'Aprano]
> (All previous quoting ruthlessly snipped.)
And ruthlessly appreciated ;-)
> A question for Tim Peters, as I guess he'll have the most experience in
> this sort of thing.
>
> With all the cross-platform hassles due to the various C compilers not
> implementing the IEEE standard
Tim Peters <[EMAIL PROTECTED]> writes:
> [Michael Hudson]
> > I doubt anyone else is reading this by now, so I've trimmed quotes
> > fairly ruthlessly :)
>
> Damn -- there goes my best hope at learning how large a message gmail
> can handle before blowing up . OK, I'll cut even more.
Heh.
> [M
(All previous quoting ruthlessly snipped.)
A question for Tim Peters, as I guess he'll have the most experience in
this sort of thing.
With all the cross-platform hassles due to the various C compilers not
implementing the IEEE standard completely or correctly, I wonder how much
work would be inv
[Michael Hudson]
> I doubt anyone else is reading this by now, so I've trimmed quotes
> fairly ruthlessly :)
Damn -- there goes my best hope at learning how large a message gmail
can handle before blowing up . OK, I'll cut even more.
[Michael]
>>> Can't we use the stuff defined in Appendix F and
I doubt anyone else is reading this by now, so I've trimmed quotes
fairly ruthlessly :)
Tim Peters <[EMAIL PROTECTED]> writes:
> > Actually, I think I'm confused about when Underflow is signalled -- is it
> > when a denormalized result is about to be returned or when a genuine
> > zero is about t
[Tim Peters]
>> All Python behavior in the presence of infinities, NaNs, and signed
>> zeroes is a platform-dependent accident, mostly inherited from that
>> all C89 behavior in the presence of infinities, NaNs, and signed
>> zeroes is a platform-dependent crapshoot.
[Michael Hudso
Tim Peters <[EMAIL PROTECTED]> writes:
> [Tim Peters]
> All Python behavior in the presence of infinities, NaNs, and signed
> zeroes is a platform-dependent accident, mostly inherited from that
> all C89 behavior in the presence of infinities, NaNs, and signed
> zeroes is a pla
[Tim Peters]
All Python behavior in the presence of infinities, NaNs, and signed
zeroes is a platform-dependent accident, mostly inherited from that
all C89 behavior in the presence of infinities, NaNs, and signed
zeroes is a platform-dependent crapshoot.
[Michael Hudson]
>>> A
On Tue, Jul 05, 2005 at 09:49:33PM +0100, Tom Anderson wrote:
> Are there any uses for NaN that aren't met by exceptions?
Sure. If you can naturally calculate two things at once, but one might
turn out to be a NaN under current rules.
x, y = calculate_two_things()
if isnan(x):
pe
On Tue, 05 Jul 2005 10:10:47 -0500, Terry Hancock wrote:
> I have to mention that the idea of a math package that
> allows NaN to propagate as though it were a number
> scares the willies out of me. God help me if I were to use
> it on something like Engineering where lives might
> depend on th
On Tue, 5 Jul 2005, Terry Hancock wrote:
> Really, the only *right* thing to do is to raise an exception ASAP after
> the NaN comes up.
That sounds like a very good idea.
Are there any uses for NaN that aren't met by exceptions?
tom
--
[Philosophy] is kind of like being driven behind the sof
Tim Peters <[EMAIL PROTECTED]> writes:
> [Tim Peters]
> >> All Python behavior in the presence of infinities, NaNs, and signed
> >> zeroes is a platform-dependent accident, mostly inherited from that
> >> all C89 behavior in the presence of infinities, NaNs, and signed
> >> zeroes is a platform-de
On Sunday 03 July 2005 10:47 pm, Steven D'Aprano wrote:
> Any floating point package that supports the IEEE
> standard should give you a test to see if a float
> represents a NaN. That's what you need. You certainly
> can't rely on "x == SOME_NAN" because there are 254
> different NaNs.
>
> Th
[Tim Peters]
>> All Python behavior in the presence of infinities, NaNs, and signed
>> zeroes is a platform-dependent accident, mostly inherited from that
>> all C89 behavior in the presence of infinities, NaNs, and signed
>> zeroes is a platform-dependent crapshoot.
[Michael Hudson]
> As you may
Tim Peters <[EMAIL PROTECTED]> writes:
> All Python behavior in the presence of infinities, NaNs, and signed
> zeroes is a platform-dependent accident, mostly inherited from that
> all C89 behavior in the presence of infinities, NaNs, and signed
> zeroes is a platform-dependent crapshoot.
As you
On Mon, 04 Jul 2005 15:35:56 +0100, Tom Anderson wrote:
>>> Also, would it be a good idea for (-1.0) ** 0.5 to evaluate to 1.0j? It
>>> seems a shame to have complex numbers in the language and then miss this
>>> opportunity to use them!
>>
>> It's generally true in Python that complex numbers are
Steven D'Aprano wrote:
> James Dennett wrote:
>
>> > Yes: 5^2 + -2^2 is 29, however you write it.
>>
>> *If* you take -2 as a number, but not if you take the number
>> as 2 and the unary minus as an operator with lower precedence
>> than exponentiation.
>
>
> [snip]
>
>> Not in this respect.
On Sun, 3 Jul 2005, Tim Peters wrote:
> [Tom Anderson]
>> So, is there a way of generating and testing for infinities and NaNs
>> that's portable across platforms and versions of python?
>
> Not that I know of, and certainly no simple way.
>
>> If not, could we perhaps have some constants in the m
On Sun, 3 Jul 2005, Dennis Lee Bieber wrote:
> On Sun, 3 Jul 2005 20:53:22 +0100, Tom Anderson <[EMAIL PROTECTED]>
> declaimed the following in comp.lang.python:
>
>>2
>> -1
>>
>> Evaluates to -1?
>
> But what do you expect, say
>
> 2
> -X
>
> to evaluate as? (-X)^2 or -(X^2)
>
>
"Steven D'Aprano" <[EMAIL PROTECTED]> wrote:
> But it doesn't make sense to say that two flags are equal:
>
> keep_processing = True
> more_reading_needed = True
> while more_reading_needed and keep_processing:
> get_more_records()
> process_records()
> if not keep_processing:
> pri
Tom Anderson wrote:
> Yes. However, it's an excellent reason why python's precedence
> rules are wrong - in conventional mathematical notation, the unary
> minus, used to denote the sign of a literal number, does indeed
> have higher precedence than exponentiation: -1^2 evaluates to 1,
> not -1.
Tom Anderson wrote about NaNs:
> > (Remember, a NaN is just an illusionary placeholder, not a number.)
>
> If you think it's illusionary, i invite you to inspect the contents of
> my variables - i have a real, live NaN trapped in one of them!
No you don't. You have a flag that says "This
calcu
James Dennett wrote:
> > Yes: 5^2 + -2^2 is 29, however you write it.
>
> *If* you take -2 as a number, but not if you take the number
> as 2 and the unary minus as an operator with lower precedence
> than exponentiation.
[snip]
> Not in this respect. However, the question is whether that's
>
George Sakkis wrote:
> "Tom Anderson" <[EMAIL PROTECTED]> wrote:
>
>
>>>But NaNs are _not_ things.
>>
>>I disagree. A NaN _is_ a thing; it's not a floating-point number, for
>>sure, but it is a symbol which means "there is no answer", or "i don't
>>know", and as such, it should follow the univers
"Tom Anderson" <[EMAIL PROTECTED]> wrote:
> > But NaNs are _not_ things.
>
> I disagree. A NaN _is_ a thing; it's not a floating-point number, for
> sure, but it is a symbol which means "there is no answer", or "i don't
> know", and as such, it should follow the universal rules which apply to
> al
...
[Tom Anderson]
> So, is there a way of generating and testing for infinities and NaNs
> that's portable across platforms and versions of python?
Not that I know of, and certainly no simple way.
> If not, could we perhaps have some constants in the math module for them?
See PEP 754 for this.
Tom Anderson wrote:
> On Sun, 3 Jul 2005, George Sakkis wrote:
>
>> "Tom Anderson" <[EMAIL PROTECTED]> wrote:
>>
> And finally, does Guido know something about arithmetic that i
> don't, or
> is this expression:
>
> -1.0 ** 0.5
>
> Evaluated wrongly?
No
On Mon, 4 Jul 2005, Steven D'Aprano wrote:
> On Sun, 03 Jul 2005 15:46:35 +0100, Tom Anderson wrote:
>
>> I think there would be a lot less confusion over the alleged inaccuracy of
>> floating point if everyone wrote in hex - indeed, i believe that C99 has
>> hex floating-point literals. C has alw
On Sun, 3 Jul 2005, Tim Peters wrote:
> [Fredrik Johansson]
>
I'd rather like to see a well implemented math.nthroot. 64**(1/3.0)
gives 3.9996, and this error could be avoided.
>
> [Steven D'Aprano]
>> math.exp(math.log(64)/3.0)
>>> 4.0
>>>
>>> Success!!!
>
> None of this
On Sun, 3 Jul 2005, George Sakkis wrote:
> "Tom Anderson" <[EMAIL PROTECTED]> wrote:
>
And finally, does Guido know something about arithmetic that i don't, or
is this expression:
-1.0 ** 0.5
Evaluated wrongly?
>>>
>>> No, it is evaluated according to the rules of pre
[Steven D'Aprano]
...
> But this works:
>
> py> inf = float("inf")
> py> inf
> inf
Another platform-dependent accident. That does not work, for example,
on Windows. In fact, the Microsoft C float<->string routines don't
support any way "to spell infinity" that works in the string->float
directi
On Sun, 03 Jul 2005 15:46:35 +0100, Tom Anderson wrote:
> I think there would be a lot less confusion over the alleged inaccuracy of
> floating point if everyone wrote in hex - indeed, i believe that C99 has
> hex floating-point literals. C has always been such a forward-thinking
> language!
N
[Fredrik Johansson]
>>> I'd rather like to see a well implemented math.nthroot. 64**(1/3.0)
>>> gives 3.9996, and this error could be avoided.
[Steven D'Aprano]
>> >>> math.exp(math.log(64)/3.0)
>> 4.0
>>
>> Success!!!
[Tom Anderson]
> Eeenteresting. I have no idea why this works.
"Tom Anderson" <[EMAIL PROTECTED]> wrote:
> >> And finally, does Guido know something about arithmetic that i don't, or
> >> is this expression:
> >>
> >> -1.0 ** 0.5
> >>
> >> Evaluated wrongly?
> >
> > No, it is evaluated according to the rules of precedence. It is
> > equivalent to -(1.0**0.5).
"Steven D'Aprano" <[EMAIL PROTECTED]> wrote:
> Unfortunately, floating point maths is a bit of a black art. Try this
> simple calculation:
>
> py> 4.0/3 - 5.0/6
> 0.49989
>
> Should be 0.5 exactly.
>
> Many numbers which you can write exactly in decimal cannot be
> stored exactly in fl
On Mon, 4 Jul 2005, Steven D'Aprano wrote:
> On Sun, 03 Jul 2005 10:56:42 +0100, Tom Anderson wrote:
>
>> On Sun, 3 Jul 2005, Steven D'Aprano wrote:
>>
>>> On Sun, 03 Jul 2005 02:22:23 +0200, Fredrik Johansson wrote:
>>>
On 7/3/05, Tom Anderson <[EMAIL PROTECTED]> wrote:
> That's one way.
On Sun, 03 Jul 2005 10:56:42 +0100, Tom Anderson wrote:
> On Sun, 3 Jul 2005, Steven D'Aprano wrote:
>
>> On Sun, 03 Jul 2005 02:22:23 +0200, Fredrik Johansson wrote:
>>
>>> On 7/3/05, Tom Anderson <[EMAIL PROTECTED]> wrote:
That's one way. I'd do:
root = value ** 0.5
Doe
On Sun, 3 Jul 2005, Steven D'Aprano wrote:
> On Sun, 03 Jul 2005 02:22:23 +0200, Fredrik Johansson wrote:
>
>> On 7/3/05, Tom Anderson <[EMAIL PROTECTED]> wrote:
>>> That's one way. I'd do:
>>>
>>> root = value ** 0.5
>>>
>>> Does that mean we can expect Guido to drop math.sqrt in py3k? :)
>>
>> I
On Sun, 03 Jul 2005 02:22:23 +0200, Fredrik Johansson wrote:
> On 7/3/05, Tom Anderson <[EMAIL PROTECTED]> wrote:
>> That's one way. I'd do:
>>
>> root = value ** 0.5
>>
>> Does that mean we can expect Guido to drop math.sqrt in py3k? :)
>
> I'd rather like to see a well implemented math.nthroo
On 7/3/05, Tom Anderson <[EMAIL PROTECTED]> wrote:
> That's one way. I'd do:
>
> root = value ** 0.5
>
> Does that mean we can expect Guido to drop math.sqrt in py3k? :)
I'd rather like to see a well implemented math.nthroot. 64**(1/3.0)
gives 3.9996, and this error could be avoided.
On Sat, 2 Jul 2005, Tom Brown wrote:
> On Saturday 02 July 2005 10:55, Nathan Pinno wrote:
>
>> Brief question for anyone who knows the answer, because I don't. Is
>> there anyway to make Python calculate square roots?
>
> from math import sqrt
That's one way. I'd do:
root = value ** 0.5
Does
On Saturday 02 July 2005 10:55, Nathan Pinno wrote:
> Brief question for anyone who knows the answer, because I don't. Is
> there anyway to make Python calculate square roots?
from math import sqrt
--
http://mail.python.org/mailman/listinfo/python-list
"Nathan Pinno" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>Brief question for anyone who knows the answer, because I don't.
> Is there anyway to make Python calculate square roots?
Python can calculate any calculable function of the objects it has to work
with. So the answer
Nathan Pinno wrote:
>
> Hi all,
>
> Brief question for anyone who knows the answer, because I don't. Is
> there anyway to make Python calculate square roots?
http://docs.python.org/
There is a search facility.
--
Robert Kern
[EMAIL PROTECTED]
"In the fields of hell where the
Hi all,
Brief question for anyone who knows the answer, because I don't. Is there
anyway to make Python calculate square roots?
Thanks,
Nathan Pinnohttp://www.npinnowebsite.ca/
--
http://mail.python.org/mailman/listinfo/python-list
47 matches
Mail list logo
