On Dec 17, 2005, at 18:48, Joshua Isom wrote:
If I make my version and the perl version print out the final
sequence, they're identical.
Ah. Sorry. I missed that it replaces from the end.
leo
Not that I can tell from the code... Starting from the beginning, push
the substr location onto the end, then in another loop, pop off that
ending and use it for replacement. Only the locations at the end are
affected which is why it starts at the end. An iterator is used to
provide a wrappe
Joshua Isom wrote:
Commented
out is code to use capturing regex to do it for the final substitution.
PGE seems faster with the coroutine.
Doesn't it now substitute on wrong positions after the first replacement?
leo
I applied the changes to the code, using capture for the initial strip.
I did use \> instead of but I didn't notice any real difference,
even when I profiled it. For the matching, using a capturing regex
didn't work well because it'd have to backtrace, which slowed it down
too much for the s
On Fri, Dec 16, 2005 at 10:56:21PM -0600, Joshua Isom wrote:
> Anyway, I've got it working uses all the regexes. I stuck to the p6
> rules, and kept the hash to print out the regex they want to see. It's
> been running now for an hour now and it hasn't even reached the main
> matching yet for
I do tend to use the latest revision, rarely more than a day old. I've
made up a quick script to make parrot, mainly because I have gmp and
gdbm installed by fink. I have --optimized enabled now. I'm primarily
using and 800Mhz PPC, 512k cache. I rarely get any difference in
speeds between -
Leopold Toetsch wrote:
Joshua Isom wrote:
I just finished three more shoot outs. Two are rather simple, a
floating point version of ack, and another that reads from stdin and
adds together the numbers on the lines.
ci'ed takfp and sumcol - r10554
sumcol is +twice the speed now (r
Joshua Isom wrote:
I just finished three more shoot outs. Two are rather simple, a
floating point version of ack, and another that reads from stdin and
adds together the numbers on the lines.
ci'ed takfp and sumcol - r10554
Thanks,
leo
On Dec 16, 2005, at 6:15, Joshua Isom wrote:
I noticed a slight glitch with the regex-dna benchmark.
There is still a glitch in the PIR:
* use regex substitution to remove FASTA sequence descriptions and all
linefeed characters
Thanks,
leo
On Dec 16, 2005, at 4:58, Joshua Isom wrote:
I just finished three more shoot outs. Two are rather simple, a
floating point version of ack,
Great, thanks. A comment wrt takfp:
ubstitution. Anyway, the floating point takfp is slow, 364 seconds
for me, which makes it really really slow
On Thu, Dec 15, 2005 at 11:15:20PM -0600, Joshua Isom wrote:
> I noticed a slight glitch with the regex-dna benchmark. The benchmark
> spec says to account for case insensitivity. So I added the :i
> modifier to the patterns and just stuck to the p6 rules. But using the
> :i modifier makes it
I noticed a slight glitch with the regex-dna benchmark. The benchmark
spec says to account for case insensitivity. So I added the :i
modifier to the patterns and just stuck to the p6 rules. But using the
:i modifier makes it take over three times as long. Although for the
example and the fu
I just finished three more shoot outs. Two are rather simple, a
floating point version of ack, and another that reads from stdin and
adds together the numbers on the lines. The third, is regex-dna. It
cheats a little, since as far as I know PGE doesn't have any regex
based substitu
13 matches
Mail list logo
