string concatentation vs. interpolation: which one is more optimal?

Programming Perl (The Camel Book) states that "String concatenation is
also implied by the interpolation that happens in double-quoted
strings."

print $a . ' is equal to ' . $b . ".\n"; # dot operator
print "$a is equal to $b.\n"; # interpolation

Can someone experienced in Perl source code confirm that they are
identical in terms of raw speed and memory use or not? The second one
is much cooler, and if so, I'm going to get rid of concatenation
altogether. (I'm not even considering the list variant separated by
commas, which is suboptimal).

Re: string concatentation vs. interpolation: which one is more optimal?

rihad schrieb:
> Programming Perl (The Camel Book) states that "String concatenation is
> also implied by the interpolation that happens in double-quoted
> strings."
>
> print $a . ' is equal to ' . $b . ".\n"; # dot operator
> print "$a is equal to $b.\n"; # interpolation
>
> Can someone experienced in Perl source code confirm that they are
> identical in terms of raw speed and memory use or not? The second one
> is much cooler, and if so, I'm going to get rid of concatenation
> altogether. (I'm not even considering the list variant separated by
> commas, which is suboptimal).
>

time perl -e '$a=$b=303; print "$a $b" for 1..39999999' > /dev/null
real 0m14.500s
user 0m14.460s
sys 0m0.022s

time perl -e '$a=$b=303; print $a." ".$b for 1..39999999' > /dev/null

real 0m12.111s
user 0m12.081s
sys 0m0.014s

Re: string concatentation vs. interpolation: which one is more optimal?

On Sep 26, 1:16 pm, papahuhn wrote:
> rihad schrieb:
>
> > Programming Perl (The Camel Book) states that "String concatenation is
> > also implied by the interpolation that happens in double-quoted
> > strings."
>
> > print $a . ' is equal to ' . $b . ".\n"; # dot operator
> > print "$a is equal to $b.\n"; # interpolation
>
> > Can someone experienced in Perl source code confirm that they are
> > identical in terms of raw speed and memory use or not? The second one
> > is much cooler, and if so, I'm going to get rid of concatenation
> > altogether. (I'm not even considering the list variant separated by
> > commas, which is suboptimal).
>
> time perl -e '$a=$b=303; print "$a $b" for 1..39999999' > /dev/null
> real 0m14.500s
> user 0m14.460s
> sys 0m0.022s
>
> time perl -e '$a=$b=303; print $a." ".$b for 1..39999999' > /dev/null
>
> real 0m12.111s
> user 0m12.081s
> sys 0m0.014s

it probably depends on the length of the string as well. i just wanted
to add the third option of passing print a list:

bash-2.03$ time perl -e '$x=$y=303; print "$x $y" for 1..16777216' > /
dev/null

real 0m17.710s
user 0m17.590s
sys 0m0.002s



bash-2.03$ time perl -e '$x=$y=303; print $x." ".$y for 1..16777216'
> /dev/null

real 0m17.115s
user 0m17.001s
sys 0m0.053s



bash-2.03$ time perl -e '$x=$y=303; print $x," ",$y for 1..16777216'
> /dev/null

real 1m18.498s
user 1m18.310s
sys 0m0.073s

MUCH slower for some reason...thoughts?

Re: string concatentation vs. interpolation: which one is more optimal?

papahuhn wrote:

> rihad schrieb:
>> Programming Perl (The Camel Book) states that "String concatenation is
>> also implied by the interpolation that happens in double-quoted
>> strings."
>>
>> print $a . ' is equal to ' . $b . ".\n"; # dot operator
>> print "$a is equal to $b.\n"; # interpolation
>>
>> Can someone experienced in Perl source code confirm that they are
>> identical in terms of raw speed and memory use or not? The second one
>> is much cooler, and if so, I'm going to get rid of concatenation
>> altogether. (I'm not even considering the list variant separated by
>> commas, which is suboptimal).
>>
>
> time perl -e '$a=$b=303; print "$a $b" for 1..39999999' > /dev/null
> real 0m14.500s
> user 0m14.460s
> sys 0m0.022s
>
> time perl -e '$a=$b=303; print $a." ".$b for 1..39999999' > /dev/null
>
> real 0m12.111s
> user 0m12.081s
> sys 0m0.014s


I found almost no difference:

$ time perl -e '$a=$b=303; print $a." ".$b for 1..39999999' > /dev/null

real 0m9.109s
user 0m9.095s
sys 0m0.012s

$ time perl -e '$a=$b=303; print "$a $b" for 1..39999999' > /dev/null

real 0m9.007s
user 0m8.997s
sys 0m0.010s



And as another poster has pointed out, using a list is very slow by
comparison:

$ time perl -e '$a=$b=303; print $a," ",$b for 1..39999999' > /dev/null

real 0m31.457s
user 0m31.438s
sys 0m0.018s


--
Brian Wakem

Re: string concatentation vs. interpolation: which one is more optimal?

On Sep 26, 9:42 am, rihad wrote:
> Programming Perl (The Camel Book) states that "String concatenation is
> also implied by the interpolation that happens in double-quoted
> strings."
>
> print $a . ' is equal to ' . $b . ".\n"; # dot operator
> print "$a is equal to $b.\n"; # interpolation
>
> Can someone experienced in Perl source code confirm that they are
> identical in terms of raw speed and memory use or not? The second one
> is much cooler, and if so, I'm going to get rid of concatenation
> altogether. (I'm not even considering the list variant separated by
> commas, which is suboptimal).

>From the benchmark below, it looks like interpolation and
concatenation come pretty close.

-------------------
#!/usr/bin/perl

use strict;
use warnings;
no warnings 'syntax';

use Benchmark qw 'cmpthese';

cmpthese 2000000 => {
'interp' => '$x=$y=303; $z = "$x $y"',
'concat' => '$x=$y=303; $z = $x . " " . $y',
'listjn' => '$x=$y=303; $z = $x," ",$y',
};

-------------- Results -------------------

Rate concat interp listjn
concat 1428571/s -- -1% -56%
interp 1438849/s 1% -- -56%
listjn 3278689/s 130% 128% --
------------------

I usually use one of the two that suits the most. When there is a
really long line involved, I tend to use the concatenation operator so
that I can break the line into multiple shorter lines. Interpolation
is fine in short lines.

HTH,
Mahesh.

Re: string concatentation vs. interpolation: which one is more optimal?

On Sep 26, 3:46 pm, Mahesh Asolkar wrote:
> On Sep 26, 9:42 am, rihad wrote:
>
> > Programming Perl (The Camel Book) states that "String concatenation is
> > also implied by the interpolation that happens in double-quoted
> > strings."
>
> > print $a . ' is equal to ' . $b . ".\n"; # dot operator
> > print "$a is equal to $b.\n"; # interpolation
>
> > Can someone experienced in Perl source code confirm that they are
> > identical in terms of raw speed and memory use or not? The second one
> > is much cooler, and if so, I'm going to get rid of concatenation
> > altogether. (I'm not even considering the list variant separated by
> > commas, which is suboptimal).
> >From the benchmark below, it looks like interpolation and
>
> concatenation come pretty close.
>
> -------------------
> #!/usr/bin/perl
>
> use strict;
> use warnings;
> no warnings 'syntax';
>
> use Benchmark qw 'cmpthese';
>
> cmpthese 2000000 => {
> 'interp' => '$x=$y=303; $z = "$x $y"',
> 'concat' => '$x=$y=303; $z = $x . " " . $y',
> 'listjn' => '$x=$y=303; $z = $x," ",$y',
>
> };
>
> -------------- Results -------------------
>
> Rate concat interp listjn
> concat 1428571/s -- -1% -56%
> interp 1438849/s 1% -- -56%
> listjn 3278689/s 130% 128% --
> ------------------
>

