On Tue, 28 Aug 2007, Manu Abraham wrote:
Trent Piepho wrote:
That's really inefficient. You've got about 250k of table there. I don't
think a 250k+ module is going to be very popular.
I do agree that's not the most effecient way. But given the short time
span and lack of FP operations,
Trent Piepho wrote:
On Tue, 28 Aug 2007, Manu Abraham wrote:
Trent Piepho wrote:
That's really inefficient. You've got about 250k of table there. I don't
think a 250k+ module is going to be very popular.
I do agree that's not the most effecient way. But given the short time
span and lack
On Tue, 28 Aug 2007, Manu Abraham wrote:
* use integer math calculations
* precompute the values where double precision is needed.
That said, the first option i tried for a while, after a few days (i
almost gave up ?) got really irritated with it.
The second option seemed a bit more
Trent Piepho wrote:
On Tue, 28 Aug 2007, Manu Abraham wrote:
* use integer math calculations
* precompute the values where double precision is needed.
That said, the first option i tried for a while, after a few days (i
almost gave up ?) got really irritated with it.
The second option
Henk Vergonet wrote:
On Tue, Aug 28, 2007 at 12:19:57AM +0400, Manu Abraham wrote:
Hi all
While working on a tuner, i stumbled upon one of the usual problems
(floating point operations) in kernel
The options what i had were:
* use integer math calculations
* precompute the values where
Hi all
While working on a tuner, i stumbled upon one of the usual problems
(floating point operations) in kernel
The options what i had were:
* use integer math calculations
* precompute the values where double precision is needed.
That said, the first option i tried for a while, after a few
