Unusual Floating-Point Format Remembered?

In article , Jerry Avins writes: |> |> It may be easy to do with floating point, but I bet it's more likely to |> be bug free the first time around in integer, especially when the final |> result must be integer in either case.

It isn't, and I have done it in both.

|> > Using integers doesn't eliminate |> > the problem - it merely means that you get the exact same movements |> > on all systems - not a very useful property. |> |> If "you get the exact same movements on all systems" and there is no |> closure error ever -- if, in other words, the plotter is always on the |> grid point closest to the point calculated with infinite precision -- |> how does that not eliminate the problem?

It does. You were using infinite precision integer arithmetic? Please tell.

The problem of ensuring closure when using floating-point is identical to that of doing so using integer.

Regards, Nick Maclaren.

Snide remarks are unbecoming.

The problem is the same, but the solution is more difficult when using floating point. The programmer has limited control over round-offs and no simple way to accumulate their effects.

Jerry

As I recall, the IBM 1620 (circa 1967) did everything in decimal: addresses, integers, floating-point.

In article , Jerry Avins writes: |> |> > It does. You were using infinite precision integer arithmetic? |> > Please tell. |> |> Snide remarks are unbecoming.

I apologise. But it is also unreasonable to bring up red herrings.

|> > The problem of ensuring closure when using floating-point is identical |> > to that of doing so using integer. |> |> The problem is the same, but the solution is more difficult when using |> floating point. The programmer has limited control over round-offs and |> no simple way to accumulate their effects.

Not at all.

You don't even TRY to control over round-off - doing so was discovered to be a serious mistake in the 1960s. The technique for accumulating round-off error has been widely known since the early 1970s, and is likely to fail only on arithmetics that few people have ever heard of and even fewer used. They were VERY rare by the 1970s, and I haven't heard of any since the CDCs.

Regards, Nick Maclaren.

Do you claim that IEEE 454 was misguided in offering four rounding options?

Jerry

In article , Jerry Avins writes: |> |> > You don't even TRY to control over round-off - doing so was discovered |> > to be a serious mistake in the 1960s. The technique for accumulating |> > round-off error has been widely known since the early 1970s, and is |> > likely to fail only on arithmetics that few people have ever heard of |> > and even fewer used. They were VERY rare by the 1970s, and I haven't |> > heard of any since the CDCs. |> |> Do you claim that IEEE 454 was misguided in offering four rounding options?

Do you know what they are there for? It isn't for code like the sort you are describing, but interval arithmetic.

The trivial accumulation techniques I am referring to work with any form of rounding that is at least as good as truncation. Do you know them?

Regards, Nick Maclaren.

Sure. But the most generally useful, accumulating the lost bits due to rounding or truncation, is impossible or tedious with floats. Look into some comp.dsp threads on "fraction saving".

Jerry

In article , Jerry Avins writes: |> |> > The trivial accumulation techniques I am referring to work with any |> > form of rounding that is at least as good as truncation. Do you know |> > them? |> |> Sure. But the most generally useful, accumulating the lost bits due to |> rounding or truncation, is impossible or tedious with floats. Look into |> some comp.dsp threads on "fraction saving".

!!! Well, I suggest that the people who claim that contact someone who knows how to do it. As I said, I have done it in both integers and floating-point. It isn't hard, and doesn't need extended precision. It does need skill and care - whether it is done in integers or floating-point.

There have been several sci.math.num-analysis threads on it.

Regards, Nick Maclaren.

It's not so simple when the exponent might change, but it's very straight-forward with integer or fixed point. Many microprocessors natively implement floored division with remainder, so most of what needs doing is taken care of by the hardware.

You have me curious enough to go look. I hadn't thought there was much to analyze.

Jerry

In article , Jerry Avins writes: |> |> > !!! Well, I suggest that the people who claim that contact someone |> > who knows how to do it. As I said, I have done it in both integers |> > and floating-point. It isn't hard, and doesn't need extended precision. |> > It does need skill and care - whether it is done in integers or |> > floating-point. |> |> It's not so simple when the exponent might change, but it's very |> straight-forward with integer or fixed point. Many microprocessors |> natively implement floored division with remainder, so most of what |> needs doing is taken care of by the hardware.