This is different than the tests the other posters conducted in that
you are not printing anything, and I don't think your listjn is doing
what you think it is.

Re: string concatentation vs. interpolation: which one is more optimal?

On Wed, 26 Sep 2007 09:42:11 -0700, rihad wrote:

>Subject: string concatentation vs. interpolation: which one is more optimal?

Something can't be "more optimal" than something else. Perhaps
"optimized"?

>print $a . ' is equal to ' . $b . ".\n"; # dot operator
>print "$a is equal to $b.\n"; # interpolation

You forget

print $a, ' is equal to ', $b, ".\n"; # print() takes a list

>Can someone experienced in Perl source code confirm that they are
>identical in terms of raw speed and memory use or not? The second one
>is much cooler, and if so, I'm going to get rid of concatenation
>altogether. (I'm not even considering the list variant separated by
>commas, which is suboptimal).

Do you *really* care?!? I agree that sometimes it *is* worth to look
at optimizations, but if you have performance problems, then the
printing of a short thing is highly likely *not* to be the cause of
them, and if it is, then you'd better switch to a faster language
altogether.


Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^ ..'KYU;*EVH[.FHF2W+#"\Z*5TI/ER 256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,

Re: string concatentation vs. interpolation: which one is more optimal?

On Wed, 26 Sep 2007 12:46:32 -0700, Mahesh Asolkar
wrote:

