Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #21245 > unrolled thread

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

Back to article view | Back to comp.lang.python

Contents

  are int, float, long, double, side-effects of computer engineering? Xah Lee <xahlee@gmail.com> - 2012-03-05 17:11 -0800
    Re: are int, float, long, double, side-effects of computer engineering? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-03-06 02:14 +0000
    Re: are int, float, long, double, side-effects of computer engineering? Westley Martínez <anikom15@gmail.com> - 2012-03-05 19:17 -0800
    Re: are int, float, long, double, side-effects of computer engineering? Tim Roberts <timr@probo.com> - 2012-03-05 21:26 -0800
      Re: are int, float, long, double, side-effects of computer engineering? Xah Lee <xahlee@gmail.com> - 2012-03-05 22:34 -0800
        Re: are int, float, long, double, side-effects of computer engineering? "Russ P." <russ.paielli@gmail.com> - 2012-03-06 00:02 -0800
        Re: are int, float, long, double, side-effects of computer engineering? Chiron <chiron613.no.spam.@no.spam.please.gmail.com> - 2012-03-06 10:10 +0000
          Re: are int, float, long, double, side-effects of computer engineering? Roy Smith <roy@panix.com> - 2012-03-06 08:49 -0500
        Re: are int, float, long, double, side-effects of computer engineering? Calvin Kim <reader@calvinkim.org> - 2012-03-06 16:29 -0500
        Re: are int, float, long, double, side-effects of computer engineering? Westley Martínez <anikom15@gmail.com> - 2012-03-06 16:53 -0800
        Re: are int, float, long, double, side-effects of computer engineering? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-03-06 21:51 -0500
        RE: are int, float, long, double, side-effects of computer engineering? "Prasad, Ramit" <ramit.prasad@jpmorgan.com> - 2012-03-07 19:05 +0000
    Re: are int, float, long, double, side-effects of computer engineering? Chiron <chiron613.no.spam.@no.spam.please.gmail.com> - 2012-03-06 10:00 +0000
    Re: are int, float, long, double, side-effects of computer engineering? rusi <rustompmody@gmail.com> - 2012-03-06 19:25 -0800
      Re: are int, float, long, double, side-effects of computer engineering? "Russ P." <russ.paielli@gmail.com> - 2012-03-07 14:02 -0800
        Re: are int, float, long, double, side-effects of computer engineering? John Nagle <nagle@animats.com> - 2012-03-13 22:32 -0700
    Re: are int, float, long, double, side-effects of computer engineering? Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-03-13 10:40 +0000

#21245 — 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

[toc] | [next] | [standalone]

#21248

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.

[toc] | [prev] | [next] | [standalone]

#21256

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.

[toc] | [prev] | [next] | [standalone]

#21257

Xah Lee <xahlee@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.
-- 
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

[toc] | [prev] | [next] | [standalone]

#21258

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

[toc] | [prev] | [next] | [standalone]

#21260

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.

[toc] | [prev] | [next] | [standalone]

#21262

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.

[toc] | [prev] | [next] | [standalone]

#21267

[intentionally violating the followup-to header]

In article <7ol5r.29957$zD5.14377@newsfe12.iad>,
 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.

[toc] | [prev] | [next] | [standalone]

#21285

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.

[toc] | [prev] | [next] | [standalone]

#21295

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.

[toc] | [prev] | [next] | [standalone]

#21300

On Tue, 06 Mar 2012 16:29:10 -0500, Calvin Kim <reader@calvinkim.org>
declaimed the following in gmane.comp.python.general:


> 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.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#21330

Dennis Lee Bieber wrote: 

> 	It wouldn't surprise me to find out that 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 I cannot 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.  

[toc] | [prev] | [next] | [standalone]

#21261

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"

[toc] | [prev] | [next] | [standalone]

#21301

On Mar 6, 6:11 am, 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

[toc] | [prev] | [next] | [standalone]

#21356

On Mar 6, 7:25 pm, rusi <rustompm...@gmail.com> wrote:
> On Mar 6, 6:11 am, 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.

[toc] | [prev] | [next] | [standalone]

#21589

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

[toc] | [prev] | [next] | [standalone]

#21559

In article <5aaded58-af09-41dc-9afd-56d7b7ced239@d7g2000pbl.googlegroups.com>,
Xah Lee  <xahlee@gmail.com> 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@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web