[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fixed-point arithmetic

From: Chipmuenk
Subject: Re: Fixed-point arithmetic
Date: Mon, 18 Apr 2011 21:59:20 -0700 (PDT)

David Bateman-2 wrote:
> Le 18 avr. 2011 à 14:39, Chipmuenk a écrit :
> Not quite true. GMP supports fixed point and the matlab code is based on
> GMP (see Laurent and I chose not to use GMP
> with the fixed point code for Octave and base it on 32 or 64 bit integers.
> In this way the code is much faster than the matlab code, though it can't
> handle large integers. The reality in communication systems is that more
> than 16 bits are rarely used, so frankly speed is the key here so I still
> think this choice was the right one.

Sorry, I wasn't aware of GMP. In my opinion (or at least for my application
;-) ), FPGA-multiplier blocks define the wordlengths that are commonly used
in FPGA-based signal processing. At the moment, these blocks usually have
input wordlengths of 18 or 25 bits, so 32 bit integers are too small in most
cases, but 64 bit should do.

David Bateman-2 wrote:
> Its not compatible as it was written before matlab released their fixed
> point package, if it was in parallel I might have tried to copy their
> interface ;-). Its faster than the matlab fixed point code, so I hardly
> think its a dead end.

I did not want to imply that the package is bad or slow (I like using it),
I'm just afraid that a package that has "disappeared from the radar" might
attract less and less users. Combine it with a completely different
interface from Matlab (unfortunately, compatibility _is_ important to many
users), and I think the danger of becoming extinct is for real.

David Bateman-2 wrote:
> Some Ideas I alright had were
> - Adapt the code for NDArrays so more Octave code could be used with the
> package.
> - Add different overflow and rounding options. The ones that are used in
> the code were the ones that were used in the CMOS process I was developing
> for.

Different overflow, rounding and saturation options were also the first
things that came to my mind.

David Bateman-2 wrote:
> Frankly I don't think its a good idea to make this package matlab
> compatible, unless we want to use GMP as well.

Compatibility is certainly not a "must", but I think making it available via
octave-forge is, and some simple DSP examples would also help (I am willing
to help with the latter).


View this message in context:
Sent from the Octave - General mailing list archive at

reply via email to

[Prev in Thread] Current Thread [Next in Thread]