>cmpthese 2000000 => {
> 'interp' => '$x=$y=303; $z = "$x $y"',
> 'concat' => '$x=$y=303; $z = $x . " " . $y',
> 'listjn' => '$x=$y=303; $z = $x," ",$y',

The last entry does something completely different altogether, because
the list is evaluated in scalar context, whereas in print() it's in
list context.


Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^ ..'KYU;*EVH[.FHF2W+#"\Z*5TI/ER 256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,

Re: string concatentation vs. interpolation: which one is more optimal?

Quoth Michele Dondi :
> On Wed, 26 Sep 2007 09:42:11 -0700, rihad wrote:
>
> >Subject: string concatentation vs. interpolation: which one is more optimal?
>
> Something can't be "more optimal" than something else. Perhaps
> "optimized"?

Yes it can. 'more optimal' implies 'better, in an absolute sense',
whereas 'more optimized' would imply 'has been improved more'. That is,
if you have A which executes 10 times a second and B which executes 20
times, and you improve this to A executing 15 times and B executing 21
times, then A is 'more optimized' than B even though B is still 'more
optimal' than A. (Did that make any sense? :) )

> >print $a . ' is equal to ' . $b . ".\n"; # dot operator
> >print "$a is equal to $b.\n"; # interpolation
>
> You forget
>
> print $a, ' is equal to ', $b, ".\n"; # print() takes a list

He(?) mentioned that he had already discarded this case.

> >Can someone experienced in Perl source code confirm that they are
> >identical in terms of raw speed and memory use or not? The second one
> >is much cooler, and if so, I'm going to get rid of concatenation
> >altogether. (I'm not even considering the list variant separated by
> >commas, which is suboptimal).
>
> Do you *really* care?!? I agree that sometimes it *is* worth to look
> at optimizations, but if you have performance problems, then the
> printing of a short thing is highly likely *not* to be the cause of
> them, and if it is, then you'd better switch to a faster language
> altogether.

While I couldn't agree more, in the interests of answering the question
asked:

~% perl -MO=Concise -e'$a . " foo " . $b'
8 <@> leave[1 ref] vKP/REFC ->(end)
1 <0> enter ->2
2 <;> nextstate(main 1 -e:1) v ->3
7 <2> concat[t2] vKS/2 ->8
5 <2> concat[t1] sK/2 ->6
- <1> ex-rv2sv sK/1 ->4
3 <$> gvsv(*a) s ->4
4 <$> const(PV " foo ") s ->5
- <1> ex-rv2sv sK/1 ->7
6 <$> gvsv(*b) s ->7
-e syntax OK
~% perl -MO=Concise -e'"$a foo $b"'
8 <@> leave[1 ref] vKP/REFC ->(end)
1 <0> enter ->2
2 <;> nextstate(main 1 -e:1) v ->3
- <1> ex-stringify vK/1 ->8
- <0> ex-pushmark s ->3
7 <2> concat[t2] sKS/2 ->8
5 <2> concat[t1] sK/2 ->6
- <1> ex-rv2sv sK/1 ->4
3 <$> gvsv(*a) s ->4
4 <$> const(PV " foo ") s ->5
- <1> ex-rv2sv sK/1 ->7
6 <$> gvsv(*b) s ->7
-e syntax OK

The ex-foo ops are those that have been optimized away, so they compile
to exactly the same optree, so have exactly the same performance. Any
differences found elsewhere in the thread are errors in benchmarking.

Ben

Re: string concatentation vs. interpolation: which one is more optimal?

On Sep 26, 1:41 pm, Michele Dondi wrote:
> On Wed, 26 Sep 2007 12:46:32 -0700, Mahesh Asolkar
> wrote:
>
> >cmpthese 2000000 => {
> > 'interp' => '$x=$y=303; $z = "$x $y"',
> > 'concat' => '$x=$y=303; $z = $x . " " . $y',
> > 'listjn' => '$x=$y=303; $z = $x," ",$y',
>
> The last entry does something completely different altogether, because
> the list is evaluated in scalar context, whereas in print() it's in
> list context.
>

Michele and it_says_BALLS_on_your forehead, yes listjn is really quite
different from what the OP wanted. I was trying to isolate performance
of concatenation and interpolation operations from the IO overhead of
print - if at all. I did not pay attention on the side effect on
listjn. My apologies.

/Mahesh.

Re: string concatentation vs. interpolation: which one is more optimal?

it_says_BALLS_on_your forehead wrote:
> bash-2.03$ time perl -e '$x=$y=303; print $x," ",$y for 1..16777216'
>> /dev/null
>
> real 1m18.498s
> user 1m18.310s
> sys 0m0.073s
>
> MUCH slower for some reason...thoughts?

Interesting.

Seems to hang on perl stdout, consider ...
(taken from the other thread):
=>

use Benchmark qw 'cmpthese';
our $fh;
open $fh, '>', '/dev/null' or die $!;
cmpthese 2000000 => {
#'spinterp' => '$x=$y=303; $z = sprintf "%s", "$x $y"',
#'spconcat' => '$x=$y=303; $z = sprintf "%s", $x . " " . $y',
#'spLISTjn' => '$x=$y=303; $z = sprintf "%s", $x, " ", $y',
#'spJOINjn' => '$x=$y=303; $z = sprintf "%s", join("", $x," ",$y)',

'printerp' => '$x=$y=303; $z = print $fh "$x $y"',
'prconcat' => '$x=$y=303; $z = print $fh $x . " " . $y',
'prLISTjn' => '$x=$y=303; $z = print $fh $x," ",$y' ,
'prJOINjn' => '$x=$y=303; $z = print $fh join("", $x, " ", $y)',
};
close $fh;
<=

will give (here):

Rate prJOINjn prconcat printerp prLISTjn
prJOINjn 1298701/s -- -12% -24% -34%
prconcat 1481481/s 14% -- -13% -24%
printerp 1709402/s 32% 15% -- -13%
prLISTjn 1960784/s 51% 32% 15% --


"List" seems to be always fastest w/all print
varieties, except when going through stdio?

Regards

M.

Re: string concatentation vs. interpolation: which one is more optimal?

On Wed, 26 Sep 2007 19:16:16 +0200, papahuhn wrote:

>time perl -e '$a=$b=303; print "$a $b" for 1..39999999' > /dev/null
>real 0m14.500s
>user 0m14.460s
>sys 0m0.022s
>
>time perl -e '$a=$b=303; print $a." ".$b for 1..39999999' > /dev/null
>
>real 0m12.111s
>user 0m12.081s
>sys 0m0.014s

I think that using time is simply not reliable enough. Benchmark.pm is
not perfect either, but could come closer. I adapted another poster's
script as follows:

pilsner:~ [22:54:10]$ cat bench.pl
#!/usr/bin/perl

use strict;
use warnings;
no warnings 'once';

use Benchmark qw/cmpthese :hireswallclock/;

open F, '>/dev/null' or die;

cmpthese -20 => {
'interp' => '$x=$y=303; print F "$x $y"',
'concat' => '$x=$y=303; print F $x . " " . $y',
'listjn' => '$x=$y=303; print F $x," ",$y',
};

__END__
pilsner:~ [22:54:19]$ perl bench.pl
Rate interp concat listjn
interp 770456/s -- -0% -2%
concat 773664/s 0% -- -1%
listjn 783474/s 2% 1% --


Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^ ..'KYU;*EVH[.FHF2W+#"\Z*5TI/ER 256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,

Re: string concatentation vs. interpolation: which one is more optimal?

On Wed, 26 Sep 2007 23:59:56 +0200, Mirco Wahab
wrote:

>"List" seems to be always fastest w/all print
>varieties, except when going through stdio?

Maybe one needs to $++?


Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^ ..'KYU;*EVH[.FHF2W+#"\Z*5TI/ER 256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,

Re: string concatentation vs. interpolation: which one is more optimal?

On Wed, 26 Sep 2007 14:28:52 -0700, Mahesh Asolkar
wrote:

>Michele and it_says_BALLS_on_your forehead, yes listjn is really quite
>different from what the OP wanted. I was trying to isolate performance
>of concatenation and interpolation operations from the IO overhead of
>print - if at all. I did not pay attention on the side effect on
>listjn. My apologies.

(No need to apologize, you didn't offend anyone!) But you *can't*, for
the print() does the actual concatenation we're interested into.


Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^ ..'KYU;*EVH[.FHF2W+#"\Z*5TI/ER 256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,

Re: string concatentation vs. interpolation: which one is more optimal?

On Wed, 26 Sep 2007 22:27:56 +0100, Ben Morrow
wrote:

>Quoth Michele Dondi :
>> Something can't be "more optimal" than something else. Perhaps
>> "optimized"?
>
>Yes it can. 'more optimal' implies 'better, in an absolute sense',
>whereas 'more optimized' would imply 'has been improved more'. That is,
>if you have A which executes 10 times a second and B which executes 20
>times, and you improve this to A executing 15 times and B executing 21
>times, then A is 'more optimized' than B even though B is still 'more
>optimal' than A. (Did that make any sense? :) )

Well, "optimal" is an adjective of clear latin descent. In Italian it
maps to "ottimale" which is somewhat a variant (with a slightly
restricted acceptation) of "ottimo" (best) which in turn is the
superlative of "buono" (good) and IMHO still has attached the sense of
a superlative. I don't know if in English it's the same or I'm simply
biased by Italian grammar, but...

(/me realizes that he can check dict to be sure -\|/-\|/-\|/-\|/)

no, it seems it's the same in English:

: From The Collaborative International Dictionary of English v.0.48 :
:
: optimal \op"ti*mal\, a.
: Best possible; most desirable; optimum; as, the optimal
: concentration of a drug.
: [PJC]
:
:
: From WordNet (r) 2.0 :
:
: optimal
: adj : most desirable possible under a restriction expressed or
: implied; "an optimum return on capital"; "optimal
: concentration of a drug" [syn: optimum]

[other two entries snipped, but the concept is the same]

So to say that something is "more optimal" (than something else) is
like saying that something is "more best" (than something else). To
me, it's not correct.

>> print $a, ' is equal to ', $b, ".\n"; # print() takes a list
>
>He(?) mentioned that he had already discarded this case.

Sorry, didn't notice. Apologies to the OP.

>> Do you *really* care?!? I agree that sometimes it *is* worth to look
>> at optimizations, but if you have performance problems, then the
>> printing of a short thing is highly likely *not* to be the cause of
>> them, and if it is, then you'd better switch to a faster language
>> altogether.
>
>While I couldn't agree more, in the interests of answering the question
>asked:
>
> ~% perl -MO=Concise -e'$a . " foo " . $b'
[snip]
>The ex-foo ops are those that have been optimized away, so they compile
>to exactly the same optree, so have exactly the same performance. Any
>differences found elsewhere in the thread are errors in benchmarking.

Very instructive, thanks!


Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^ ..'KYU;*EVH[.FHF2W+#"\Z*5TI/ER 256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,

[OT] optimal vs. optimized [was: Re: string concatentation...]

Quoth Michele Dondi :
> On Wed, 26 Sep 2007 22:27:56 +0100, Ben Morrow
> wrote:
>
> >Quoth Michele Dondi :
> >> Something can't be "more optimal" than something else. Perhaps
> >> "optimized"?
> >
> >Yes it can. 'more optimal' implies 'better, in an absolute sense',
> >whereas 'more optimized' would imply 'has been improved more'. That is,
> >if you have A which executes 10 times a second and B which executes 20
> >times, and you improve this to A executing 15 times and B executing 21
> >times, then A is 'more optimized' than B even though B is still 'more
> >optimal' than A. (Did that make any sense? :) )
>
> Well, "optimal" is an adjective of clear latin descent. In Italian it
> maps to "ottimale" which is somewhat a variant (with a slightly
> restricted acceptation) of "ottimo" (best) which in turn is the
> superlative of "buono" (good) and IMHO still has attached the sense of
> a superlative. I don't know if in English it's the same or I'm simply
> biased by Italian grammar, but...
>
> (/me realizes that he can check dict to be sure -\|/-\|/-\|/-\|/)

>
> So to say that something is "more optimal" (than something else) is
> like saying that something is "more best" (than something else). To
> me, it's not correct.

You have a good point; however, as is usual in English grammar,
arguments from ancestry don't always help :). For instance, if 'optimum'
and derived words are necessarily superlative, then 'optimized' means
'made best', and A cannot be more optimized than B either. A has either
been 'made best' or it hasn't.

I think what has happened is that, in English, 'optimal' and
'optimized' have acquired something of a sense of 'efficient', which is
clearly comparative, rather than of 'best' in a more general sense. So
optimizing a program doesn't necessarily make it better, it simply makes
it more efficient: other things may be more important than efficiency,
portability or readability for example. 'Optimum' has not (I would say)
changed like this, so I find it odd that the dictionaries you quoted say
it is synonymous with 'optimal': I would entirely agree that 'more
optimum' is obviously wrong.

Theory aside, a quick google shows that 'more optimal' is definitely
acceptable usage; for instance (a random example from the results)

This is because the claim that A is more optimal or better adapted
than B with respect to some function does not entail that A is
optimal or even good with respect to that function.

http://www.seop.leeds.ac.uk/archives/fall1999/entries/teleol ogy-biology/

which shows that 'optimal' can have the sense of 'efficient' or
'effective' rather than simply 'best'.

[English] not only borrows words from other languages; it has on
occasion chased other languages down dark alley-ways, clubbed them
unconscious and rifled their pockets for new vocabulary.
-- James Nicoll
:)

Ben

Re: string concatentation vs. interpolation: which one is more optimal?

On Thu, 27 Sep 2007 00:35:45 +0200, Michele Dondi
wrote:

>>"List" seems to be always fastest w/all print
>>varieties, except when going through stdio?
>
>Maybe one needs to $++?

I meant $|++; # Sorry


Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^ ..'KYU;*EVH[.FHF2W+#"\Z*5TI/ER 256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,

Re: string concatentation vs. interpolation: which one is more optimal?

On Sep 27, 2:27 am, Ben Morrow wrote:
> Quoth Michele Dondi :
> He(?) mentioned that he had already discarded this case.
>
Yes, I'm a "he" :)

> > >Can someone experienced in Perl source code confirm that they are
> > >identical in terms of raw speed and memory use or not? The second one
> > >is much cooler, and if so, I'm going to get rid of concatenation
> > >altogether. (I'm not even considering the list variant separated by
> > >commas, which is suboptimal).
>
>
>
[snipped]
> The ex-foo ops are those that have been optimized away, so they compile
> to exactly the same optree, so have exactly the same performance. Any
> differences found elsewhere in the thread are errors in benchmarking.
>
> Ben

Thank you very much, Ben! Thanks everyone else for sparkling up the
topic too.


>Quoth Michele Dondi :
>> Something can't be "more optimal" than something else. Perhaps
>> "optimized"?

> Well, "optimal" is an adjective of clear latin descent. In Italian it
> maps to "ottimale" which is somewhat a variant (with a slightly
> restricted acceptation) of "ottimo" (best) which in turn is the
> superlative of "buono" (good) and IMHO still has attached the sense of
> a superlative. I don't know if in English it's the same or I'm simply
> biased by Italian grammar, but...

My apologies if "more optimal" happens to not be proper English: I
simply mapped the Russian " " [boleye optimal'niy] to
"more optimal" verbatim, which happened to not be too far from the
truth, as Ben's counterarguments later showed :)

It's very amusing to learn English and Perl side by side. For example,
"unless (...)" Perl lingo doesn't ring the bell for non-native (non-
american?) English speakers too much (at least not for me), so I try
to avoid it and use "if (not ...)" instead. "California or bust" is
okay, though (open ... or die $!)

Re: [OT] optimal vs. optimized

Ben Morrow wrote:

> I think what has happened is that, in English, 'optimal' and
> 'optimized' have acquired something of a sense of 'efficient',

Both are meaningless.

I always try to exchange 'optimize' by 'maximize' or 'minimize', e.g.

- minimize runtime
- minimize memory usage
- maximize execution rate
- maximize readability
- maximize test coverage

Helmut Wollmersdorfer

Re: string concatentation vs. interpolation: which one is more optimal?

In article <1190824931.665621.151990@50g2000hsm.googlegroups.com>,
rihad wrote:

> Programming Perl (The Camel Book) states that "String concatenation is
> also implied by the interpolation that happens in double-quoted
> strings."

> Can someone experienced in Perl source code confirm that they are
> identical in terms of raw speed and memory use or not?

When you start looking at the speed of things like this and actaully
caring about the answer, you'll probably find that Perl is not the
right tool for the job. Perl is really fast, but if this sort of
operation is too slow for you, then the bigger tasks in Perl, uch as
using a module, will just kill your performance (relatively).

Before anyone gets too concerned about small details like this
(especially when Perl is not constrained to implement them in any way
and the next release of Perl might do it differently), try profiling
the application that you are concerned about. You'll find easier and
slower things to fix and worry about :)

Re: [OT] optimal vs. optimized

In article , Helmut Wollmersdorfer
wrote:

> Ben Morrow wrote:

> > I think what has happened is that, in English, 'optimal' and
> > 'optimized' have acquired something of a sense of 'efficient',

> Both are meaningless.
>
> I always try to exchange 'optimize' by 'maximize' or 'minimize', e.g.
>
> - minimize runtime
> - minimize memory usage
> - maximize execution rate


well, minimize and maximize work well for single dimensions, but when
you get into multi-dimensional concerns (say, memoery and speed), you
can't use those terms that well anymore. In the memory-speed surface
there will points where one or the other dimension are better, some
local minimums, and so on, but the optimal solution might not be the
one that has the absolute minumum for either of the factors.

I like "optimal" still, but people have to realize that it's a relative
and subjective term based on the assumptions and goals of the person
using it. It's not meaningless although it is often used without
context and with the implicit asumptions that everyone wants the same
thing. :)

