is delete[] necessary?

[James Kanze]

On 2008-01-28 21:05:53, James Kanze wrote:

Which boils down to "never use (in)equality comparison with
floating point numbers".

No, it doesn't boil down to that. It boils down to the fact
that you have to understand floating point, and how it works, to
use it correctly, and that simple testing isn't always
sufficient to be sure that the algorithm works.

OTOH, abs(((a + b) + c) - (a + (b + c))) < epsilon can be safe, with
appropriate choice of epsilon.

Comparing for exact equality can also be appropriate, in certain
cases. Similarly, the above won't necessarily help in many
cases.

 

[James Kanze]

"James Kanze"
On Jan 28, 6:18 pm, "John Brawley" wrote:

"James Kanze" wrote
[...]

cases. But there are also a lot of threading issues which
don't lend themselves to testing, and some floating point
issues as well.
Please, you bring up a worry: you say some floating point
issues don't lend themselves well to testing. I use double

What tests would have issues with floating piont, if your
answer would be a) of interest to you or others or b) not
wildly offtopic?
(block quote)

Floating point is very, very tricky, because it's not linear.
Which means that at least in principle, and algorithm might work
for two values very, very near one another, and fail for a value
in between them. (And of course, the number of possible
floating point values generally precludes exhaustive testing.)
The result is that you do very, very careful numerical anaysis
to prove that your algorith will behave linearly over a given
range, despite the descrete nature of machine floating point,
then test the ends of the range exhaustively, and add a few
random tests elsewhere. In some cases, in fact, you'll find
that you'll have to use two different algorithms, depending on
the input, since no one algorithm will be linear over the entire
range---in such cases, of course, you'll test very insensively
around the switch-over point.

Thank you very much. I'm aware the machine itself can (and
does) generate "rounding errors" that vary, much as you
describe (close-to-same floats, perhaps error beyond the
fifteenth(?) decimal place).

It's not "rounding errors", per se. It's the fact that machine
floating point uses discreet values, and as such, isn't really a
very good approximation of real numbers, at least in some cases.

My implementation is likely not suffering: I haven't seen a
single exception thrown by the operating system even in
literally days of continuous running flat-out.

Most errors will result in wrong results or an endless loop,
rather than crashing. And in literally days of continuous
running flat-out, you've still only exercised a very small
percentage of possible values, and so haven't really proved
anything.

Of course, it all depends on what you're actually doing. For
example, I use floating point to calculate and display
percentages (e.g. 100.0 * hits / total, where hits and total are
integers). In that case, it just works, and there's no need for
any deep analysis.