Re: Perl commandments - index .vs. //

2001-01-15 Thread Chris Benson
On Tue, Jan 09, 2001 at 12:50:08PM +, Piers Cawley wrote: David Cantrell [EMAIL PROTECTED] writes: Also index. These two snippets are equivalent: if($foo=~/foo/) { ... } if(index($foo, 'foo')!=-1) { ... } I always want to do just plain if(index(...)) though. ISTR that (for

Re: Perl commandments

2001-01-10 Thread Mark Fowler
Thou shalt optimise for programmer time unless absolutely necessary, Thou shalt optimise for programmer time unless O(x(n)) O(y(n)) and n is a suitably large value, where programmer time is both the time for the current programming task and any future programming time that may be expended

Re: Perl commandments

2001-01-10 Thread Greg McCarroll
* Mark Fowler ([EMAIL PROTECTED]) wrote: Thou shalt optimise for programmer time unless absolutely necessary, Thou shalt optimise for programmer time unless O(x(n)) O(y(n)) and n is what are O(x(n)) and O(y(n)), i'm not familiar with the x and y notation -- Greg McCarroll

Re: Perl commandments

2001-01-10 Thread Mark Fowler
what are O(x(n)) and O(y(n)), i'm not familiar with the x and y notation Okay, I was making it up on the fly; - They're meant to be the functions you're implementing. Hence O(x(n)) is running time of x on the data n, and the same for y. I think the point I was trying to make about future

Re: Perl commandments

2001-01-10 Thread Piers Cawley
Greg McCarroll [EMAIL PROTECTED] writes: * Mark Fowler ([EMAIL PROTECTED]) wrote: what are O(x(n)) and O(y(n)), i'm not familiar with the x and y notation Okay, I was making it up on the fly; - They're meant to be the functions you're implementing. Hence O(x(n)) is running time of x

Re: Perl commandments

2001-01-10 Thread Greg McCarroll
* Mark Fowler ([EMAIL PROTECTED]) wrote: Err... Twice as fast is still twice as fast when it's running on a processor that's twice as fast as it would have been. I now can't remember where I read a fascinating piece on the value of more efficient algorithms as computers got faster. But it

Re: Perl commandments

2001-01-10 Thread Peter Corlett
In article [EMAIL PROTECTED] you write: ok, but it gets more interesting as take into account moores law that reduces the effectiveness of optmisation by halving the improvement of the optimization every year [...] This depends. If you're just doing an optimisation that changes one O(N)

Re: Perl commandments

2001-01-10 Thread Greg McCarroll
* Peter Corlett ([EMAIL PROTECTED]) wrote: In article [EMAIL PROTECTED] you write: ok, but it gets more interesting as take into account moores law that reduces the effectiveness of optmisation by halving the improvement of the optimization every year [...] This depends. If you're just

Re: Perl commandments

2001-01-10 Thread David Hodgkinson
Greg McCarroll [EMAIL PROTECTED] writes: the best way to do this, if you see something is N^2 is to figure out how you could do it with a sort and hey presto it usually can be turned into NlogN+N .. NlogN This would involve beating aforementioned programmers round the head with Programming

Re: Perl commandments

2001-01-10 Thread Piers Cawley
David Hodgkinson [EMAIL PROTECTED] writes: Greg McCarroll [EMAIL PROTECTED] writes: the best way to do this, if you see something is N^2 is to figure out how you could do it with a sort and hey presto it usually can be turned into NlogN+N .. NlogN This would involve beating

Re: Perl commandments

2001-01-09 Thread Piers Cawley
Greg McCarroll [EMAIL PROTECTED] writes: * Piers Cawley ([EMAIL PROTECTED]) wrote: David Cantrell [EMAIL PROTECTED] writes: On Tue, Jan 09, 2001 at 11:25:18AM +, Greg McCarroll wrote: 6.) regular expressions are not the only way to code, length and substr

Re: Perl commandments

2001-01-09 Thread Greg McCarroll
* Piers Cawley ([EMAIL PROTECTED]) wrote: Greg McCarroll [EMAIL PROTECTED] writes: * Piers Cawley ([EMAIL PROTECTED]) wrote: David Cantrell [EMAIL PROTECTED] writes: On Tue, Jan 09, 2001 at 11:25:18AM +, Greg McCarroll wrote: 6.) regular expressions are not the only

Re: Perl commandments

2001-01-09 Thread Leon Brocard
Greg McCarroll sent the following bits through the ether: in my original rule it was all to do with good programming style, not eeking out every bit of performance, my reply was actually that i thought dave choose a very grey area in terms of programming style Indeed. And someone mentioned

Re: Perl commandments

2001-01-09 Thread Piers Cawley
Leon Brocard [EMAIL PROTECTED] writes: Greg McCarroll sent the following bits through the ether: in my original rule it was all to do with good programming style, not eeking out every bit of performance, my reply was actually that i thought dave choose a very grey area in terms of

Re: Perl commandments

2001-01-09 Thread Leon Brocard
Piers Cawley sent the following bits through the ether: This time. The discussion has been back and forth on various lists, usually with benchmarks. Thou shalt optimise for programmer time unless absolutely necessary, when thou shalt Benchmark and quoth both the benchmark and the results.