Re: string concatentation vs. interpolation: which one is more optimal?

On Sep 28, 2:03 am, brian d foy wrote:
> In article <1190824931.665621.151...@50g2000hsm.googlegroups.com>,
>
> rihad wrote:
> > Programming Perl (The Camel Book) states that "String concatenation is
> > also implied by the interpolation that happens in double-quoted
> > strings."
> > Can someone experienced in Perl source code confirm that they are
> > identical in terms of raw speed and memory use or not?
>
> When you start looking at the speed of things like this and actaully
> caring about the answer, you'll probably find that Perl is not the
> right tool for the job. Perl is really fast, but if this sort of
> operation is too slow for you, then the bigger tasks in Perl, uch as
> using a module, will just kill your performance (relatively).
>
Hi, brian d foy (I like the way your name is spelled that makes you
stand out from the rest throughout "Learning Perl" and the Perl FAQ -
it must be you really deserve this distinction :))

It's not that I want Perl to be as fast as assembly, no. I just don't
want to be using suboptimal patterns from the start if it can be done
better AND if the loss of programming convenience does not outweigh
performance gains. IOW, I wouldn't write CGI's in assembly because web
servers being normally written in C would probably be the
bottleneck :) (greatly simplifying, of course)

Besides, interpolation is almost always more legible than
concatenation, the fact that rarely goes hand in hand with efficiency.
It would be a sin not to exploit their being identical (not to be
taken literally). Sadly, most strings I've seen are being built up
disregarding interpolation. This struck my curiosity enough to ask
here.

> Before anyone gets too concerned about small details like this
> (especially when Perl is not constrained to implement them in any way
> and the next release of Perl might do it differently), try profiling
> the application that you are concerned about. You'll find easier and
> slower things to fix and worry about :)

Ok this seems to be coming from the innards of great developing
experience. Again, the reason I asked is based on my strive for
perfection, not that I was counting on an answer here to make more
money or anything.

/Here I reread what's been written, and .../

Still... why shouldn't Perl (or language Foo) programmers care about
efficiency if OS programmers _do_ care?

Re: string concatentation vs. interpolation: which one is more optimal?

rihad wrote:
> On Sep 28, 2:03 am, brian d foy wrote:
>> In article <1190824931.665621.151...@50g2000hsm.googlegroups.com>,
>>
>> rihad wrote:
>> > Programming Perl (The Camel Book) states that "String concatenation is
>> > also implied by the interpolation that happens in double-quoted
>> > strings."
>> > Can someone experienced in Perl source code confirm that they are
>> > identical in terms of raw speed and memory use or not?
>>
>> When you start looking at the speed of things like this and actaully
>> caring about the answer, you'll probably find that Perl is not the
>> right tool for the job. Perl is really fast, but if this sort of
>> operation is too slow for you, then the bigger tasks in Perl, uch as
>> using a module, will just kill your performance (relatively).


> Ok this seems to be coming from the innards of great developing
> experience.


Here's some more:

http://en.wikipedia.org/wiki/Optimization_(computer_science) #When_to_optimize


--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"

Re: string concatentation vs. interpolation: which one is more optimal?

In article <1190824931.665621.151990@50g2000hsm.googlegroups.com>,
rihad wrote:

