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

[Xah Lee]

some additional info i thought is relevant.

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

Xah Lee wrote:
«… One easy way to measure it is whether a programer can read and
understand a program without having to delve into its idiosyncrasies.
…»

Chris Angelico wrote:
«Neither the behavior of ints nor the behavior of IEEE floating point
is a "quirk" or an "idiosyncracy". …»

they are computer engineering by-products. Are quirks and
idiosyncracies. Check out a advanced lang such as Mathematica. There,
one can learn how the mathematical concept of integer or real number
are implemented in a computer language, without lots by-products of
comp engineering as in vast majority of langs (all those that chalks
up to some IEEEEEEE. (which, sadly, includes C, C++, perl, python,
lisp, and almost all. (Common/Scheme lisp idiots speak of the jargon
“number tower” instead IEEEE.) (part of the reason almost all langs
stick to some IEEEEEEEE stuff is because it's kinda standard, and
everyone understand it, in the sense that unix RFC (aka really fucking
common) is wide-spread because its free yet technically worst. (in a
sense, when everybody's stupid, there arise a cost to not be
stupid.)))).


A friend asked: «Can you enlighten us as to Mathematica's way of
handling numbers, either by a post or a link to suitable
documentation? …»

what i meant to point out is that Mathematica deals with numbers at a
high-level human way. That is, one doesn't think in terms of float,
long, int, double. These words are never mentioned. Instead, you have
concepts of machine precision, accuracy. The lang automatically handle
the translation to hardware, and invoking exact value or infinite
precision as required or requested.

in most lang's doc, words like int, long, double, float are part of
the lang, and it's quick to mention IEEE. Then you have the wide-
spread overflow issue in your lang. In M, the programer only need to
think in terms of math, i.e. Real number, Integer, complex number,
precision, accuracy, etc.

this is what i meat that most lang deals with computer engineering by-
products, and i wished them to be higher level like M.

http://reference.wolfram.com/mathematica/guide/PrecisionAndAccuracyControl.html

Xah

 

[Mark Lawrence]

some additional info i thought is relevant.

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

Whatever you're taking please can I have some? Is it available via an
NHS prescription or do I have to go private, or do I go down the pub and
get it illegally?

 

[Westley Martínez]

some additional info i thought is relevant.

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

Xah Lee wrote:
«… One easy way to measure it is whether a programer can read and
understand a program without having to delve into its idiosyncrasies.
…»

Chris Angelico wrote:
«Neither the behavior of ints nor the behavior of IEEE floating point
is a "quirk" or an "idiosyncracy". …»

they are computer engineering by-products. Are quirks and
idiosyncracies. Check out a advanced lang such as Mathematica. There,
one can learn how the mathematical concept of integer or real number
are implemented in a computer language, without lots by-products of
comp engineering as in vast majority of langs (all those that chalks
up to some IEEEEEEE. (which, sadly, includes C, C++, perl, python,
lisp, and almost all. (Common/Scheme lisp idiots speak of the jargon
“number tower†instead IEEEE.) (part of the reason almost all langs
stick to some IEEEEEEEE stuff is because it's kinda standard, and
everyone understand it, in the sense that unix RFC (aka really fucking
common) is wide-spread because its free yet technically worst. (in a
sense, when everybody's stupid, there arise a cost to not be
stupid.)))).


A friend asked: «Can you enlighten us as to Mathematica's way of
handling numbers, either by a post or a link to suitable
documentation? …»

what i meant to point out is that Mathematica deals with numbers at a
high-level human way. That is, one doesn't think in terms of float,
long, int, double. These words are never mentioned. Instead, you have
concepts of machine precision, accuracy. The lang automatically handle
the translation to hardware, and invoking exact value or infinite
precision as required or requested.

in most lang's doc, words like int, long, double, float are part of
the lang, and it's quick to mention IEEE. Then you have the wide-
spread overflow issue in your lang. In M, the programer only need to
think in terms of math, i.e. Real number, Integer, complex number,
precision, accuracy, etc.

this is what i meat that most lang deals with computer engineering by-
products, and i wished them to be higher level like M.

http://reference.wolfram.com/mathematica/guide/PrecisionAndAccuracyControl.html

Try Fortran.

 

[Xah Lee]

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.

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.

i'd share this these talks:

〈Programing Language: Steve Yegge on Dynamic Languages〉
http://xahlee.org/comp/Steve_Yegge_on_dynamic_languages.html

