Services & Resources / Wolfram Forums
-----
 /
MathGroup Archive
2004
*January
*February
*March
*April
*May
*June
*July
*August
*September
*October
*November
*December
*Archive Index
*Ask about this page
*Print this page
*Give us feedback
*Sign up for the Wolfram Insider

MathGroup Archive 2004

[Date Index] [Thread Index] [Author Index]

Search the Archive

RE: Re: bug in IntegerPart ?

  • To: mathgroup at smc.vnet.net
  • Subject: [mg47946] RE: [mg47908] Re: bug in IntegerPart ?
  • From: "DrBob" <drbob at bigfoot.com>
  • Date: Sun, 2 May 2004 04:50:41 -0400 (EDT)
  • Sender: owner-wri-mathgroup at wolfram.com

Peter,

Mathematica already supports exact mathematics, as we all know. As Peltio
pointed out in another thread, the expression 34.123*89 can be entered as

N[Rationalize[34.123]*89,30]

3036.94700000000000000000000000

I'd probably use

N[(34123/1000)*89, 30]
3036.947`30.

or, better yet,

(34123/1000)*89
3036947/1000

It appears you recognize that machine arithmetic is needed for speed, at
least some of the time.

We have both arithmetic models available, so what's the problem?

Your quibble seems to be that exact arithmetic should be the default. Well,
maybe so, but it isn't. I can live with that because it's doubtful, when I
type in 34.123, that I actually know the number to infinitely many places
(or even five). If I do, it's because I derived it by dividing two integers.
In that case, there's no particular reason -- other than the space taken up
onscreen -- to prefer writing 34.123 rather than 34123/1000. Mathematically,
they're the same. If I don't know the number to more places than those I've
entered, it's misleading (and amateurish) to do arithmetic or present
results as if I did. It's also SLOW.

Almost all algebraic (and all transcendental) numbers are not representable
as terminating decimals, so it seems natural (to me) to think of decimals as
approximate. Rational fractions and radicals of integers "look" exact.
Decimals don't.

I think, in a few years, the need for speed will be less pressing, and
changing the default may be attractive. Like it or not, it will be up to
developers to decide if, and when, that time has come.

Meanwhile, if another system does it better, why not use it? The members of
this group can't rewrite Mathematica to your specifications, even if we
wanted to.

DrBob

www.eclecticdreams.net


-----Original Message-----
From: AC [mailto:ancow65 at yahoo.com] 
To: mathgroup at smc.vnet.net
Subject: [mg47946] [mg47908] Re: bug in IntegerPart ?

I have feeling speaking to deaf ears. Let me try again.

On one hand, there is mathematics with all these wonderful and precise
ideas. On other hand are computer programs that model (sic!) these
ideas on computer. I have impression that some of us got some much
involved with programs that forgot that they are just projections of
mathematical ideas. In mathematics 1.3 is an exact number. Decimals
can be represented on computer in number of ways. IEEE representation
is only one of many. Contrary to the belief of posters, there are
known ways to represent decimal numbers on computer EXACTLY. Just as
there are big integers, there are also big floats available in number
of languages or programs. Sorry, the charter of this group does not
allow me to list their names.  There is no apparent reason, why
Mathematica could not do the same. Additionally, there are indeed
numbers that are known only approximately and there are methods to
perform computations with such. Interval arithmetic is notably one of
such methods. As long as Mathematica's numerical model mixes these two
classes, there will side effects and confusion. I am trying to say
that the system can be improved relatively easily, the methods are
known, and the only missing factor will.  I made a constructive
suggestion. (1) Treat all decimals as exact numbers. In this way
number of problems arising on the border between Machine Precision and
Big Number Arithmetic would disappear. The mapping between decimals in
mathematics and Mathematica would become bijection. (2) Introduce a
new notation or alternatively a programming switch for inexact numbers
that would follow IEEE rules. Both developers and users will have
precision or speed as needed without compromising mathematical clarity
and precision.

AC




  • Prev by Date: Re: bug in IntegerPart ?
  • Next by Date: Re: Re: bug in IntegerPart ?
  • Previous by thread: Re: bug in IntegerPart ?
  • Next by thread: Re: Re: bug in IntegerPart ?