Hi,
Why are the two logs added as integers (+) rather than
as polynumials (^)? Why do you do % 255 rather than 256?
Interesting point.
The justification must be hidden in James S.
Plank's statement:
This implementation makes use of the fact that
the inverse log of an integer is equal to the
Hi,
Why are the two logs added as integers (+) rather than
as polynumials (^)?
One can prove the theorem
log(a*b) = log(a) + log(b)
by
a = x^log(a)
b = x^log(b)
a*b = x^log(a)*x^log(b)
= x*x...x * x*x...x
\/\/
log(a) many log(b) many
This breaks
Hi,
I have to correct myself:
I.e. the indice of the power and log table
represent natural numbers, not polynomials.
The indice of the power table are natural
numbers, the indice of the log table
are polynomials.
Have a nice day :)
Thomas
--
To UNSUBSCRIBE, email to
Hi,
D. Hugh Redelmeier:
If you double the gfpow table's size you could elminate the % 255.
That was a substantial improvement.
It now needs only 10 % more time than the old
implementation. I.e. you cut off 80% of the
initial performance deficit.
One has to unroll the table gfpow[] up to 511
Andy Polyakov ap...@fy.chalmers.se wrote:
On the other hand, looking through the information provided *beyond*
requested one allows to draw conclusion that DMA is *in fact* enabled
for optical drive in question. Once again, target1-dcd-options is 0xa2
and more important read performance
D. Hugh Redelmeier h...@mimosa.com wrote:
I'm not going to judge who is right and who is wrong. This is a long
conflict, as far as I know.
There is no related long conflict with libburn. You may confuse this with the
conflict that has been initiated by a hostile Debian packaging person in
Andy:
It's of greater relevance/interest to look at dvd+rw-mediainfo for
*resulting* recording, not for blank media. There you should be able to
confirm that READ CAPACITY and/or lead-out position are adequate,
recording size / 2048 to be specific.
Here is the same command, but with a burned
Julián M. julia...@gmail.com wrote:
Joerg:
BTW: Cdrecord does honor this firmware specific behavior
ftp://ftp.berlios.de/pub/cdrecord/alpha/
I installed cdrecord:
~$ /opt/schily/bin/cdrecord -version
Cdrecord-ProDVD-ProBD-Clone 2.01.01a36 (i686-pc-linux-gnu) Copyright
(C) 1995-2007
This is the original version but it is _very_ old.
I tried to compile from the newest source but i think i didnt
succeed... the i installed a .deb, probably thats where the old
version came from.
I think I never told you, im running Kubuntu Hardy 8.04
2.6.24-24-generic #1 SMP Fri Sep 18
Julián M. julia...@gmail.com wrote:
This is the original version but it is _very_ old.
I tried to compile from the newest source but i think i didnt
succeed... the i installed a .deb, probably thats where the old
version came from.
Where did you take the package from?
a36 is two years
| From: Thomas Schmitt scdbac...@gmx.net
| I have to correct myself:
| I.e. the indice of the power and log table
| represent natural numbers, not polynomials.
|
| The indice of the power table are natural
| numbers, the indice of the log table
| are polynomials.
Thanks for your very useful
Hi,
As such, your original gfpow table should have had a size of
255 elements, not 256.
Yes. It became obvious when i unrolled it.
I had just estimated its size to produce no
buffer overflows.
The operation % 255 makes index 255 impossible.
The smallest log is 0. The largest is 254 (not
Hi,
the next final release for cdrtools is close and I am of course
interested in giving the best possible. I unfortunately did not have
access to some pf the supported platforms for a long time and it
seems that AIX may be the most important platform from this list.
Is there somebody who is
| From: Thomas Schmitt scdbac...@gmx.net
| Some of my own experiments yielded surprising
| setbacks. E.g. i replaced
|gfpow[44 - i]
| by
|h45[i]
| with a suitable constant array h45[].
| This was 7 percent slower !
| (I suspect a less fortunate cache situation.)
Right. gcc can fold the
14 matches
Mail list logo
