Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Python: Python

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

 

 

Python python RSS feed   Index | Next | Previous | View Threaded


xahlee at gmail

Mar 5, 2012, 5:11 PM

Post #1 of 15 (784 views)
Permalink
are int, float, long, double, side-effects of computer engineering?

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
--
http://mail.python.org/mailman/listinfo/python-list


breamoreboy at yahoo

Mar 5, 2012, 6:14 PM

Post #2 of 15 (782 views)
Permalink
Re: are int, float, long, double, side-effects of computer engineering? [In reply to]

On 06/03/2012 01:11, Xah Lee wrote:
> 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?

--
Cheers.

Mark Lawrence.

--
http://mail.python.org/mailman/listinfo/python-list


anikom15 at gmail

Mar 5, 2012, 7:17 PM

Post #3 of 15 (771 views)
Permalink
Re: are int, float, long, double, side-effects of computer engineering? [In reply to]

On Mon, Mar 05, 2012 at 05:11:09PM -0800, Xah Lee wrote:
> 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.
--
http://mail.python.org/mailman/listinfo/python-list


timr at probo

Mar 5, 2012, 9:26 PM

Post #4 of 15 (773 views)
Permalink
Re: are int, float, long, double, side-effects of computer engineering? [In reply to]

Xah Lee <xahlee [at] gmail> 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.
--
Tim Roberts, timr [at] probo
Providenza & Boekelheide, Inc.
--
http://mail.python.org/mailman/listinfo/python-list


xahlee at gmail

Mar 5, 2012, 10:34 PM

Post #5 of 15 (766 views)
Permalink
Re: are int, float, long, double, side-effects of computer engineering? [In reply to]

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.

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
--
http://mail.python.org/mailman/listinfo/python-list


russ.paielli at gmail

Mar 6, 2012, 12:02 AM

Post #6 of 15 (766 views)
Permalink
Re: are int, float, long, double, side-effects of computer engineering? [In reply to]

On Mar 5, 10:34pm, Xah Lee <xah...@gmail.com> wrote:
> On Mar 5, 9:26pm, 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


"chiron613.no.spam." at no

Mar 6, 2012, 2:00 AM

Post #7 of 15 (767 views)
Permalink
Re: are int, float, long, double, side-effects of computer engineering? [In reply to]

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?

--
A girl with a future avoids the man with a past.
-- Evan Esar, "The Humor of Humor"
--
http://mail.python.org/mailman/listinfo/python-list


"chiron613.no.spam." at no

Mar 6, 2012, 2:10 AM

Post #8 of 15 (779 views)
Permalink
Re: are int, float, long, double, side-effects of computer engineering? [In reply to]

On Mon, 05 Mar 2012 22:34:46 -0800, Xah Lee wrote:

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

--
You will be singled out for promotion in your work.
--
http://mail.python.org/mailman/listinfo/python-list


roy at panix

Mar 6, 2012, 5:49 AM

Post #9 of 15 (769 views)
Permalink
Re: are int, float, long, double, side-effects of computer engineering? [In reply to]

[intentionally violating the followup-to header]

In article <7ol5r.29957$zD5.14377 [at] newsfe12>,
Chiron <chiron613.no.spam.@no.spam.please.gmail.com> wrote:

> On Mon, 05 Mar 2012 22:34:46 -0800, Xah Lee wrote:
>
> > 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.

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.
--
http://mail.python.org/mailman/listinfo/python-list


reader at calvinkim

Mar 6, 2012, 1:29 PM

Post #10 of 15 (766 views)
Permalink
Re: are int, float, long, double, side-effects of computer engineering? [In reply to]

On 03/06/2012 01:34 AM, Xah Lee wrote:
> 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.



--
http://mail.python.org/mailman/listinfo/python-list


anikom15 at gmail

Mar 6, 2012, 4:53 PM

Post #11 of 15 (767 views)
Permalink
Re: are int, float, long, double, side-effects of computer engineering? [In reply to]

On Tue, Mar 06, 2012 at 04:29:10PM -0500, Calvin Kim wrote:
> On 03/06/2012 01:34 AM, Xah Lee wrote:
> >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.

Also remember that double precision is not the maximum. There exist
standards for triple and quadruple precision formats, as well as other
extended formats.
--
http://mail.python.org/mailman/listinfo/python-list


rustompmody at gmail

Mar 6, 2012, 7:25 PM

Post #12 of 15 (766 views)
Permalink
Re: are int, float, long, double, side-effects of computer engineering? [In reply to]

On Mar 6, 6:11am, Xah Lee <xah...@gmail.com> wrote:
> 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/Computable_number#Can_computable_numbers_be_used_instead_of_the_reals.3F
--
http://mail.python.org/mailman/listinfo/python-list


russ.paielli at gmail

Mar 7, 2012, 2:02 PM

Post #13 of 15 (765 views)
Permalink
Re: are int, float, long, double, side-effects of computer engineering? [In reply to]

On Mar 6, 7:25pm, rusi <rustompm...@gmail.com> wrote:
> On Mar 6, 6:11am, Xah Lee <xah...@gmail.com> wrote:
>
> > 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)
>
> 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.
--
http://mail.python.org/mailman/listinfo/python-list


albert at spenarnc

Mar 13, 2012, 3:40 AM

Post #14 of 15 (724 views)
Permalink
Re: are int, float, long, double, side-effects of computer engineering? [In reply to]

In article <5aaded58-af09-41dc-9afd-56d7b7ced239 [at] d7g2000pbl>,
Xah Lee <xahlee [at] gmail> wrote:
<SNIP>
>
>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

--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert [at] sp&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

--
http://mail.python.org/mailman/listinfo/python-list


nagle at animats

Mar 13, 2012, 10:32 PM

Post #15 of 15 (722 views)
Permalink
Re: are int, float, long, double, side-effects of computer engineering? [In reply to]

On 3/7/2012 2:02 PM, Russ P. wrote:
> On Mar 6, 7:25 pm, rusi<rustompm...@gmail.com> wrote:
>> On Mar 6, 6:11 am, Xah Lee<xah...@gmail.com> wrote:

> 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: "http://www.youtube.com/watch?v=5lHqEwk7YHs")
(A test with a heavy object:
"http://www.youtube.com/watch?v=-DaWIHc1VLY". Most physics engines
don't do heavy objects well. Everything looks too light. We call
this the "boink problem.")

John Nagle
--
http://mail.python.org/mailman/listinfo/python-list

Python python RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.