No, it's actually equally simple in any faithful (a technical term) floating-point.

The key is that (for positive numbers) X-wombat(X) is exact, where wombat() is a function that maintains the exponent of X, returns the next power of the base above X or is a normalised form of something that would be exact when unnormalised with the exponent of X. The functions floor, ceil, nearest and others all meet the requirements.

This means that you can subtract where you are from where you want to be and not lose accuracy. In general, the implicit double precision provides enough extra accuracy to ensure that you always close the loop - because, if it didn't, you have other problems. It also means that you can implement double precision addition by a few statements, which is where the technique originated.

Regards, Nick Maclaren.

Integer addition and subtraction never have a problem, and accumulating division's remainder and adjusting on overflow is simpler and faster than double precision. We are writing about solutions adapted to entirely different domains.

Jerry

In article , Jerry Avins writes: |> |> Integer addition and subtraction never have a problem, and accumulating |> division's remainder and adjusting on overflow is simpler and faster |> than double precision. We are writing about solutions adapted to |> entirely different domains.

Sigh. Yes, they do. Integers can merely be an approximation, and the error accumulation issues are identical. As I have said several times, I have done that using both methods.

Regards, Nick Maclaren.

Did your floating-point divide hardware provide a floating-point remainder as well as a quotient? Most fixed-point dividers generate a remainder. Having the remainder automatically in a register greatly simplifies the process of of fraction saving.

Jerry

In article , Jerry Avins writes: |> |> > Sigh. Yes, they do. Integers can merely be an approximation, and |> > the error accumulation issues are identical. As I have said several |> > times, I have done that using both methods. |> |> Did your floating-point divide hardware provide a floating-point |> remainder as well as a quotient? Most fixed-point dividers generate a |> remainder. Having the remainder automatically in a register greatly |> simplifies the process of of fraction saving.

No.

There are very good reasons to write the code such that it does not use a generalised remainder and/or exact divide. For both integer and floating-point, that requires either the hardware to support a double precision dividend or some extremely painful emulation. Even when the hardware does have such a feature, it is usually slow.

For both integer and floating-point, the way to do that is to scale the calculation so that only an 'integer part' operation is needed. It was ancient technology when I started to use it, some 40 years back.

Regards, Nick Maclaren.

I agree, and I am annoyed that computers make it so difficult to have binary input, including addresses and register labels, and even in their codes. Binary certainly helps, especially if part of the code is 256 or 385 or 513. The instruction subfields are usually in binary.

You rarely do well by microcontrolling roundoff, but it is necessary to control it. My crude estimate of the precision needed to carry out Remez' Second Algorith (one of the best for getting uniform approximations of functions) is at least triple the precision wanted, and this must be taken into account in the calculations, including solutions of linear equations.

In fact, things can be worse. Consider getting the convolution of the sequence 1/j!, j=0,...,127 by the fast Fourier transform.

Floating point roundoff can be catastrophic, as can fixed point, or anything other than integer or fixed point rational.

...

??? How do computers make entering binary data difficult? Are you addressing a representational issue? If so, that's a function of the user interface program, not the computer itself.

Jerry

However slow integer division might be on a particular machine, getting the remainder takes no extra time. Most high-level languages discard it, but it is there. I know the technique of scaling so that only the integer part is needed as "fixed point". Division has remainders nevertheless.

Maybe I don't understand what you mean. If you scale all your quantities so that only the integer part is relevant, why use floating point at all?

Jerry

I agree it is mainly a representational program; the software does not have the relevant features to make it anything but difficult. Try doing this in the "mixed-endian" notation for the VAXen. Also, there are situations where a constant, such as ln(2) or pi, is needed to have be of the form x + y, where x is approximately the constant wanted, but with the last k bits 0, and x+y agrees with the true value to some extra precision.