Possible bug in Tcl or Windows or Tcl on Windows
in [TCL]
|
From: Donald Arseneau on 5 Sep 2009 04:43 On Sep 4, 5:12 pm, Robert Heller <hel...(a)deepsoft.com> wrote: > > > why do you think 101 would have an exact representation in binary? > > > Because it is 1100101 ? > > That is an integer. It is not a floating point binary fraction. Let me turn it around then ... why do you think it doesn't? (I *know* it does.) Do you think integers are not a subset of fp numbers for some reason? DA
From: Alexandre Ferrieux on 5 Sep 2009 04:51 On Sep 5, 6:46 am, solar <solaradmin2...(a)gmail.com> wrote: > > > By the way, you *do* realize that there are much better ways to > > generate Pythagorean triples? > > Yes. I just found some code comparing the exectution time of triplets > in php, erlang, ruby etc,. and rewrote the same in Tcl. It was only > for a comparison. Uh, so you're saying that the brilliant algorithm you're benchmarking across languages uses the floating-point test A=hypoth(B,C) round(A)==A (whatever '==' means here) instead of the accurate, integer-based test A=round(hypoth(B,C)) A*A==B*B+C*C as Bruce suggested ? In a sense you're fortunate that Tcl helped you stumble on that OS- specific hypot() inaccuracy... -Alex
From: Robert Heller on 5 Sep 2009 07:43 At Sat, 5 Sep 2009 01:43:14 -0700 (PDT) Donald Arseneau <asnd(a)triumf.ca> wrote: > > On Sep 4, 5:12 pm, Robert Heller <hel...(a)deepsoft.com> wrote: > > > > > why do you think 101 would have an exact representation in binary? > > > > > Because it is 1100101 ? > > > > That is an integer. It is not a floating point binary fraction. > > Let me turn it around then ... why do you think it doesn't? > > (I *know* it does.) > > Do you think integers are not a subset of fp numbers for > some reason? Sure they are. It is just not always the case that a fp math library function will in fact return an integer result. I.e. the match function is not return 101, it is returning 100.9999999999999 or something like that. Assuming that although *mathematically* the result should be an integer result does not mean that the math library will in fact return the exact integer result. As soon as you start doing arithmetic on a computer *using finite precision floating point*, you start picking up errors and over time (number of calculations) you will pickup errors due to guard bit jitter and round off, etc. One should never assume mathenetically exact results and almost *never* should use an equality test, even when mathematically called for. > > DA > -- Robert Heller -- 978-544-6933 Deepwoods Software -- Download the Model Railroad System http://www.deepsoft.com/ -- Binaries for Linux and MS-Windows heller(a)deepsoft.com -- http://www.deepsoft.com/ModelRailroadSystem/
From: Gerry Snyder on 5 Sep 2009 11:11 Robert Heller wrote: > At Sat, 5 Sep 2009 01:43:14 -0700 (PDT) Donald Arseneau <asnd(a)triumf.ca> wrote: > >> >> Do you think integers are not a subset of fp numbers for >> some reason? > > Sure they are. It is just not always the case that a fp math library > function will in fact return an integer result. I.e. the match function > is not return 101, it is returning 100.9999999999999 or something like > that. Assuming that although *mathematically* the result should be an > integer result does not mean that the math library will in fact return > the exact integer result. As soon as you start doing arithmetic on a > computer *using finite precision floating point*, you start picking up > errors and over time (number of calculations) you will pickup errors due > to guard bit jitter and round off, etc. One should never assume > mathenetically exact results and almost *never* should use an equality > test, even when mathematically called for. Errr,... A math library that says 15 / 3 = 4.999999 or sqrt(10201) = 100.9999999 has an error that should be fixed. Gerry
From: Gerald W. Lester on 5 Sep 2009 11:49
Gerry Snyder wrote: > Robert Heller wrote: >> At Sat, 5 Sep 2009 01:43:14 -0700 (PDT) Donald Arseneau >> <asnd(a)triumf.ca> wrote: >> >>> >>> Do you think integers are not a subset of fp numbers for >>> some reason? >> >> Sure they are. It is just not always the case that a fp math library >> function will in fact return an integer result. I.e. the match function >> is not return 101, it is returning 100.9999999999999 or something like >> that. Assuming that although *mathematically* the result should be an >> integer result does not mean that the math library will in fact return >> the exact integer result. As soon as you start doing arithmetic on a >> computer *using finite precision floating point*, you start picking up >> errors and over time (number of calculations) you will pickup errors due >> to guard bit jitter and round off, etc. One should never assume >> mathenetically exact results and almost *never* should use an equality >> test, even when mathematically called for. > > Errr,... > > A math library that says 15 / 3 = 4.999999 or sqrt(10201) = 100.9999999 > has an error that should be fixed. > > > Gerry 15 / 3 = 5 but 15.0 / 3.0 may equal 4.99999... since it is perfectly obvious that 4.99... and 5.0 the exact same number. Note in fixed length floating point operations, round off errors do happen (normally at the hardware level but also at the software level). To expect anything less is to not live in the real world. -- +------------------------------------------------------------------------+ | Gerald W. Lester | |"The man who fights for his ideals is the man who is alive." - Cervantes| +------------------------------------------------------------------------+ |