float / double support in Python?

Brandon Van Every vanevery at 3DProgrammer.com
Tue Feb 11 05:02:37 EST 2003


Martijn Faassen wrote:
> Brandon Van Every <vanevery at 3dprogrammer.com> wrote:
> [snip]
>> Not supporting a basic machine type in the year 2003 is brain dead.
>> It is excusable in new languages with limited problem domains.
>
> Not abstracting away basic machine types in the 2003 is brain dead

You think we should all use 64-bit integers because some machines do it
natively, and others can do it with an emulation library?  You think we
should all use 2-byte wide chars because the Japanese need them?  Why stop
at 8-byte doubles then?  Why not implement arbitrary precision integer and
floating point libraries?  Well, because on real computers, efficiency and
storage are issues, duh.

> It is execusable in old languages with limited problem domains. :)

Please name the "limited problem domains" for a language such as C++.  It
may not be the best fit to everything, but it certainly has been used for
everything.  What you're really saying is, you want to limit what Python is
applicable to.

> This depends, as many things, on your perspective..
>
>> 3D graphics programmers are going to knock Python
>> for this until it's fixed.
>
> Why do you want to write low level 3D code in Python?

The lower I can go without excessive fat, the less I have to worry about
Python / C++ boundaries, and the more I can use Python's easier syntax and
primitives.  Ergo, the more productively I can code.  But if I have to keep
Python at a higher level for fear of its piggishness, then it's the same old
C++ drill for that sort of problem.

In my experience, a 3D graphics engine has to stack component on top of
component on top of component.  It would be nice to stack these components
on top of each other without having to worry about bloat.  I can of course
do this in C++, which is why I'm still using C++ for my 3D engine
development.  But C++ isn't as flexible as Python and sometimes you run into
problems where you really wish you had an easier to use, but still efficient
language.

> I can only think of one main reason to write such low level 3D code in
> Python and that's to have an easier time experimenting, but then raw
> performance does not matter too much.

I don't believe the drill should have to be "experiment and reimplement."  I
would like the option to "experiment, then leave it alone if it works."  I
can certainly leave the C++ alone.  But I'm limited as to how much
experimentation I can do.

> It is generally a useful thing to post with a working mind, so you
> don't come across the wrong way. :)

I disagree.  My working mind has to go towards the life tasks that will make
me money, or that produce great art, or help friends in jeopardy, or
otherwise secure something of tremendous value to me.  A Python debate ain't
it.  I don't greatly care if I come across "the wrong way" on a Usenet
forum.  My experience on Usenet is that crowds cannot be pleased, so there
is no point.  The only tremendously civilized Usenet is moderated Usenet.
Even then, I'm often surprised at what some moderators allow.

> Anyway, Python by itself is just not a very good language for low
> level performance oriented programming such as 3D programming. It is
> a very
> good language for high level concept oriented programming, however.
> It may help glueing together low level performance oriented things,
> as well. Perhaps considering it that way will be enlightening.

I agree.  Actually, this is all very circular for how this thread came to
be.

--
Cheers,                         www.3DProgrammer.com
Brandon Van Every               Seattle, WA

20% of the world is real.
80% is gobbledygook we make up inside our own heads.





More information about the Python-list mailing list