C:\Objective Caml\Bin>ocamlopt.opt -S -o grtest.exe graphics.cmx grtest.ml
LINK: fatal error LNK1181: cannot open input file 'C:\Objective
Caml\lib\graphics.obj'
Error during linking

Dear everyone

Happy new year

Can somebody tell me how I can represent positive infinity float number
in Ocaml?

Is there such symbol in Ocaml library?

Best regards
Zhifeng sheng

Dear everyone

Happy new year

Can somebody tell me how I can represent infinity float number?

Is there such notation in the Ocaml library?

Best regards
Zhifeng Sheng

On Friday 06 January 2006 14:31, Zhifeng Sheng wrote:
> Can somebody tell me how I can represent positive infinity float number
> in Ocaml?

$ ocaml
         Objective Caml version 3.08.4

# infinity;;
- : float = infinity

--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

On Jan 6, 2006, at 7:29 AM, Jon Harrop wrote:

> $ ocaml
>         Objective Caml version 3.08.4
>
> # infinity;;
> - : float = infinity

And it's neg_infinity for negative infinity.  It's all in the manual,
in the floating-point arithmetic part of the section on the
Pervasives module <http://caml.inria.fr/pub/docs/manual-ocaml/libref/
Pervasives.html>.

William D. Neumann

"I eat T-bone steaks, I lift barbell plates, I'm sweeter than a
German chocolate cake. I'm the reflection of perfection, the number
one selection. I'm the man of the hour, the man with the power, too
sweet to be sour. The ladies' pet, the men's regret, where what you
see is what you get, and what you don't see, is better yet."

           --Superstar Billy Graham

On Fri, 6 Jan 2006, Zhifeng Sheng wrote:

> Dear everyone
>
> Happy new year
>
> Can somebody tell me how I can represent infinity float number?
>
> Is there such notation in the Ocaml library?

Yes:

# infinity;;
- : float = infinity
# neg_infinity;;
- : float = neg_infinity


--
Martin Jambon, PhD
http://martin.jambon.free.fr

Visit http://wikiomics.org, the Bioinformatics Howto Wiki

Hi,
      This function was supposed to be an implementation of  simpson's rule for
integration, but the Ocaml interpreter won't accept  it; can anyone find
anything wrong with it?

   let simp xmin xmax n f =
           let h = float (xmax - xmin)/.(float n) in
           let gosimp sum x i n f =
               if i >= n then ()
               else
                   let rem z y = z -z/y*y in
                       let m =
                              match  (rem i 2) with
                           0-> 4. |
                            _ ->  2.  in
                       sum := !sum +. m*.(f x);
                   gosimp sum (x + h) (i + 1) n f
           in gosimp (ref 0.) (xmin + h) 2 n f;
           sum := !sum +. (f xmax) +. (f xmin); !sum/.3.;;

   here f is the function, n is the number of subdivisions.


   Also does anyone know a built-in modular function? Like 5%2 in the C
programming language.


   thanks a lot in advance,
   Jerry


---------------------------------
Yahoo! Photos
  Got holiday prints? See all the ways to get quality prints in your hands ASAP.

[Non-text portions of this message have been removed]

Well...

I got:
   "Unbound value gosimp"

So, you better define the functions you want to use..

the first problem seems to be: you call a function inside itself:
you have to use "let rec" instead of "let" for the "gosimp" function.

After fixing that, you should look at what type your
values shoukd have!

I got a lot of type-problems, but it's best you clarify for yourself,
which are necessarily int and which are float-values and
then corrct the sources.

Ciao,
    Oliver

On Sat, 7 Jan 2006, Oliver Bandel wrote:

> Well...
>
> I got:
>  "Unbound value gosimp"
>
> So, you better define the functions you want to use..
>
> the first problem seems to be: you call a function inside itself:
> you have to use "let rec" instead of "let" for the "gosimp" function.
>
> After fixing that, you should look at what type your
> values shoukd have!
>
> I got a lot of type-problems, but it's best you clarify for yourself,
> which are necessarily int and which are float-values and
> then corrct the sources.