: print $a . ' is equal to ' . $b . ".\n"; # dot operator
: print "$a is equal to $b.\n"; # interpolation

These compile to the same ppcode.

Greg
--
Not a place upon earth might be so happy as America. Her situation is
remote from all the wrangling world and she has nothing to do but trade
with them.
-- Thomas Paine

Re: string concatentation vs. interpolation: which one is more optimal?

Quoth rihad :
>
> Besides, interpolation is almost always more legible than
> concatenation,

See also http://blog.plover.com/prs/nyc.html .

> > Before anyone gets too concerned about small details like this
> > (especially when Perl is not constrained to implement them in any way
> > and the next release of Perl might do it differently), try profiling
> > the application that you are concerned about. You'll find easier and
> > slower things to fix and worry about :)
>
> Ok this seems to be coming from the innards of great developing
> experience. Again, the reason I asked is based on my strive for
> perfection, not that I was counting on an answer here to make more
> money or anything.
>
> /Here I reread what's been written, and .../
>
> Still... why shouldn't Perl (or language Foo) programmers care about
> efficiency if OS programmers _do_ care?

The point is, you should care when, and only when, it matters. Worrying
about micro-optimization without having profiled first is always a waste
of time, and only leads to writing illegible code.

Ben

Re: [OT] optimal vs. optimized

>>>>> "bdf" == brian d foy writes:

bdf> I like "optimal" still, but people have to realize that it's
bdf> a relative and subjective term based on the assumptions and
bdf> goals of the person using it. It's not meaningless although
bdf> it is often used without context and with the implicit
bdf> asumptions that everyone wants the same thing. :)

I'm not sure it's subjective, and I certainly don't think it's
meaningless; I think in common usage it's vague, and I agree that the
context is almost always incorrectly implied or inferred.

Charlton


--
Charlton Wilbur
cwilbur@chromatico.net

Re: string concatentation vs. interpolation: which one is more optimal?

>>>>> "r" == rihad writes:

r> Still... why shouldn't Perl (or language Foo) programmers care
r> about efficiency if OS programmers _do_ care?

Perl programmers care about efficiency in the same way that OS
programmers care about efficiency: it's one of a set of things to
worry about (which include expressiveness, readability,
maintainability, portability), and tradeoffs among them need to be
carefully balanced. What suits one project won't suit another.

The Linux kernel isn't written in C because C is inherently more
efficient than any other language, for instance; it's written in C
because C offers the tradeoff between efficiency, maintainability, and
control that is closest to what they need. Perl puts a lot more
emphasis on programmer time than computer time, which is not the right
solution for operating systems (which are written once and run many
thousands of times), but is the right solution for one-off scripts,
custom work with small teams, and other situations that are not likely
to be CPU-bound.

The right answer for performance tuning in Perl is the same as the
right answer for development in C: write the @#$% thing, then profile
it and fix the parts that are too slow. You get the biggest win from
choosing the right data structure and the right algorithm; after that
it's all rapidly diminishing returns.

Charlton


--
Charlton Wilbur
cwilbur@chromatico.net

Re: string concatentation vs. interpolation: which one is more optimal?

Tad McClellan writes:
> Here's some more:
>
> http://en.wikipedia.org/wiki/Optimization_(computer_science) #When_to_optimize

I prefer the relatively pithy "Not Yet".

-=Eric

Re: string concatentation vs. interpolation: which one is more optimal?

On Sep 28, 8:28 pm, Ben Morrow wrote:

> When you start looking at the speed of things like this and actaully
> caring about the answer, you'll probably find that Perl is not the
> right tool for the job. Perl is really fast, but if this sort of
> operation is too slow for you, then the bigger tasks in Perl, uch as
> using a module, will just kill your performance (relatively).

I'm not saying I want Perl to be faster than assembly. I just want to
write fastest Perl code I can, all constrained within Perl's own
performance overhead. Imagine tomorrow there will be (if not already)
some Perl hardware executing opcode natively, and then what, all of a
sudden micro-tunings begin to make sense? In this respect, I don't
believe there's any obvious reason to take the sub-optimal path in any
language (if you have the time).

> > Still... why shouldn't Perl (or language Foo) programmers care about
> > efficiency if OS programmers _do_ care?
>
> The point is, you should care when, and only when, it matters. Worrying
> about micro-optimization without having profiled first is always a waste
> of time, and only leads to writing illegible code.
>
I couldn't agree more. I'm only micro-optimizing obvious usage
patterns such as string interpolation/concatenation vs. list (such as
print "$foo $bar"; vs. print $foo, ' ', $bar;) which is *always*
faster by its nature. In assembly, one would surely be using "inc
[mem]" instead of "add [mem], 1" because the former is more optimal
[sic].

Re: string concatentation vs. interpolation: which one is more optimal?

rihad wrote:

> I couldn't agree more. I'm only micro-optimizing obvious usage
> patterns such as string interpolation/concatenation vs. list (such as
> print "$foo $bar"; vs. print $foo, ' ', $bar;) which is *always*
> faster by its nature.

Let me see if I understand correctly. The one that should be used is

print $foo, ' ', $bar;

since printing a list is faster than building a string and printing that.

I don't understand why in your original posting you referred to
"the list variant separated by commas" as being suboptimal.

-Joe

Re: string concatentation vs. interpolation: which one is more optimal?

On Sep 29, 4:27 pm, Joe Smith wrote:
> Let me see if I understand correctly. The one that should be used is
>
> print $foo, ' ', $bar;
>
> since printing a list is faster than building a string and printing that.
>
> I don't understand why in your original posting you referred to
> "the list variant separated by commas" as being suboptimal.
>

Damn ;-) I hoped no one would notice. It's the other way around. Read
it as I mean it (c)

Re: string concatentation vs. interpolation: which one is moreoptimal?

On 2007-09-26 21:27, Ben Morrow wrote:
> Quoth Michele Dondi :
>> >Can someone experienced in Perl source code confirm that they are
>> >identical in terms of raw speed and memory use or not? The second one
>> >is much cooler, and if so, I'm going to get rid of concatenation
>> >altogether. (I'm not even considering the list variant separated by
>> >commas, which is suboptimal).
>>
>> Do you *really* care?!? I agree that sometimes it *is* worth to look
>> at optimizations, but if you have performance problems, then the
>> printing of a short thing is highly likely *not* to be the cause of
>> them, and if it is, then you'd better switch to a faster language
>> altogether.
>
> While I couldn't agree more, in the interests of answering the question
> asked:
[...]
> The ex-foo ops are those that have been optimized away, so they compile
> to exactly the same optree, so have exactly the same performance. Any
> differences found elsewhere in the thread are errors in benchmarking.

the time difference between

perl -e '$a=$b=303; print "$a $b" for 1..39999999' > /dev/null

and

perl -e '$a=$b=303; print $a." ".$b for 1..39999999' > /dev/null

is real on some machines (it is very noticable on my Core2 in 32 bit
mode (19.3 vs. 15.5 seconds) less noticable on a Core2 in 64 bit mode or
a P4, and unmeasurable on a PIII - perl 5.8.8 in all cases), so the code
can't be the same. Either the output of perl -MO=Concise is wrong or at
least incomplete or you are interpreting it wrong (how does it know that
there are instructions which were optimized away? Are the instructions
perhaps still there with a "don't execute" flag? Or does it produce its
output at an earlier stage of compilation?). One aspect which is
obviously missing from the output are the adresses of the instructions.
Alignment can have a large impact on performance.

hp


--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"

Re: string concatentation vs. interpolation: which one is more optimal?

