are int, float, long, double, side-effects of computer engineering?

Russ P. russ.paielli at
Tue Mar 6 09:02:22 CET 2012

On Mar 5, 10:34 pm, Xah Lee <xah... at> wrote:
> On Mar 5, 9:26 pm, Tim Roberts <t... at> wrote:
> > Xah Lee <xah... at> wrote:
> > >some additional info i thought is relevant.
> > >are int, float, long, double, side-effects of computer engineering?
> > Of course they are.  Such concepts violate the purity of a computer
> > language's abstraction of the underlying hardware.  We accept that
> > violation because of performance reasons.  There are, as you point out,
> > languages that do maintain the purity of the abstraction, but that purity
> > is ALWAYS at the expense of performance.
> > I would also point out pre-emptively that there is nothing inherently wrong
> > with asking us to accept an impure abstraction in exchange for performance.
> > It is a performance choice that we choose to make.
> while what you said is true, but the problem is that 99.99% of
> programers do NOT know this. They do not know Mathematica. They've
> never seen a language with such feature. The concept is alien. This is
> what i'd like to point out and spread awareness.

I seriously doubt that. I think most decent programmers are well aware
of the limitations of floating point math. If properly used, double-
precision arithmetic is more than adequate for the vast majority of
practical scientific and engineering problems.

> also, argument about raw speed and fine control vs automatic
> management, rots with time. Happened with auto memory management,
> managed code, compilers, auto type conversion, auto extension of
> array, auto type system, dynamic/scripting languages, etc.

First of all, "dynamic/scripting languages" are still a long, long way
from being "fast enough" for computationally intensive applications.

Secondly, nothing is stopping anyone from writing a library to
implement rational numbers or infinite-precision arithmetic in python
(or just about any other language). They are just not needed for most

More information about the Python-list mailing list