〈Guy Steele on Parallel Programing: Get rid of cons!〉
http://xahlee.org/comp/Guy_Steele_parallel_computing.html

〈Ocaml Use in Industry (Janestreet Talk by Yaron Minsky)〉
http://xahlee.org/comp/Yaron_Minsky_Janestreet_talk.html

〈Stephen Wolfram: The Background and Vision of Mathematica 〉
http://xahlee.blogspot.com/2011/10/stephen-wolfram-background-and-vision.html

Xah

 

[Russ P.]

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.

 

[Chiron]

On Mon, 05 Mar 2012 17:11:09 -0800, Xah Lee wrote:

Yes.

Why do you ask? Is this not obvious?

Was this a rhetorical question?

 

[Chiron]

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

Could you please offer some evidence to support this claim? Most of the
programmers I've ever run into, were quite familiar with the notion that
many aspects of their languages were artifacts of hardware limitations.
You don't need Mathematica to figure out that (10.0 * 0.1) - 1.0 doesn't
often equal 0.0. The moment you try such comparisons with floats, you
figure it out. Oh, granted - the *first* time you try it, you might
spend days trying to understand what's wrong. But having done that, you
will never, ever fail to understand about the evils of computer
engineering.

Anyway, most programmers probably get burned like this early on, if they
forget that numeric representations in most languages are inaccurate.
They don't need Mathematica to help them understand.

BTW, for those who don't have access to Mathematica, I highly recommend
sagemath. I have no way of making a comparison between the two (I have
no access to Mathematica), but sagemath is mature, useful, and fast.

 

[Roy Smith]

[intentionally violating the followup-to header]

Could you please offer some evidence to support this claim? Most of the
programmers I've ever run into, were quite familiar with the notion that
many aspects of their languages were artifacts of hardware limitations.

While I doubt Xah's claim that 99.99% of programmers are unaware of
this, oddly enough, we ran across an instance of this just yesterday.
We have a test problem we give to job candidates:

Write a program that counts the number of times the subsequence "1, 2, 3"
appears in the first 100,000 digits of pi. Note "subsequence" does not imply
consecutive digits. For example, "1, 2, 3" appears in "3.141592653" twice.
You may use Google or the link above to find the digits of pi. Please include
the correct count when submitting your application.

We had a candidate submit a solution in Python which ran in O(n) time.
The algorithm was essentially correct, but unfortunately, he used a
numpy.array to hold some counters, and suffered integer overflow. Had
he used regular python lists, he would have been fine.

What's unclear (at the moment) is whether he falls into Xah's camp of
people who are unaware of such issues (unlikely, IMHO). Possibly he
just didn't realize that the numbers in this problem might get big
enough to overflow a 32-bit int. Or had been lulled into a false sense
of security knowing that python does arbitrary precision integer math
and didn't realize that doesn't extend to numpy.

 

[Calvin Kim]

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 can see your point. But that's not simply true. In my case and many
others, such issue was addressed during first week of introductory
programming classes. I was naively thought "computer = precision" and I
was stunned to find out the inaccuracy of computer calculations.

But as you experienced, I also stumble upon some people (specially Java
only programmers) who were not aware of it.

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.

Maybe it's because I'm not in scientific community, that I learned to
live with such side-effects. Because 99.99% of computer users and
programmers can afford to, and willing to lose such small inaccuracy
billion times in exchange for some performance increase and convenience.
Although NASA may not accept my application for their projects for Mars
mission after this posting.

 

[Westley Martínez]

I can see your point. But that's not simply true. In my case and
many others, such issue was addressed during first week of
introductory programming classes. I was naively thought "computer =
precision" and I was stunned to find out the inaccuracy of computer
calculations.

But as you experienced, I also stumble upon some people (specially
Java only programmers) who were not aware of it.

Maybe it's because I'm not in scientific community, that I learned
to live with such side-effects. Because 99.99% of computer users and
programmers can afford to, and willing to lose such small inaccuracy
billion times in exchange for some performance increase and
convenience. Although NASA may not accept my application for their
projects for Mars mission after this posting.

Also remember that double precision is not the maximum. There exist
standards for triple and quadruple precision formats, as well as other
extended formats.

 

[Dennis Lee Bieber]

I can see your point. But that's not simply true. In my case and many
others, such issue was addressed during first week of introductory
programming classes. I was naively thought "computer = precision" and I
was stunned to find out the inaccuracy of computer calculations.