All of which are correct- there are several places where it looks like
he's using + and - (integer addition and subtraction) when he needs to be
using +. and -. (floating point addition and subtraction).  These will
show up as type errors.

I'd also point out the mod operator, for integer modulo, as an answer to
his second question.

Brian

I'd also point out the mod operator, for integer modulo, as an answer to
   his second question.

   Brian



   Can you give example as to how to use the mod operator?  I tried
   mod 5 3, rem 5 3, 5%2 etc.

   thanks,
   Jerry



---------------------------------
Yahoo! Photos
  Got holiday prints? See all the ways to get quality prints in your hands ASAP.

[Non-text portions of this message have been removed]

mod is a special, infix function. same with lsl, asr, lsr, lor, land,
and lxor (think that's them all).

so: 5 mod 2

On Fri, Jan 06, 2006 at 09:51:09PM -0600, Brian Hurt wrote:
>
>
> On Sat, 7 Jan 2006, Oliver Bandel wrote:
>
> > Well...
> >
> > I got:
> >  "Unbound value gosimp"
> >
> > So, you better define the functions you want to use..
> >
> > the first problem seems to be: you call a function inside itself:
> > you have to use "let rec" instead of "let" for the "gosimp" function.
> >
> > After fixing that, you should look at what type your
> > values shoukd have!
> >
> > I got a lot of type-problems, but it's best you clarify for yourself,
> > which are necessarily int and which are float-values and
> > then corrct the sources.
>
> All of which are correct-

No.

> there are several places where it looks like
> he's using + and - (integer addition and subtraction) when he needs to be
> using +. and -. (floating point addition and subtraction).  These will
> show up as type errors.

These ARE type errors.

An "int" is not a "float", it's a different type.


>
> I'd also point out the mod operator, for integer modulo, as an answer to
> his second question.

Second question?
Didn't remembre there was one. ;-(


Ciao,
    Oliver

Hey,
       Thanks for answering my last question, I finally got  the 1-D simpson's
method working, but when I extended it to 2-D with  the following code, I got a
mysterious error message:
   """
   Characters 395-396:
                 in go2simp sum (xmin +. h) 2 n f;
                                      ^
   This expression has type float but is here used with type int
   """

   but after staring at my code for about an hour, I still don't see any type
errors here. Here's entire code


    let twosimp xmin xmax ymin ymax n f =
       let h = (xmax -. xmin)/.n in
           let sum = ref 0. in
               let rec go2simp sum x i n f =
                   if i >= n then ()
                   else
                       let m =
                            match (i mod 2) with
                                0 ->  4. |
                                _ ->  2. in
                            let oneint y = simp (ymin  y) (ymax y) n (f y) in
                                sum :=  !sum +. m*.(oneint x);
                            go2simp sum (x +. h) (i +  1) n f
               in go2simp sum (xmin +. h) 2 n f;
           sum := !sum +. (oneint xmax) +. (oneint xmin);
           !sum*.h/.3.;;



   Here's the new code for simp if that matters
   let simp xmin xmax n f =
           let h = (xmax -. xmin)/.(float n) in
           let sum = ref 0. in
               let rec gosimp sum x i n f =
                   if i >= n then ()
                   else
                       let rem z y = z -z/y*y in
                       let m =
                              match  (rem i 2) with
                           0-> 4. |
                            _ ->  2.  in
                       sum := !sum +. m*.(f x);
                   gosimp sum (x +. h) (i + 1) n f
               in gosimp sum (xmin +. h) 2 n f;
           sum := !sum +. (f xmax) +. (f xmin); !sum*.h/.3.;;


   thanks a lot in advance,
   Jerry



---------------------------------
  Yahoo! DSL Something to write home about. Just $16.99/mo. or less

[Non-text portions of this message have been removed]

On Jan 7, 2006, at 8:33 AM, Jerry He wrote:

>   Characters 395-396:
>                 in go2simp sum (xmin +. h) 2 n f;
>                                      ^
>   This expression has type float but is here used with type int

What's the code for go2simp?  Or more importantly, what is its type
signature?  Let's see: You declare let rec go2simp sum x i n f, but
also have match (i mod 2) with ... inside it, which means that i is
an int, and thus the second argument to go2simp is an int.

However, the expression (xmin +. h) has type float (inferred from the
use of +. and the earlier expression let h = (xmax -. xmin)/.n in),
but you are using it in a place that expects an int.  Hence the error.

William D. Neumann

"I eat T-bone steaks, I lift barbell plates, I'm sweeter than a
German chocolate cake. I'm the reflection of perfection, the number
one selection. I'm the man of the hour, the man with the power, too
sweet to be sour. The ladies' pet, the men's regret, where what you
see is what you get, and what you don't see, is better yet."

           --Superstar Billy Graham

Jerry He <rebound1618@...> writes:
>   This expression has type float but is here used with type int
Isn't the hint given by the compiler quite accurate? It says you pass a
float value to some parameter which is supposed to be a int.

  - According to expression "let h = (xmax -. xmin)/.n in", the compiler
    knows that the "n", the 5th parameter of twosimp,  is a float.
  - Inside your definition of go2simp, according to "i mod 2" it knows
    "i" is int, then according to "i >= n" it know "n" is also int. Hence
    the 4th parameter of go2simp should be int. (You can draw the same
    conclusion from the type of "simp" whose 3rd parameter should be int)
  - Finally, in the line where the compiler complains, you pass the 5th
    argument of twosimp "n" to directly instantiate the 4th parameter of
    gosimp, hence the types vary here.

Wish it helps.

code17

>   """
>
>   but after staring at my code for about an hour, I still don't see any type
errors here. Here's entire code
>
>
>    let twosimp xmin xmax ymin ymax n f =
>       let h = (xmax -. xmin)/.n in
>           let sum = ref 0. in
>               let rec go2simp sum x i n f =
>                   if i >= n then ()
>                   else
>                       let m =
>                            match (i mod 2) with
>                                0 ->  4. |
>                                _ ->  2. in
>                            let oneint y = simp (ymin  y) (ymax y) n (f y) in
>                                sum :=  !sum +. m*.(oneint x);
>                            go2simp sum (x +. h) (i +  1) n f
>               in go2simp sum (xmin +. h) 2 n f;
>           sum := !sum +. (oneint xmax) +. (oneint xmin);
>           !sum*.h/.3.;;

Wish it helps.

   code17
It helps alot, thanks!

   -Jerry



---------------------------------
Yahoo! Photos – Showcase holiday pictures in hardcover
  Photo Books. You design it and we’ll bind it!

[Non-text portions of this message have been removed]

Hello, list

Not sure whether the following problem belongs to OCaml or general UNIX
issues:

Suppose I have two file_descr already exist, in_fd for reading, out_fd
for writing. What I'm doing is keeping reading from in_fd then writing
the contents to out_fd, i.e. my program acts like a pipe between two
worlds.

What I'm thinking is whether there exist a direct abstraction (as well
as primitive) in OCaml or maybe in the system layer, for connecting two
file_descr instead of keeping my program looping and working, so my
program can delegate this task to system.

Note that:

  - A pipe generated by Unix.pipe is two file_descr, in which the data
    flows from out_fd to in_fd, and the program itself is outside of this
    pipe. But in my case, the data flows from in_fd to out_fd, and the
    program itself is inside this pipe. The data actually being piped can
    be considered from the output file_descr behind in_fd in one world,
    and to the input_descr behind out_fd in the other world.

   potential output --|-> in_fd ---my-program--> out_fd --|-> potential input

  - I guess there could be clever solution if the in_fd and out_fd can be
    mutably manipulated. However it seems impractical in my case, the both
    worlds I'm trying to communicate are not programed by myself, hence
    some tricks that are playable with forked process won't work here.

Any suggestions? or this is just impossible in OCaml (or UNIX) ?

Thanks

- code17

I'm addressing this from the Unix side of things.

In <871wzjvctm.fsf@...>, code17 <code17@...> typed:
> Suppose I have two file_descr already exist, in_fd for reading, out_fd
> for writing. What I'm doing is keeping reading from in_fd then writing
> the contents to out_fd, i.e. my program acts like a pipe between two
> worlds.

Well, BSD has sendfile, which copies data from a regular file to a
socket. That has some possibilities, but I haven't played with it a
lot to see how flexible it is.

>   potential output --|-> in_fd ---my-program--> out_fd --|-> potential input
>
>  - I guess there could be clever solution if the in_fd and out_fd can be
>    mutably manipulated. However it seems impractical in my case, the both
>    worlds I'm trying to communicate are not programed by myself, hence
>    some tricks that are playable with forked process won't work here.

Well, if the two worlds read from stdin or stdout, then you can
manipulate that part of their environment after forking before you
exec them. If they open files by names that you get to give them, then
you can do things with Unix domain sockets and fd file systems to
control what they get when they open the files.

	 <mike
--
Mike Meyer <mwm@...>  http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.

Hi all,
         I just installed Ocaml 3.09.0 Mingw and I have Cygwin, but when I tried
to do
   ocamlopt filename.ml, it gave me thie error message:
       "E:\OCaml\lib/pervasives.cmx is not a compilation unit description."

   Any ideas on how to fix that?

   thanks in advance,
   Jerry




---------------------------------
Yahoo! Photos
  Got holiday prints? See all the ways to get quality prints in your hands ASAP.

[Non-text portions of this message have been removed]

On Fri, 6 Jan 2006, Jerry He wrote:

>
>  I'd also point out the mod operator, for integer modulo, as an answer to
>  his second question.
>
>  Brian
>
>
>
>  Can you give example as to how to use the mod operator?  I tried
>  mod 5 3, rem 5 3, 5%2 etc.

It's an operator, so:
$ ocaml
          Objective Caml version 3.08.2

# 5 mod 3;;
- : int = 2
#

Brian

Mike Meyer <mwm-keyword-ocaml.8afb38@...> writes:
> I'm addressing this from the Unix side of things.
Thanks for the hint.
> Well, if the two worlds read from stdin or stdout, then you can
> manipulate that part of their environment after forking before you
> exec them.
If I understand correctly, you are actually suggesting I open the two
worlds with specific file_descr instead of their stdin stdout (which is
the exact behavior of Unix.create_process, I don't know whether this
function is just a shortcut of what you've said "first fork; then set
file_descr; then exec" but seems to be similar). Unfortunately, I've
emphasized in my title that the file_descr are *already exist*. To be
clearer, suppose the left world is actually the input system of my
program:

in previous post
>> potential output --|-> in_fd ---my-program--> out_fd --|-> potential input

now clearer
     keystroke etc --|-> my_stdin --- my-prog --> out_fd --|-> potential input

in such a case, I can't do much things to my stdin (which is obviously
already exist), otherwise I won't be able to receive information
outside; nor can I fork the right side world by giving my stdin as its
stdin, because it's also *already* forked with other file_descr (so that
I can do some other interaction with it beforehand -- before I really
want to pipe the two worlds).

> If they open files by names that you get to give them, then
> you can do things with Unix domain sockets and fd file systems to
> control what they get when they open the files.

I don't know much UNIX programming. But if you're talking about the
functionality provided by Unix.mkfifo, the named pipe in OCaml, then my
problem still exists for the same reason.

Maybe this is just impossible in *nix? I mean, anyway, I can do it by
keeping reading and writing with no doubt, the problem is that whether
doing it this way is quite silly and there exists some clever magic I
don't know, or this is the only choice _under_such_a_situation_ ?


- code17

Hi,

I'm trying to figure out how I can declare two classes where each needs
to know the others type.  This is a rough illustration, but I want to
do something like this:


let firstObject =
   object
     val mutable secondObject  = None

     method setSecondObject theObject  =
       match secondObject with
         None  -> secondObject <- Some theObject
       | _ -> ()

     method secondObjectsValue =
       match secondObject with
         None  -> 0
       | Some theObject -> theObject#getValue

   end


class secondObject = object (self)

   val something = 99;

   method getValue = something

   initializer
     firstObject#setSecondObject self

end


Where the second class needs to call 'setSecondObject' in the first
class/object, and the first class needs to call the 'getValue' function
from the second class.

I know that with ordinary functions the "let rec" with "and" syntax
lets you define mutually recursive functions, but I haven't seen
anything similar with objects.  I get an error like this:

    This expression has type < getValue : int; .. > but is here used with
    type < getValue : int; .. >
    Self type cannot escape its class

Any suggestions?

In <87ek3jeyae.fsf@...>, code17 <code17@...> typed:
> Mike Meyer <mwm-keyword-ocaml.8afb38@...> writes:
> > I'm addressing this from the Unix side of things.
> Thanks for the hint.
> in previous post
> >> potential output --|-> in_fd ---my-program--> out_fd --|-> potential input
> now clearer
>     keystroke etc --|-> my_stdin --- my-prog --> out_fd --|-> potential input
> in such a case, I can't do much things to my stdin (which is obviously
> already exist), otherwise I won't be able to receive information
> outside; nor can I fork the right side world by giving my stdin as its
> stdin, because it's also *already* forked with other file_descr (so that
> I can do some other interaction with it beforehand -- before I really
> want to pipe the two worlds).

The only thing I know of that will do what you want is the sendfile
call - and it may not work. I don't know how portable it is, so you'll
have to check your Unix variant to see if it has sendfile.  The BSDs
do. Linux does.

> > If they open files by names that you get to give them, then
> > you can do things with Unix domain sockets and fd file systems to
> > control what they get when they open the files.
> I don't know much UNIX programming. But if you're talking about the
> functionality provided by Unix.mkfifo, the named pipe in OCaml, then my
> problem still exists for the same reason.

Sendfile is limited, in that it copies from files to sockets. The
point of using unix domain sockets and the fd file system is make your
outbound fd into a socket so that you can call sendfile on it.

Pipes may or may not be implemented with sockets underneath, so
sendfile may or may not work on them. Ditto for fifos. If they don't
work, you'll want to create a Unix domain socket and get both ends of
it. You then use one end as stdin for the child process. After doing
whatever you need to do to it, you can call sendfile with the other
end as the destination socket.

And it still may not work if your input fd is of the wrong type.

> Maybe this is just impossible in *nix? I mean, anyway, I can do it by
> keeping reading and writing with no doubt, the problem is that whether
> doing it this way is quite silly and there exists some clever magic I
> don't know, or this is the only choice _under_such_a_situation_ ?

The answer is that there exists clever magic that works some of the
time. It's pretty specialized, and it doesn't sound like your usage is
what it's intended for. If that's the case, you could check and see if
sendfile can be used, but unless performance is critical for this part
of your app, I wouldn't bother.

	 <mike
--
Mike Meyer <mwm@...>  http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.

Bob Jones wrote:

>Hi,
>
>I'm trying to figure out how I can declare two classes where each needs
>to know the others type.  This is a rough illustration, but I want to
>do something like this:
>
>
>let firstObject =
>  object
>    val mutable secondObject  = None
>
>    method setSecondObject theObject  =
>      match secondObject with
>        None  -> secondObject <- Some theObject
>      | _ -> ()
>
>    method secondObjectsValue =
>      match secondObject with
>        None  -> 0
>      | Some theObject -> theObject#getValue
>
>  end
>
>
>class secondObject = object (self)
>
>  val something = 99;
>
>  method getValue = something
>
>  initializer
>    firstObject#setSecondObject self
>
>end
>
>
>Where the second class needs to call 'setSecondObject' in the first
>class/object, and the first class needs to call the 'getValue' function
>from the second class.
>
>I know that with ordinary functions the "let rec" with "and" syntax
>lets you define mutually recursive functions, but I haven't seen
>anything similar with objects.  I get an error like this:
>
>   This expression has type < getValue : int; .. > but is here used with
>   type < getValue : int; .. >
>   Self type cannot escape its class
>
>Any suggestions?
>
>
>
Hi,

you need to cast self in the initializer (and more generally whenever
you use it as an argument to a function/method outside the class)
because self's type is not fixed (see
http://caml.inria.fr/pub/docs/manual-ocaml/manual005.html#ss:reference-to-self)
:

class secondObject = object (self)

   val something = 99;

   method getValue = something

   initializer
     firstObject#setSecondObject (self :> secondObject)

end


This compiles here.

Christophe

__________________________

Ce message (et toutes ses pièces jointes éventuelles) est confidentiel et établi
à l'intention exclusive de ses destinataires. Toute utilisation de ce message
non conforme à sa destination, toute diffusion ou toute publication, totale ou
partielle, est interdite, sauf autorisation expresse. L'IFP décline toute
responsabilité au titre de ce message.

This message and any attachments (the message) are confidential and intended
solely for the addressees. Any unauthorised use or dissemination is prohibited.
IFP should not be liable for this message.

Visitez notre site Web / Visit our web site : http://www.ifp.fr
__________________________

Hello all,

  my problem can be summed up in one line :

  #10.87+.0.01;;
- : float = 10.879999999999999

   Of course I can redefine my own float type and operations,
but isn't it a pity that Caml behaves like that ?


                                  Ewan

roparzhhemon a écrit :

>   Hello all,
>
> my problem can be summed up in one line :
>
> #10.87+.0.01;;
>- : float = 10.879999999999999
>
>  Of course I can redefine my own float type and operations,
>but isn't it a pity that Caml behaves like that ?
>
>
>
Here is a little C program :
---------------------------------
#include <stdio.h>

void main (){
   float a , b;
   a = 10.87;
   b = 0.01;

  printf ("%.10f\n", a + b);
}
---------------------------------
  The output of this program is :  10.8799998853

Rounding is the difficult part when you are doing floating point arithmetic.

OCaml provides also the Num library that may interest you?

Matthieu

http://docs.sun.com/source/806-3568/ncg_goldberg.html

Perhaps you want fixed point?

roparzhhemon wrote:
>
>    Hello all,
>
>  my problem can be summed up in one line :
>
>  #10.87+.0.01;;
> - : float = 10.879999999999999
>
>   Of course I can redefine my own float type and operations,
> but isn't it a pity that Caml behaves like that ?
>
>                                  Ewan

The standard floats, used by almost all computer languages & implementations
including OCaml and C, use a binary representation such that neither 10.87 nor
0.01 can be exactly represented (much like 1/3 cannot be exactly represented in
decimal : any finite sequence like 0.333333 is only an approximation). Hence
problems like yours.

The other language you are using is probably just hiding that from you, for
instance by using less digits when displaying results.

If you absolutely need to avoid the problem (e.g. you're doing accounting) the
easiest workaround is, indeed, to define your own (say) "currency" type which
store, say, the (integer) number of cents of the amount.

Frédéric

On Sun, Jan 08, 2006 at 12:27:17AM +0100, code17 wrote:
> Suppose I have two file_descr already exist, in_fd for reading, out_fd
> for writing. What I'm doing is keeping reading from in_fd then writing
> the contents to out_fd, i.e. my program acts like a pipe between two
> worlds.
>
> What I'm thinking is whether there exist a direct abstraction (as well
> as primitive) in OCaml or maybe in the system layer, for connecting two
> file_descr instead of keeping my program looping and working, so my
> program can delegate this task to system.

This is basically a Unix programming question.  I suggest you pick up
a copy of Advanced Programming in the Unix Environment
(http://www.kohala.com/start/apue.html) or one of the late Mr Stevens'
other books on the subject.

The short answer to your question is that this will probably work, but
at the same time is not a particularly good idea, for reasons that you
will find out if you read the above book.

   open Printf
   open Unix

   let pid = fork () in
   if pid > 0 then
     ignore (wait ())
   else (
     let cmd = sprintf "cat <%d >%d" in_fd out_fd in
     ignore (Sys.command cmd);
     exit 0
   )

Getting the integer *_fd from the Unix.file_descr is a bit harder.
You might need to use Obj.magic, which is yet another reason why you
wouldn't really want to use the above code.

Rich.

--
Richard Jones, CTO Merjis Ltd.
Merjis - web marketing and technology - http://merjis.com
Team Notepad - intranets and extranets for business - http://team-notepad.com

On Mon, 9 Jan 2006, roparzhhemon wrote:

>
>
>   Hello all,
>
> my problem can be summed up in one line :
>
> #10.87+.0.01;;
> - : float = 10.879999999999999
>
>  Of course I can redefine my own float type and operations,
> but isn't it a pity that Caml behaves like that ?

Short answer: No.

Long answer: here's the problem.  Floating point is of finite precision.
For any base, *any* base, there are simple fractions which can not be
represented exactly in a finite number of digits.  Base 10, for example,
can't represent 1/3rd exactly without an infinite number of 3's.  Ocaml
floats happen to be IEEE-754 double precision floating point numbers,
which work in binary.  Which means that in addition to 1/3rd, they also
can't exactly represent 1/5 or 1/10 without an infinite number of bits.

Which means that with any finite amount of precision, you will simply hold
an approximation.  Instead of 1/3, you get 0.3333.  Of course, 1/3 * 3 =
1, but 0.3333 * 3 = 0.9999.  Welcome to numeric roundoff.  Doesn't matter
what you do, with finite precision, you will hit numeric round off.
Decimal vr.s binary floats, both hit round off.  You have rational
arithmetic- you represent the number a/b as the tuple of the two numbers
(a, b).  Then someone asks you to normalize the vector [1, 1, 0].  Which
is simply the vector [1/sqrt(2), 1/sqrt(2), 0].  Except there are no two
finite precision numbers a and b such that a/b = sqrt(2).  And so you get
numeric roundoff.

So we have to deal with numeric roundoff no matter what we do.  We can't
escape from the problem.  So why not use an arithmetic that the computer
can do fast, and gives us as many digits as possible?  This is why the
hardware manufacturers went with binary- as did C, Ocaml, Java, C++, Perl,
Python, Ruby, Fortran, and pretty much every other language except Cobol.
64 bit floats gives us 15 decimal digits of precision (actually a little
more)- enough digits to measure from here to the moon in micrometers.  And
that isn't an exageration.  The moon is a little bit less than 400,000
kilometers from the earth.  That's six digits of precision to measure the
distance in kilometers.  Nine digits gets you meters.  12 digits gets you
millimeters.  15 digits, micrometers.  The distance from here to the moon,
with no round off, in micrometers.

Surely, that's enough precision, isn't it?  I mean, for any real life use.
So long as we don't lose too many bits of precision.  Because the problem
is that the errors can accumulate.  There are, broadly speaking, two
different sorts of numeric algorithms (the situation isn't precisely this
clear, but I'm simplifying here).  The first type is the unstable
algorithms.  With these algorithms, errors accumulate.  If you're a little
high this step, next step you'll be even higher.  The other type is stable
algorithms.  With these algorithms, errors cancel- a little high this
round, a little low next round.  I liken it to a marble with a bowl.  Put
a marble in a bowl, and move it away from the bottom of the bowl, and the
marble will roll around the bottom of the bowl- but it won't leave the
bowl.  The position of the ball will always be reasonable near the bottom
of the bowl.  Now take the bowl and turn it upside down and put the marble
on top.  So long as it's exactly on the top of the bowl, balanced
precariously, it'll stay there.  But move it away from the top of the
overturned bowl, and it'll start rolling away from the top of the bowl,
accelerating away as it does.

With an unstable algorithm, any finite number of bits is insufficient-
because you lose them to roundoff error, sooner or later.  I've seen
algorithms that double the number of bits of roundoff error every
iteration.  Start with one bit wrong, and six steps later your entire
64-bit floating point number is wrong.  The newbie solution to this is to
just add more bits- but remember the number of bits being eaten doubles
every step.  So a 128 bit floating point number is totally garbage at
seven steps.  A 1 Kbyte floating point number is wrong after 13 steps.  A
1 Mbyte number is wrong after 23 steps.  Even if you went to 1 GByte
numbers, they'd be wrong after 33 steps.  Meanwhile, the stable algorithm
just got down with a million iterations, and only has a couple of bits
wrong.

Nor, I comment, does interval arithmetic help.  The idea of interval
arithmetic is that you represent each number as an interval a to b.  Two
numbers.  I can then calculate the bounds of any operation.  Say I'm
calculating x - y, and I know that x is somewhere in the bounds of x1 to
x2 (x1 < x2), and y is between y1 and y2.  Then I know that x - y is
somewhere between x1 - y2 and x2 - y1.  And I know that x/y is somewhere
between x1/y2 and x2/y1.

A counter example of why this doesn't work is Newton's method.  You
remember Newton's method from Calculus, right?  If you're trying to find a
solution to f(x) = 0, you calculate x' = x - f(x)/f'(x).  If x is at all
close to the right answer, then x' is even closer to the right answer.
You feed x' in as the next x, and you converge on the right answer.  Were
you to run interval arithmetic on this algorithm, you'd find that in each
step, the bounds became larger- when, in reality, the answer you're
getting is becoming more accurate.  If you were to start with 1 correct
bit in your initial guess, after one iteration you'd have two iterations.
After the second iteration, you'd have four correct bits, then 8, then 16.
After six steps, you could quit because you have the right answer.  Errors
in one step tend to be canceled in the next step- Newton's method is very
stable.  Overshoot a little this step, next round you'll undershoot a
little- but you're still converging and gaining correct bits.

So interval arithmetic doesn't work- and neither does bigger floats nor
rational arithmetic, nor a couple of dozen other ideas that have been
invented and tried out in the last fifty plus years we've been struggling
with this (this isn't a new problem- one of the candidates for first
digital computers was built by Professor Atanasoff at Iowa State to solve
partial differential equations, and had this problem).  The solution is to
use stable algorithms, and to be aware that floating point is only only
accurate to 15 digits or so.

I bring up interval arithmetic because Sun has recently rediscovered it,
at least according to their press releases.  Bad news, Sun: interval
arithmetic had been *re*discovered at least twice before I was born- it
ain't new.  And it doesn't work- didn't work then, doesn't work now.

So what's a stable algorithm, and what isn't?  Especially when
conceptually small changes make big differences.  Gaussian elimination-
unstable.  Gaussian elimination with partial pivoting- stable.

Well, there are two different ways you can tell this.  Way number one is
to get a PhD in Mathematic specializing in numerical analysis, and analyze
the algorithms yourself.  Or, you can do what I do.  Which is buy a book
on numerical analysis, and skip the sections where they actually derive
what the error bounds for the algorithms are, except for the conclusions.
They generally make the conclusions fairly obvious.  "As we can see from
the above text, the error bounds for Gaussian elimination without partial
pivoting accumulate at an unacceptable rate, while the error bounds for
Gaussian elimination with partial pivoting accumulate at an asymptocially
slower rate."  Right.  Mental note to self: always partially pivot when
doing Gaussian elimination.

I hope this helps.

Brian