float / double support in Python?

[Martijn Faassen]

Brandon Van Every <vanevery at 3dprogrammer.com> wrote:
> 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.

No, I don't think any of those things; I usually don't worry about the 
amounts of bytes that go into the integers. By the way, in Python, integers
can grow infinitely large (if it fits in memory). I mean, just try 
1000 ** 100 in a Python 2.2.

Of course there are cases where I do worry, which is when I start taking
special care or go to a different level (like non-python).

What I was trying to point out with my direct translation of your statement
is that there are various different perspectives. Your perspective is one
of a low-level worrier. You have to if you want to write optimized 3d 
engines. I start worrying more low-level if I work on XML databases too.
But what python is frequently used for are domains where such worrying is
not very productive, and actually counterproductive as it costs time and
is not very useful in the problem domain.

>> 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.

I used to program in C++ but almost never use it anymore, so to me it has
a limited problem domain. For most of the problems I face during day to
day programming (and this is my job) I use Python. Again, this depends on
your perspective. I hope you will be able to understand other people's
perspective a bit better after my explanations. I do attempt to understand
your perspective. Try to realize that you're disagreeing with a simple 
rephrasing of your own controversial statement here (controversial to
most people's minds in comp.lang.python)..

Anyway, in low level 3d programming, or writing simulations which have to
go very fast, and various other problem domains, C++ has its place. It is
useful when you need efficiency or need to talk to hardware, while still 
having a reasonable power of abstraction.  The negative tradeoff is that writing
solid C++ time costs more time than writing solid code in some other
languages, like Python. Many people here advocate a mixed-language approach
trying to gain the benefits of both languages. This has its limitations
as you have to deal with the intermediary layer, but many people consider
it worth the expenditure of effort still, as they can stay in a more high
level language most of the time. The old adage is that 10% of the code costs
90% of the execution time. That other 90% of the code still has to be 
developed however, and it's not true that 10% of the code costs 90% of the
*development* time.

>> 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.

I think that by careful profiling and some creativity you can probably
get the bounadry between C++ and Python lower than you might think, but 
then again I don't know your problem domain that well. If all you care about
is low level 3d programming with an orientation towards performance then 
Python may only be interesting to you as a prototyping language, if that.
If you however have to write the other 90% (or more) of the application
as well, then Python may be interesting to you.

> 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.

>From the perspective of C++ Python is easier to use but it's definitely not
"still efficient". Mind that it's fast enough for a huge problem domain,
and that there are a lot of things you can do to help efficiency, but 
I'd say that from your perspective Python is dramatically slow. :)

>> 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.

Hm, I always find that when experimenting I get new ideas which profoundly
influence the implementation. If I can make the first few cycles go more
quickly without being bogged down by the intricacies of C++, then I may
win. Another possibility is that I discover in my experiments that things
are fast enough anyway in Python, so I can leave it alone then. But I'd 
think that is unlikely from a low level 3d performance perspective.

>> 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.

comp.lang.python has become more trigger-happy recently, and people are 
too prone to call someone a troll when they come from another perspective.
I wish they would do so less often, but then some of the more prominent
people in this group and python-dev are not giving great examples (I
can understand it more for python-dev, as they are trying to get work
done there). comp.lang.python used to be a very very friendly unmoderated
group, and is still pretty high quality overall, I'd say. Please give it
a chance and forget this is group is not moderated? It is sad to give
up on a group before you give it a good chance.

By the way, I, like many people, actually appreciate talking to people with
a working mind that actually care about the way they interact with other
people. I care less about interacting with someone who claims they don't
care about actually thinking for themselves or being polite to others.
I hope you understand this, even though you're likely to read this with a
less than optimally functioning mind. :)  A good first step would be to
stop using it as an excuse for being allowed to say 'duh' and similar
things.

I'll have to stop typing now before I start sounding like the 
martellibot! Normally my posts are less long and far far more silly..

Regards,

Martijn
-- 
History of the 20th Century: WW1, WW2, WW3?
No, WWW -- Could we be going in the right direction?