On Sep 29, 7:04 pm, "Peter J. Holzer" wrote:
> the time difference between
>
> perl -e '$a=$b=303; print "$a $b" for 1..39999999' > /dev/null
>
> and
>
> perl -e '$a=$b=303; print $a." ".$b for 1..39999999' > /dev/null
>
> is real on some machines (it is very noticable on my Core2 in 32 bit
> mode (19.3 vs. 15.5 seconds) less noticable on a Core2 in 64 bit mode or
> a P4, and unmeasurable on a PIII - perl 5.8.8 in all cases), so the code
> can't be the same. Either the output of perl -MO=Concise is wrong or at

Try running each test several times and comparing the average times. I
can't see any difference beyond +/- 1% error, can you? Then again, my
Athlon XP might be the "unmeasurable" one.

Re: string concatentation vs. interpolation: which one is moreoptimal?

On 2007-09-29 15:17, rihad wrote:
> On Sep 29, 7:04 pm, "Peter J. Holzer" wrote:
>> the time difference between
>>
>> perl -e '$a=$b=303; print "$a $b" for 1..39999999' > /dev/null
>>
>> and
>>
>> perl -e '$a=$b=303; print $a." ".$b for 1..39999999' > /dev/null
>>
>> is real on some machines (it is very noticable on my Core2 in 32 bit
>> mode (19.3 vs. 15.5 seconds) less noticable on a Core2 in 64 bit mode or
>> a P4, and unmeasurable on a PIII - perl 5.8.8 in all cases), so the code
>> can't be the same. Either the output of perl -MO=Concise is wrong or at
>
> Try running each test several times and comparing the average times.

I did that, of course. The timings are stable to about 0.2 seconds -
much less than the difference. (Hardly surprising for a program which is
almost completely CPU bound).

The difference almost vanishes if the builtin variables $a and $b are
replaced by lexical variables:

#!/usr/bin/perl
use warnings;
use strict;
my ($x, $y);
$x=$y=303; print "$x $y" for 1..39999999;

takes 17.70s, 17.70s, 17.80s user time in three successive runs.

#!/usr/bin/perl
use warnings;
use strict;
my ($x, $y);
$x=$y=303; print $x." ".$y for 1..39999999;

takes 17.57s, 17.44s, 17.59s user time in three successive runs.
I was running the scripts alternately to reduce the influence of other
task potentially running at the same time. The concatenation version
still seems a bit faster, but that could be a measurement error.

Note that the timings are now almost exactly between the timings for the
same scripts with $a and $b - one got faster and the other slower.

Using our gives similar results as my, except that it's about 2 seconds
faster and now the interpolating version is consistently a tiny bit
faster.

So it could be some wierd interaction with $a and $b, although I haven't
the slightest idea what it could be.

(Another unexpected result is that all of these scripts get quite a lot
slower if I use the string "303" instead of the number 303).

hp



--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"

Re: [OT] optimal vs. optimized [was: Re: string concatentation...]

Note: crossposted to some supposedly relevant groups. If anyone has
better ones to suggest, then they're welcome.

For people reading this outside of clpmisc, the question arose with
the following post:



which in turn was in response to an observation of mine. The whole
thread is available from GG at the following URL:




============================================================ ====================


On Thu, 27 Sep 2007 02:59:52 +0100, Ben Morrow
wrote:

>You have a good point; however, as is usual in English grammar,
>arguments from ancestry don't always help :). For instance, if 'optimum'
>and derived words are necessarily superlative, then 'optimized' means
>'made best', and A cannot be more optimized than B either. A has either
>been 'made best' or it hasn't.

I'm not sure. 'To optimize' could mean 'to try to reach the optimum'
(or optimal incarnation - of something) thus 'optimized' may mean 'to
have undergone the process of optimization', thus to have gone as much
as possible (wrt some constraints, e.g. time) towards the optimum
without necessarily reaching it. By contrast I see 'optimal' very much
as a synonym of 'optimum' itself, and personally I find much more
acceptable the expression 'more optimzed' than 'more optimal'.

>I think what has happened is that, in English, 'optimal' and
>'optimized' have acquired something of a sense of 'efficient', which is
>clearly comparative, rather than of 'best' in a more general sense. So

That they have been or are occasionally used in that sense may well
be, but I would be surprised to learn that they have actually
"acquired" it. If I paste the remaining two entries found by dict
(which I snipped last time), namely:

: From Moby Thesaurus II by Grady Ward, 1.0 :
:
: 24 Moby Thesaurus words for "optimal":
: best, champion, choice, elect, elite, for the best, greatest,
: handpicked, matchless, optimum, paramount, peerless, picked, prime,
: prize, quintessential, select, supreme, surpassing, unmatchable,
: unmatched, unparalleled, unsurpassed, very best
:
:
:
:
: From The Free On-line Dictionary of Computing (27 SEP 03) :
:
: optimal
:
: 1. Describes a solution to a problem which
: minimises some cost function. Linear programming is one
: technique used to discover the optimal solution to certain
: problems.
:
: 2. Of code: best or most efficient in time,
: space or code size.

you will see that the last one, which is specifically aimed at CS and
IT -and it's actually relevant here- still does not mention just
"efficiency". Thus my take on the issue is that 'optimal' is not just
'efficient' as alleged, but 'the most efficient'. All this, still at a
syntactical level, i.e. we're not discussing yet what "efficient"
could mean.

I'll repeat myself: maybe this strikes me more strongly because of my
implicit Latin heritage, but I still find 'more optimal' to sound like
'more most efficient'.

>optimizing a program doesn't necessarily make it better, it simply makes
>it more efficient: other things may be more important than efficiency,

This is semantics. "better" and "more efficient" are both
comparatives. That other things may be more important than efficiency
(and indeed I think they are) is irrelevant to the linguistic point
being discussed here.

>portability or readability for example. 'Optimum' has not (I would say)

We're not necessarily speaking of computer programs here, and although
it is not in the dictionaries I mentioned before I think that the
italian definition I found for 'ottimale' may well be translated in
English, which is what I'm trying to do now:

: adj: of something that, according to some determinate parameters or
: points of view, represents the *best* possible condition or the *best*
: possible result: e.g. optimal life conditions.

If you accept this, then you can still speak in the context of
programming of a

>changed like this, so I find it odd that the dictionaries you quoted say
>it is synonymous with 'optimal': I would entirely agree that 'more
>optimum' is obviously wrong.

In all earnestness I had never witnessed the use you're reporting of
'optimal', namely that in which it is not a superlative. But
admittedly I do not read *that* much in English.

>Theory aside, a quick google shows that 'more optimal' is definitely
>acceptable usage; for instance (a random example from the results)

Huh?!? Google may show that "ur so c00l bro" is acceptable usage!!

> This is because the claim that A is more optimal or better adapted
> than B with respect to some function does not entail that A is
> optimal or even good with respect to that function.
>
> http://www.seop.leeds.ac.uk/archives/fall1999/entries/teleol ogy-biology/
>
>which shows that 'optimal' can have the sense of 'efficient' or
>'effective' rather than simply 'best'.

Well, that is from an academic institution thus should not fall in the
"ur so c00l bro", but I'm still skeptical: young researchers, however
good may they be in their research field, often tend to speak and
write very bad in their own mother tongue. For example in Italy some
young mathematicians are beginning to use the horrible anglophonic
"surgettiva" in place of the traditional "suriettiva", not that a word
borrowed from English is so bad in and of itself, but it is when
there's a perfectly fine alternative in one's own language.

> [English] not only borrows words from other languages; it has on
> occasion chased other languages down dark alley-ways, clubbed them
> unconscious and rifled their pockets for new vocabulary.
> -- James Nicoll

