On Mar 5, 10:34 pm, Xah Lee <xah...@gmail.com> wrote: > On Mar 5, 9:26 pm, Tim Roberts <t...@probo.com> wrote: > > > Xah Lee <xah...@gmail.com> 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 applications. -- http://mail.python.org/mailman/listinfo/python-list
