# Unusual Floating-Point Format Remembered?

V

Jan 1, 1970
0
Jerry Avins wrote:

No.

64 bits provides a range of +/- 9,223,372,036,854,775,807. What is the
ratio of the forces of Brownian motion in room temperature air and of a
major earthquake?

Leave the banal comparisons to the journalists. It is fairly simple to
run out of 64 bits when you are working with the cascaded CIC filter,
for example.

BTW, there is a MIRACL math library which alows having the arithmetic
with any given precision.

DSP and Mixed Signal Design Consultant

http://www.abvolt.com

N

#### Nick Maclaren

Jan 1, 1970
0
[ Irrelevant newsgroups removed from follow-up. ]

|>
|> Leave the banal comparisons to the journalists. It is fairly simple to
|> run out of 64 bits when you are working with the cascaded CIC filter,
|> for example.

Well, yes, in theory. But do you actually suffer from serious loss
of accuracy in practice? And can you provide any useful references
as to how and why?

We both know that FFTs 'lose' up to log_2(N) bits, which means that
a cascaded series could lose M.log_2(N) - which could be a lot. But
does this happen in practice, and do you know what difference the
rounding method makes?

I am interested in this because I have an unproven hypothesis that
this could be a real case where probabilistic rounding is numerically
superior to even the best nearest rounding. It would be interesting
to see if that really is the case.

Regards,
Nick Maclaren.

J

#### Jerry Avins

Jan 1, 1970
0
Jerry Avins wrote:

Leave the banal comparisons to the journalists. It is fairly simple to
run out of 64 bits when you are working with the cascaded CIC filter,
for example.

OK; you're right. But what is a /cascaded/ CIC filter? Is it like AC
voltage (alternating current voltage)?
BTW, there is a MIRACL math library which alows having the arithmetic
with any given precision.

There are several BigNum packages. I use one written in Forth.

Jerry

V

Jan 1, 1970
0
Jerry Avins wrote:

I know what a CIC is. What's a _cascaded_ CIC?

Point taken.

VLV

M

#### MooseFET

Jan 1, 1970
0
|>
|> If you are doing special hardware for an FFT, the addressing is fairly
|> easy to implement.
|> The operations involved are all "add like" in operation.

That's not the problem.

The problem is that all current memory technologies rely on the data
being accessed in contiguous 'blocks'; it requires a LOT more money
and watts to make true random access efficient. And there is no way
to assign arrays to blocks that doesn't cause some passes of the FFTs
to access the data in a very inefficient pattern.

Oh that problem.

If part of the address space is disk, it makes sense to stop and re-
order the data part way through the bufferfly process. I have never
considered it for RAM speed issues.

N

#### Nick Maclaren

Jan 1, 1970
0
|>
|> > The problem is that all current memory technologies rely on the data
|> > being accessed in contiguous 'blocks'; it requires a LOT more money
|> > and watts to make true random access efficient. And there is no way
|> > to assign arrays to blocks that doesn't cause some passes of the FFTs
|> > to access the data in a very inefficient pattern.
|>
|> Oh that problem.
|>
|> If part of the address space is disk, it makes sense to stop and re-
|> order the data part way through the bufferfly process. I have never
|> considered it for RAM speed issues.

RAM is the new disk.

Regards,
Nick Maclaren.

J

#### [email protected]

Jan 1, 1970
0
We didn't use pens. A rarely used option was scribing coated film, but
most of the work was done by projecting light through apertures of
various shapes onto photographic film with the projection head I
described above. The head contained a wheel with 24? apertures that
could be selected on command like the tools in an NC machine. We had an
inventory of many more apertures than would fit the wheel at one time.
An aperture could be removed and remounted so that its image was
repeatably relocated within a step. Gerber's apertures were etched in
metal and not intended for frequent replacement. They had two holes to
match pins in the wheel. Mine were photographic images on thin Plexiglas
drilled with one hole to fit a pin tightly and another larger hole to
serve as a rotation stop. A tapered wedge in the larger held the pin
against the stop. Eventually, we built a mechanical slit whose length
could be varied and which could be rotated to be normal to any direction
of motion. I believe that Gerber adapted that approach in some of its
plotters.

Oh, kewl. You could etch a board with that.
Do you want more detail?

No, thank you.
This getting a bit afield,

Yes, and I apoligize to the s.m.n-a critters for drifting the thread.
but I can understand

But I'm glad I did trespass here. I learned about something I didn't
know I didn't know. Thank you for spending your time on my
query.

/BAH

T

#### Terje Mathisen

Jan 1, 1970
0
Jerry said:
No thanks. There are always situations that call for more MORE *MORE*.
One of my first delivered assembly-language programs added using triple
precision. Of course, that was on an 8-bit machine (So why doesn't
the DEC Alpha have a carry flag?)

Because 64-bit ints are enough for the vast majority of all integer
apps, and for those that do require carries, it can be _very_ efficient
to work in a redundant format like carry-save, in which case you'll
handle full carry propagation only when delivering the final result.

As a longtime asm programmer, and author of about 5 bignum/arbitrary
precision packages, I do like AddWithCarry, but I have absolutely no
problem accepting that this has to be a slower operation than a normal ADD.

Terje

J

#### Jerry Avins

Jan 1, 1970
0
glen said:
MooseFET wrote:

(someone wrote)

Traditionally it was done by having the result of multiply stored
in two registers and one uses the high register. With a double
length shift (hopefully fast) one can select the desired bits.

The original TeX is in Pascal, with the suggestion that one routine
be written in assembler for the host machine. That does (A*B)/C where
A, B, and C are 32 bit values, and A*B has 64 bits. Easy on many
machines, not so easy in Pascal.

That is the Forth primitive "*/". n1 n2 n3 */ gives (n1*n2)/n3 using a
double-length intermediate product. It makes scaled integer fairly simple.

Jerry

G

#### glen herrmannsfeldt

Jan 1, 1970
0
(someone wrote)

Is the question still FFT?

Are there any actual uses where one would try to separate an
earthquake signal and Brownian motion with an FFT? And even
so, 64 bit floating point won't do any better.

-- glen

G

#### glen herrmannsfeldt

Jan 1, 1970
0
MooseFET wrote:

(someone wrote)
Yes a Y = X + A*B/(2^N) instruction would be a nice feature, even if N
was restricted to only certain values.

Traditionally it was done by having the result of multiply stored
in two registers and one uses the high register. With a double
length shift (hopefully fast) one can select the desired bits.

The original TeX is in Pascal, with the suggestion that one routine
be written in assembler for the host machine. That does (A*B)/C where
A, B, and C are 32 bit values, and A*B has 64 bits. Easy on many
machines, not so easy in Pascal.

-- glen

M

#### MooseFET

Jan 1, 1970
0
MooseFET wrote:

(someone wrote)

Traditionally it was done by having the result of multiply stored
in two registers and one uses the high register. With a double
length shift (hopefully fast) one can select the desired bits.

Yes, I do that in assembly. Quite a few machines do a a "multiply

Y = Y + A*B

In some DSP like processors, the instruction can be:

Y = X + A*B

where X and Y are both accumulator registers.

You can't use these if you need to shift the result down first. This
means you need three instructions to do the operation. Just a little
extra logic on the chip would allow for the shifted versions.

Replies
0
Views
342
Replies
5
Views
808
Replies
1
Views
1K
Replies
0
Views
3K
Replies
5
Views
931