Nasty typo in PEP 238 (revised)
tim.one at home.com
Sat Jul 28 02:42:58 EDT 2001
>>> when/if the grand unification happens what will math.cos do with 1+3j?
>>> What will floor do with 1.3+0j etc etc etc. Presumably a Timbot thread
>>> is even now busily extending all math functions to the complex domain.
>> My belief is that the vast majority of Python users are best
>> served by the current behavior of never getting a complex result from
>> non-complex inputs unless they explicitly invoke functions from the
>> cmath module. But that's a question you didn't ask (although you
>> should have). A more interesting question is whether math.acos(2)
>> should continue to whine.
> so the statement by the grand designer that int/float(x) won't cut it
> if x is complex is just a little fake.
I don't grasp your meaning, but not for lack of trying.
> If complex x hurts in division are we to accept it won't hurt in sqrt?
Sorry, but ditto. Give a concrete example? If someone said complex x hurts
in division, I missed it.
> The idea that we might import cmath to get complex '/' to work is
> interesting given the arguments presented about closure for arbitrary
> numerics as inputs to functions.
I haven't seen that idea before, and if you're now *suggesting* it I don't
see any point to it. Your examples had users explicitly passing complex
inputs to functions. I was talking about getting complex results out of
functions when complex numbers are *not* passed to them (such as acos(2)).
Division can never return a complex result unless given a complex input. I
see nothing surprising to anyone about complex-in, complex-out. It's only
non-complex-in, complex-out that Python currently shields users from (in the
absence of explicitly using cmath functions). As I said, I think that's a
benefit for the majority of users; I don't know whether Guido agrees.
> Others have been presenting similar schemes to preserve/change the
> natural order of literals etc, but these schemes seem doomed. If OO
> completeness is desirable why shouldn't math.acos is cmath.acos be
Don't know what "OO completeness" means. As a pragmatic matter, I would
much rather that the typical business programmer get an exception at the end
of their floating-point algorithm for (say) computing standard deviation,
when due to fp inexperience they use a numerically naive textbook method
that ends up passing a negative number to sqrt due to massive cancellation.
Let that silently return a complex result instead, and God only knows how
much more computation they'll do with it before getting a meaningless result
in the end. For most users most of the time, a complex result is more
likely a symptom of an error in their code (or uncaught bogosity in their
data) than a useful result.
If you're a Comp Sci Purity Guy, you may want to torture them with 4.02j
> I accept along with others that there are other numeric models. I don't
> accept the grand unification at face value as some kind of panacea.
Do you believe anyone does? Not even Moshe has claimed that it would be.
> Before all this brouhaha we didn't really understand any of the real
> problems and I don't believe we can solve them to everyone's
This stuff isn't new to me, and I know that we can't. That doesn't imply
trying to do better would be a net loss.
either<wink>-ly y'rs - tim
More information about the Python-list