FFT Speeds

On Friday, April 3, 2020 at 6:23:14 AM UTC-4, David Brown wrote:
> On 03/04/2020 10:29, Rick C wrote:
> > On Friday, April 3, 2020 at 2:34:42 AM UTC-4, upsid...@downunder.com
> > wrote:
> >> On Thu, 2 Apr 2020 12:39:55 -0700 (PDT), Rick C 
> >> <gnuarm.deletethisbit@gmail.com> wrote:
> >> 
> >>> On Thursday, April 2, 2020 at 2:33:20 PM UTC-4, Tauno Voipio
> >>> wrote:
> >>>> 
> >>>> Booth's algorithm does handle signed operands in two's
> >>>> complement notation.
> >>> 
> >>> Your mention of two's complement as if there were other choices
> >>> these days made me recall that in the Forth language group there
> >>> is a discussion of standardizing on 2's complement... finally.
> >>> 
> >>> Seems someone looked and there are literally no remaining
> >>> hardware computers running anything other than 2's complement.
> >>> There is an architecture running 1's complement, but it is no
> >>> longer a hardware implementation but only simulated on other
> >>> machines, lol.  There must be some commercial niche for software
> >>> written for that machine.
> >> 
> >> The nice feature with 1&#31350; complement is that you can negate a
> >> number by simply inverting all bits in a word. Thus inserting the
> >> inverters in one data path and both inverting and some other
> >> operation can be used in a single instruction.
> >> 
> >> The problem with 2&#31350; complement is that after inverting all bits,
> >> "1" must be added to the result, requiring an adder and the ripple
> >> carry can propagate through all bit positions. Thus complementing a
> >> number needs an ADD instruction and takes as long as an ordinary
> >> ADD, Of course these days with carry look-ahead logic, the ADD is
> >> nearly as fast as AND/OR instructions.
> > 
> > Exactly, and the 2's complement doesn't have the various issues the
> > 1's complement does.  It only has a single value for zero.  I can't
> > recall how they deal with that.  If you subtract 2 from 1 you would
> > get an all ones word which is zero, so you have to subtract another 1
> > to get -1 which is all ones with the LSB zero.  So it's not really
> > simpler, just messy in different ways.
> 
> Yes - ones' complement has several complications, and not many benefits. 
>   Sign-magnitude also has the "negative zero" issue, but has nice 
> symmetry and is good for multiplication and division.  

At least with sign magnitude it is easy to detect zero, just ignore the sign bit. 


> These formats 
> also avoid the asymmetry of having a larger negative range than positive 
> range, and odd things like "abs(-128) == -128" (using 8-bit to keep the 
> numbers small).

I don't have a problem with asymmetry.  I've never found a situation where it was a problem. 

-- 

  Rick C.

  -++ Get 1,000 miles of free Supercharging
  -++ Tesla referral code - https://ts.la/richard11209

On 03/04/2020 18:38, Rick C wrote:
> On Friday, April 3, 2020 at 6:23:14 AM UTC-4, David Brown wrote:

<snipped?
> 
>> These formats
>> also avoid the asymmetry of having a larger negative range than positive
>> range, and odd things like "abs(-128) == -128" (using 8-bit to keep the
>> numbers small).
> 
> I don't have a problem with asymmetry.  I've never found a situation where it was a problem.

I've previously disallowed 0x8000 as a digitised 16 bit analog value so 
I could use it as an escape word in the data stream.

-- 
Cheers
Clive