But as you experienced, I also stumble upon some people (specially Java
only programmers) who were not aware of it.

It wouldn't surprise me to find out that modern CompSci degrees
don't even discuss machine representation of numbers. In contrast I
recall having an assignment, in my assembly class I think, to emulate
the floating point operations using integer operations and bit
manipulation. Somewhat fun as the Sigma-6 used a rather unusual
"exponent" (base-16... a normalized binary mantissa could have up to
three 0-bits)

Maybe it's because I'm not in scientific community, that I learned to
live with such side-effects. Because 99.99% of computer users and

And, as I learned "science", results should not exceed the precision
of the input -- if the input (physical measurements) only had 5
significant figures, any output beyond 5 significant figures was noise.
Granted, some of the internal number crunching might need
double-precision (orbital position propagation, say), but the printed
results would only be to the level of the initial measurements.

 

[rusi]

some additional info i thought is relevant.

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

It is a bit naive for computer scientists to club integers and reals
as mathematicians do given that for real numbers, even equality is
undecidable!
Mostly when a system like mathematica talks of real numbers it means
computable real numbers which is a subset of mathematical real numbers
(and of course a superset of floats)

See
http://en.wikipedia.org/wiki/Comput...table_numbers_be_used_instead_of_the_reals.3F

 

[Prasad, Ramit]

Dennis Lee Bieber wrote:

It wouldn't surprise me to find outthat modern CompSci degrees
don't even discuss machine representation of numbers.

As a fairly recent graduate, I can assure you that they still do.
Well, I should say at least my school did since Icannot speak
for every other school.

Ramit


Ramit Prasad | JPMorgan Chase Investment Bank | Currencies Technology
712 Main Street | Houston, TX 77002
work phone: 713 - 216 - 5423

--

This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.

 

[Russ P.]

It is a bit naive for computer scientists to club integers and reals
as mathematicians do given that for real numbers, even equality is
undecidable!
Mostly when a system like mathematica talks of real numbers it means
computable real numbers which is a subset of mathematical real numbers
(and of course a superset of floats)

Seehttp://en.wikipedia.org/wiki/Computable_number#Can_computable_numbers....

I might add that Mathematica is designed mainly for symbolic
computation, whereas IEEE floating point numbers are intended for
numerical computation. Those are two very different endeavors. I
played with Mathematica a bit several years ago, and I know it can do
numerical computation too. I wonder if it resorts to IEEE floating
point numbers when it does.

 

[Albert van der Horst]

what i meant to point out is that Mathematica deals with numbers at a
high-level human way. That is, one doesn't think in terms of float,
long, int, double. These words are never mentioned. Instead, you have
concepts of machine precision, accuracy. The lang automatically handle
the translation to hardware, and invoking exact value or infinite
precision as required or requested.

With e.g. a vanderMonde matrix you can easily make Mathematica fail.
If you don't understand what a condition number is, you can't use
Mathematica. And yes condition numbers are fully in the realm
of concepts of machine precisions and accuracy.

Infinite precision takes infinite time. Approaching infinite precious
may take exponentional time.

Xah

Groetjes Albert

 

[John Nagle]

I might add that Mathematica is designed mainly for symbolic
computation, whereas IEEE floating point numbers are intended for
numerical computation. Those are two very different endeavors. I
played with Mathematica a bit several years ago, and I know it can do
numerical computation too. I wonder if it resorts to IEEE floating
point numbers when it does.

Mathematica has, for some computations, algorithms to determine the
precision of results. This is different than trying to do infinite
precision arithmetic, which doesn't help as soon as you get to trig
functions. It's about bounding the error.

It's possible to do bounded arithmetic, where you carry along an
upper and lower bound on each number. The problem is what to do
about comparisons. Comparisons between bounded numbers are
ambiguous when the ranges overlap. Algorithms have to be designed
to deal with that. Mathematica has such algorithms for some
operations, especially numerical integration.

It's a very real issue. I had to deal with this when I was
writing the first "ragdoll physics" system that worked right,
back in the 1990s. Everybody else's system blew up on the hard
cases; mine just slowed down. Correct integration over a force
function that's changing over 18 orders of magnitude is difficult,
but quite possible.

(Here it is, from 1997: "

")
(A test with a heavy object:
"

". Most physics engines
don't do heavy objects well. Everything looks too light. We call
this the "boink problem.")

John Nagle