I knew that. In fact it's amongs my .sigs!


Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^ ..'KYU;*EVH[.FHF2W+#"\Z*5TI/ER 256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,

Re: optimal vs. optimized [was: Re: string concatentation...]

On Oct 2, 1:42 am, Michele Dondi wrote:
> Note: crossposted to some supposedly relevant groups. If anyone has
> better ones to suggest, then they're welcome.
>
> For people reading this outside of clpmisc, the question arose with
> the following post:
>
>
>
> which in turn was in response to an observation of mine. The whole
> thread is available from GG at the following URL:
>
> ndns.org>
>
> ==================== =====
==================== =====3D=
==================== =====3D=
=­=====3D
>
> On Thu, 27 Sep 2007 02:59:52 +0100, Ben Morrow
> wrote:
>
> >You have a good point; however, as is usual in English grammar,
> >arguments from ancestry don't always help :). For instance, if 'optimum'
> >and derived words are necessarily superlative, then 'optimized' means
> >'made best', and A cannot be more optimized than B either. A has either
> >been 'made best' or it hasn't.
>
> I'm not sure. 'To optimize' could mean 'to try to reach the optimum'
> (or optimal incarnation - of something) thus 'optimized' may mean 'to
> have undergone the process of optimization', thus to have gone as much
> as possible (wrt some constraints, e.g. time) towards the optimum
> without necessarily reaching it. By contrast I see 'optimal' very much
> as a synonym of 'optimum' itself, and personally I find much more
> acceptable the expression 'more optimzed' than 'more optimal'.
>
> >I think what has happened is that, in English, 'optimal' and
> >'optimized' have acquired something of a sense of 'efficient', which is
> >clearly comparative, rather than of 'best' in a more general sense. So
>
> That they have been or are occasionally used in that sense may well
> be, but I would be surprised to learn that they have actually
> "acquired" it. If I paste the remaining two entries found by dict
> (which I snipped last time), namely:
>
> : From Moby Thesaurus II by Grady Ward, 1.0 :
> :
> : 24 Moby Thesaurus words for "optimal":
> : best, champion, choice, elect, elite, for the best, greatest,
> : handpicked, matchless, optimum, paramount, peerless, picked, prime,
> : prize, quintessential, select, supreme, surpassing, unmatchable,
> : unmatched, unparalleled, unsurpassed, very best
> : =20
> : =20
> :
> :
> : From The Free On-line Dictionary of Computing (27 SEP 03) :
> :
> : optimal
> : =20
> : 1. Describes a solution to a problem which
> : minimises some cost function. Linear programming is one
> : technique used to discover the optimal solution to certain
> : problems.
> : =20
> : 2. Of code: best or most efficient in time,
> : space or code size.
>
> you will see that the last one, which is specifically aimed at CS and
> IT -and it's actually relevant here- still does not mention just
> "efficiency". Thus my take on the issue is that 'optimal' is not just
> 'efficient' as alleged, but 'the most efficient'. All this, still at a
> syntactical level, i.e. we're not discussing yet what "efficient"
> could mean.
>
> I'll repeat myself: maybe this strikes me more strongly because of my
> implicit Latin heritage, but I still find 'more optimal' to sound like
> 'more most efficient'.
>
> >optimizing a program doesn't necessarily make it better, it simply makes
> >it more efficient: other things may be more important than efficiency,
>
> This is semantics. "better" and "more efficient" are both
> comparatives. That other things may be more important than efficiency
> (and indeed I think they are) is irrelevant to the linguistic point
> being discussed here.
>
> >portability or readability for example. 'Optimum' has not (I would say)
>
> We're not necessarily speaking of computer programs here, and although
> it is not in the dictionaries I mentioned before I think that the
> italian definition I found for 'ottimale' may well be translated in
> English, which is what I'm trying to do now:
>
> : adj: of something that, according to some determinate parameters or
> : points of view, represents the *best* possible condition or the *best*
> : possible result: e.g. optimal life conditions.
>
> If you accept this, then you can still speak in the context of
> programming of a
>
> >changed like this, so I find it odd that the dictionaries you quoted say
> >it is synonymous with 'optimal': I would entirely agree that 'more
> >optimum' is obviously wrong.
>
> In all earnestness I had never witnessed the use you're reporting of
> 'optimal', namely that in which it is not a superlative. But
> admittedly I do not read *that* much in English.
>
> >Theory aside, a quick google shows that 'more optimal' is definitely
> >acceptable usage; for instance (a random example from the results)
>
> Huh?!? Google may show that "ur so c00l bro" is acceptable usage!!
>
> > This is because the claim that A is more optimal or better adapted
> > than B with respect to some function does not entail that A is
> > optimal or even good with respect to that function.
>
> > http://www.seop.leeds.ac.uk/archives/fall1999/entries/teleol ogy-biol=
ogy/
>
> >which shows that 'optimal' can have the sense of 'efficient' or
> >'effective' rather than simply 'best'.
>
> Well, that is from an academic institution thus should not fall in the
> "ur so c00l bro", but I'm still skeptical: young researchers, however
> good may they be in their research field, often tend to speak and
> write very bad in their own mother tongue. For example in Italy some
> young mathematicians are beginning to use the horrible anglophonic
> "surgettiva" in place of the traditional "suriettiva", not that a word
> borrowed from English is so bad in and of itself, but it is when
> there's a perfectly fine alternative in one's own language.
>
> > [English] not only borrows words from other languages; it has on
> > occasion chased other languages down dark alley-ways, clubbed them
> > unconscious and rifled their pockets for new vocabulary.
> > -- James Nicoll
>
> I knew that. In fact it's amongs my .sigs!
>
> Michele
> --
> {$_=3Dpack'B8'x25,unpack'A8'x32,$a^=3Dsub{pop^pop}->(map substr
> (($a||=3Djoin'',map--$|x$_,(unpack'w',unpack'u','G^ > .'KYU;*EVH[.FHF2W+#"\Z*5TI/ER > 256),7,249);s/[^\w,]/ /g;$ \=3D/^J/?$/:"\r";print,redo}#JAPH,



Yes, vocabulary in English was made rich by the words from many other
languages. These languages were of the places where British and
English moved in the course of history. I saw a website which helps in
knowing words and building vocabulary. It is www.buildingvocabulary.org.

Re: optimal vs. optimized [was: Re: string concatentation...]

On Oct 5, 2:10 pm, vocabulary wrote:
> On Oct 2, 1:42 am, Michele Dondi wrote:
>
>
>
>
>
> > Note: crossposted to some supposedly relevant groups. If anyone has
> > better ones to suggest, then they're welcome.
>
> > For people reading this outside of clpmisc, the question arose with
> > the following post:
>
> >
>
> > which in turn was in response to an observation of mine. The whole
> > thread is available from GG at the following URL:
>
> > dyndns.org>
>
> > ==================== ===3D=
==================== =====3D=
==================== =====3D=
==­­=====3D
>
> > On Thu, 27 Sep 2007 02:59:52 +0100, Ben Morrow
> > wrote:
>
> > >You have a good point; however, as is usual in English grammar,
> > >arguments from ancestry don't always help :). For instance, if 'optimu=
m'
> > >and derived words are necessarily superlative, then 'optimized' means
> > >'made best', and A cannot be more optimized than B either. A has either
> > >been 'made best' or it hasn't.
>
> > I'm not sure. 'To optimize' could mean 'to try to reach the optimum'
> > (or optimal incarnation - of something) thus 'optimized' may mean 'to
> > have undergone the process of optimization', thus to have gone as much
> > as possible (wrt some constraints, e.g. time) towards the optimum
> > without necessarily reaching it. By contrast I see 'optimal' very much
> > as a synonym of 'optimum' itself, and personally I find much more
> > acceptable the expression 'more optimzed' than 'more optimal'.
>
> > >I think what has happened is that, in English, 'optimal' and
> > >'optimized' have acquired something of a sense of 'efficient', which is
> > >clearly comparative, rather than of 'best' in a more general sense. So
>
> > That they have been or are occasionally used in that sense may well
> > be, but I would be surprised to learn that they have actually
> > "acquired" it. If I paste the remaining two entries found by dict
> > (which I snipped last time), namely:
>
> > : From Moby Thesaurus II by Grady Ward, 1.0 :
> > :
> > : 24 Moby Thesaurus words for "optimal":
> > : best, champion, choice, elect, elite, for the best, greatest,
> > : handpicked, matchless, optimum, paramount, peerless, picked, pri=
me,
> > : prize, quintessential, select, supreme, surpassing, unmatchable,
> > : unmatched, unparalleled, unsurpassed, very best
> > : =20
> > : =20
> > :
> > :
> > : From The Free On-line Dictionary of Computing (27 SEP 03) :
> > :
> > : optimal
> > : =20
> > : 1. Describes a solution to a problem which
> > : minimises some cost function. Linear programming is one
> > : technique used to discover the optimal solution to certain
> > : problems.
> > : =20
> > : 2. Of code: best or most efficient in time,
> > : space or code size.
>
> > you will see that the last one, which is specifically aimed at CS and
> > IT -and it's actually relevant here- still does not mention just
> > "efficiency". Thus my take on the issue is that 'optimal' is not just
> > 'efficient' as alleged, but 'the most efficient'. All this, still at a
> > syntactical level, i.e. we're not discussing yet what "efficient"
> > could mean.
>
> > I'll repeat myself: maybe this strikes me more strongly because of my
> > implicit Latin heritage, but I still find 'more optimal' to sound like
> > 'more most efficient'.
>
> > >optimizing a program doesn't necessarily make it better, it simply mak=
es
> > >it more efficient: other things may be more important than efficiency,
>
> > This is semantics. "better" and "more efficient" are both
> > comparatives. That other things may be more important than efficiency
> > (and indeed I think they are) is irrelevant to the linguistic point
> > being discussed here.
>
> > >portability or readability for example. 'Optimum' has not (I would say)
>
> > We're not necessarily speaking of computer programs here, and although
> > it is not in the dictionaries I mentioned before I think that the
> > italian definition I found for 'ottimale' may well be translated in
> > English, which is what I'm trying to do now:
>
> > : adj: of something that, according to some determinate parameters or
> > : points of view, represents the *best* possible condition or the *best*
> > : possible result: e.g. optimal life conditions.
>
> > If you accept this, then you can still speak in the context of
> > programming of a
>
> > >changed like this, so I find it odd that the dictionaries you quoted s=
ay
> > >it is synonymous with 'optimal': I would entirely agree that 'more
> > >optimum' is obviously wrong.
>
> > In all earnestness I had never witnessed the use you're reporting of
> > 'optimal', namely that in which it is not a superlative. But
> > admittedly I do not read *that* much in English.
>
> > >Theory aside, a quick google shows that 'more optimal' is definitely
> > >acceptable usage; for instance (a random example from the results)
>
> > Huh?!? Google may show that "ur so c00l bro" is acceptable usage!!
>
> > > This is because the claim that A is more optimal or better adapted
> > > than B with respect to some function does not entail that A is
> > > optimal or even good with respect to that function.
>
> > > http://www.seop.leeds.ac.uk/archives/fall1999/entries/teleol ogy-bi=
ology/
>
> > >which shows that 'optimal' can have the sense of 'efficient' or
> > >'effective' rather than simply 'best'.
>
> > Well, that is from an academic institution thus should not fall in the
> > "ur so c00l bro", but I'm still skeptical: young researchers, however
> > good may they be in their research field, often tend to speak and
> > write very bad in their own mother tongue. For example in Italy some
> > young mathematicians are beginning to use the horrible anglophonic
> > "surgettiva" in place of the traditional "suriettiva", not that a word
> > borrowed from English is so bad in and of itself, but it is when
> > there's a perfectly fine alternative in one's own language.
>
> > > [English] not only borrows words from other languages; it has on
> > > occasion chased other languages down dark alley-ways, clubbed them
> > > unconscious and rifled their pockets for new vocabulary.
> > > -- James Nicoll
>
> > I knew that. In fact it's amongs my .sigs!
>
> > Michele
> > --
> > {$_=3Dpack'B8'x25,unpack'A8'x32,$a^=3Dsub{pop^pop}->(map substr
> > (($a||=3Djoin'',map--$|x$_,(unpack'w',unpack'u','G^ > > .'KYU;*EVH[.FHF2W+#"\Z*5TI/ER > > 256),7,249);s/[^\w,]/ /g;$ \=3D/^J/?$/:"\r";print,redo}#JAPH,
>
> Yes, vocabulary in English was made rich by the words from many other
> languages. These languages were of the places where British and
> English moved in the course of history. I saw a website which helps in
> knowing words and building vocabulary. It iswww.buildingvocabulary.org.- =
Hide quoted text -
>
> - Show quoted text -


origins of the English words are many and so mastering them may be
little difficult.
www.vocabularycafe.com
www.improvingvocabulary.org

these may help

Re: optimal vs. optimized [was: Re: string concatentation...]

GRE wrote a message of 205 lines, all of which was quotation except:

> origins of the English words are many and so mastering them may be
> little difficult.
> www.vocabularycafe.com
> www.improvingvocabulary.org
>
> these may help

Even though you are using the news client of the clueless,
groups.google.com, you can avoid being tarred with that brush if you
learn how to use it. One of the most important is to snip away all but
those sections of the original post except those necessary and germane
to you response. Quoting the whole original post only to add your own
tiny bit to the end is unnecessary and, in fact, rude.

Re: optimal vs. optimized [was: Re: string concatentation...]

> Even though you are using the news client of the clueless,
> groups.google.com, you can avoid being tarred with that brush if you
> learn how to use it. One of the most important is to snip away all but
> those sections of the original post except those necessary and germane
> to you response. Quoting the whole original post only to add your own
> tiny bit to the end is unnecessary and, in fact, rude.

Right. though that was not my point.

I wanted to tell about teaching vocabulary. I teach vocabulary to
students and take help of different sites. Some of them like
www.ultimatevocabulary.com
www.vocabularysoftware.net
www.buildingvocabulary.org
www.ultimatespelling.com
www.vocabularybuilder.info

Re: optimal vs. optimized [was: Re: string concatentation...]

teachingvocabulary wrote:
>> Even though you are using the news client of the clueless,
>> groups.google.com, you can avoid being tarred with that brush if you
>> learn how to use it. One of the most important is to snip away all
>> but those sections of the original post except those necessary and
>> germane to you response. Quoting the whole original post only to
>> add your own tiny bit to the end is unnecessary and, in fact, rude.
>
> Right. though that was not my point.
>
> I wanted to tell about teaching vocabulary. I teach vocabulary to
> students and take help of different sites. Some of them like
[...]

We disbelieve your claim. Your English isn't good enough to make you an
effective English teacher: you're just a low-down commercial spammer
breaking the charter of Usenet discussion groups. Anybody reading your
messages will avoid buying the stuff on principle: these things are
generally garbage anyhow.



--
Posted via a free Usenet account from http://www.teranews.com