[33167] in Perl-Users-Digest
Perl-Users Digest, Issue: 4446 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Jun 5 18:09:20 2015
Date: Fri, 5 Jun 2015 15:09:06 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Fri, 5 Jun 2015 Volume: 11 Number: 4446
Today's topics:
CGI Redirect with parameters (post method) <hslee911@yahoo.com>
Re: CGI Redirect with parameters (post method) <rweikusat@mobileactivedefense.com>
Re: CGI Redirect with parameters (post method) <*@eli.users.panix.com>
comparing by serializing (was: Comparing Lists) <rweikusat@mobileactivedefense.com>
Re: Comparing Lists <gamo@telecable.es>
Re: Comparing Lists <uri@stemsystems.com>
Re: Comparing Lists <rweikusat@mobileactivedefense.com>
Re: Comparing Lists <rweikusat@mobileactivedefense.com>
Re: Comparing Lists <rweikusat@mobileactivedefense.com>
Re: Comparing Lists <gamo@telecable.es>
Re: Comparing Lists <tzz@lifelogs.com>
Re: Comparing Lists <rweikusat@mobileactivedefense.com>
Re: Comparing Lists <tzz@lifelogs.com>
Re: Comparing Lists <rweikusat@mobileactivedefense.com>
Re: Comparing Lists <tzz@lifelogs.com>
Re: Comparing Lists <rweikusat@mobileactivedefense.com>
One encoding to rule them all <rweikusat@mobileactivedefense.com>
Perl module (or something) for emoji short codes <*@eli.users.panix.com>
Perlmind Programming Journal (PMPJ) -- details for 2015 mentificium@gmail.com
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 4 Jun 2015 13:17:20 -0700 (PDT)
From: James <hslee911@yahoo.com>
Subject: CGI Redirect with parameters (post method)
Message-Id: <3772c748-f172-4db4-af0b-1d906721ceb6@googlegroups.com>
Instead of the following way (get method for the URL),
print $cgi-> redirect(
-uri => "some-URL?param=$param",
...
);
how can I use post method? I don't want to reveal "param=$param".
I checked perldoc CGI, but not much help.
Thanks.
James
------------------------------
Date: Thu, 04 Jun 2015 21:32:01 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: CGI Redirect with parameters (post method)
Message-Id: <878ubznrjy.fsf@doppelsaurus.mobileactivedefense.com>
James <hslee911@yahoo.com> writes:
> Instead of the following way (get method for the URL),
>
> print $cgi-> redirect(
> -uri => "some-URL?param=$param",
> ...
> );
>
> how can I use post method? I don't want to reveal "param=$param".
That's not directly possible as 'methods' are used by the client and 'a
redirect' is part of a reply from the server. You can hide the actual
parameters in other ways, eg, you could encrypt the actual query string
using a secret key only known to the server and instruct the client to
pass the encrypted string back to the server using some generic
parameter name. Prior to processing, the server would decrypt what it
got from the client and thus regain the actual parameters.
------------------------------
Date: Thu, 4 Jun 2015 20:36:32 +0000 (UTC)
From: Eli the Bearded <*@eli.users.panix.com>
Subject: Re: CGI Redirect with parameters (post method)
Message-Id: <eli$1506041630@qz.little-neck.ny.us>
In comp.lang.perl.misc, James <hslee911@yahoo.com> wrote:
> Instead of the following way (get method for the URL),
>
> print $cgi-> redirect(
> -uri => "some-URL?param=$param",
> ...
> );
>
> how can I use post method? I don't want to reveal "param=$param".
>
> I checked perldoc CGI, but not much help.
This is an HTTP limitation by design since GET and POST are intended for
different purposes.
http://programmers.stackexchange.com/questions/99894/why-doesnt-http-have-post-redirect
As close reading of the 307 redirect spec shows that it can be used for
this, but there is a major usage caveat:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
10.3.8 307 Temporary Redirect
[...]
If the 307 status code is received in response to a request other
than GET or HEAD, the user agent MUST NOT automatically redirect the
request unless it can be confirmed by the user, since this might
change the conditions under which the request was issued.
I have not done (nor seen the results of someone else doing) tests to
check how well browsers adhere to that MUST NOT nor what the UI for the
confirmation would look like.
Elijah
------
not sure if that helps
------------------------------
Date: Fri, 05 Jun 2015 13:56:37 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: comparing by serializing (was: Comparing Lists)
Message-Id: <87vbf2gvp6.fsf_-_@doppelsaurus.mobileactivedefense.com>
"C.DeRykus" <derykus@gmail.com> writes:
> On Wednesday, May 27, 2015 at 9:37:19 PM UTC-7, Robbie Hatley wrote:
>> I'm starting to come across situations in which I need to compare
>> two lists item-for-item, and it occurs to me that Perl doesn't
>> have any easy way to do that. I'm ending up having to compare
>> one element at a time, like so:
>>
>> ...
>> It works, but seems overly complex to me.
>>
>> Is there a simpler, more-direct way to do list comparisons?
>>
>
> Assuming no binary data or memory-busting lists:
>
> say "same" if join("\0",@list1) eq join("\0",@list2);
It's somewhat difficult to experiment with this because there is simply
no 'general case' which could serve as yardstick. But at least for one
example (which I consider representative for 'comparing moderately long,
flat lists of simple things'), comparing by serializing is by no means
practically unusable. For me, it was always faster when the lists were
actually identical (I tried a few different sizes), became faster (for
this example) when about 580 comparisons had to be performed before a
difference was detected and even for the absolutely worst case, lists of
different sizes, which could and probably should be handled with a
separate test, where the other function ran at about 145 times the speed
of the serializing one, the absolute runtime of the latter was about
.000079s/ 7.9E-5s, surely nothing to worry about.
-------
use Benchmark;
my @a = 0 .. 999;
my @b = @a;
pop(@b);
sub direct
{
my ($a, $b) = @_;
return unless @a == @b;
$a->[$_] == $b->[$_] or return for 0 .. $#a;
return 1;
}
sub serial
{
return join(' ', @{$_[0]}) eq join(' ', @{$_[1]});
}
print(direct(\@a, \@b), ' ', serial(\@a, \@b), "\n");
timethese(-3,
{
direct => sub {
direct(\@a, \@b);
},
serial => sub {
serial(\@a, \@b);
}});
------------------------------
Date: Thu, 04 Jun 2015 20:09:20 +0200
From: gamo <gamo@telecable.es>
Subject: Re: Comparing Lists
Message-Id: <mkq48f$mis$1@speranza.aioe.org>
El 04/06/15 a las 17:50, Uri Guttman escribió:
> g> return 0 unless ( defined ($X[$_]) == defined ($Y[$_]) );
>
> that doesn't make any sense. what if one entry was defined as '' and the
> other undef? those aren't equal but your code makes them so.
If one are defined and other no, the lists are diferent, so it was
procceding accordingly.
--
http://www.telecable.es/personales/gamo/
The generation of random numbers is too important to be left to chance
------------------------------
Date: Thu, 04 Jun 2015 14:35:32 -0400
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Comparing Lists
Message-Id: <87mw0f2uff.fsf@stemsystems.com>
>>>>> "g" == gamo <gamo@telecable.es> writes:
g> El 04/06/15 a las 17:50, Uri Guttman escribió:
g> return 0 unless ( defined ($X[$_]) == defined ($Y[$_]) );
>>
>> that doesn't make any sense. what if one entry was defined as '' and the
>> other undef? those aren't equal but your code makes them so.
g> If one are defined and other no, the lists are diferent, so it was
g> procceding accordingly.
but the earlier test for eq will pass if one is undef and the other
''. that is not correct.
uri
------------------------------
Date: Thu, 04 Jun 2015 19:57:28 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Comparing Lists
Message-Id: <87d21bnvxj.fsf@doppelsaurus.mobileactivedefense.com>
Uri Guttman <uri@stemsystems.com> writes:
>>>>>> "g" == gamo <gamo@telecable.es> writes:
[...]
> g> return 0 unless ( ($X[$_] == $Y[$_]) || ($X[$_] eq $Y[$_]) );
>
> don't do both compare types. you will get warnings if the == sees
> non-numbers.
>
> g> return 0 unless ( defined ($X[$_]) == defined ($Y[$_]) );
>
> that doesn't make any sense. what if one entry was defined as '' and the
> other undef? those aren't equal but your code makes them so.
In this case, the first test will pass while the second will detect the
difference.
----
sub eql
{
return 0 unless $_[0] == $_[1] || $_[0] eq $_[1];
print STDERR ("\tcompared equal\n");
return 0 unless defined($_[0]) == defined($_[1]);
print STDERR ("\defined equal\n");
return 1;
}
print(eql('', undef), "\n");
print(eql('', ''), "\n");
print(eql(undef, undef), "\n");
----
But this code has a pretty glaring, other problem (I also just spotted):
The first comparison will cause both values to be converted to a
number and compare the results. And that's decidedly not sensible if
strings can actually occur.
----
sub eql
{
return 0 unless $_[0] == $_[1] || $_[0] eq $_[1];
print STDERR ("\tcompared equal\n");
return 0 unless defined($_[0]) == defined($_[1]);
print STDERR ("\defined equal\n");
return 1;
}
print(eql('a', 'b'), "\n");
print(eql(0, 'Eins'), "\n");
----
------------------------------
Date: Thu, 04 Jun 2015 22:38:39 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Comparing Lists
Message-Id: <874mmnnogw.fsf@doppelsaurus.mobileactivedefense.com>
Ted Zlatanov <tzz@lifelogs.com> writes:
> On Thu, 04 Jun 2015 15:18:25 +0100 Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
[...]
> The problem, as given: "I need to compare two lists item-for-item"
>
> As I explained already, join/pack is the wrong approach because 1) undef
> and "" are not the same thing; and 2) it's inefficient. This is basic
> stuff, usually taught in first-year algorithms courses.
I think I've meanwhile also decrypted this semi-sensical statement:
While there shouldn't be much of a difference for comparing two ordered
sets as the algorithm is O(n) either way, this is not true for the naive
implementation for (non-destructively) testing equivalence of two
unordered sets (what List::Compare really is about as far as I know
this). The naive implementation would loop through all members of the
first set and loop through all members of the second set for each member
of the first in order to determine if it exists. And this is O(n*n). A
more sensible approach for doing that is to utilize a hash because the
lookup then becomes (amortized) O(1) and the whole algorithm O(n).
Example:
--------
use Benchmark;
my @first = 0 .. 99;
my @second = reverse(@first);
sub loopy
{
my ($f, $s) = @_;
my $found;
return unless @$f == @$s;
for my $ff (@$f) {
$found = 0;
$ff == $_ and $found = 1, last for @$s;
return 0 unless $found;
}
return 1;
}
sub hashy
{
my %f;
$f{$_} = 1 for @{$_[0]};
for (@{$_[1]}) {
return 0 unless keys(%f) && $f{$_};
delete($f{$_});
}
return keys(%f) == 0;
}
timethese(-3,
{
loopy => sub { loopy(\@first, \@second) },
hashy => sub { hashy(\@first, \@second) }});
------------------------------
Date: Thu, 04 Jun 2015 22:45:51 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Comparing Lists
Message-Id: <87zj4fm9kg.fsf@doppelsaurus.mobileactivedefense.com>
Rainer Weikusat <rweikusat@mobileactivedefense.com> writes:
[...]
> my @first = 0 .. 99;
> my @second = reverse(@first);
[...]
> sub hashy
> {
> my %f;
>
> $f{$_} = 1 for @{$_[0]};
>
> for (@{$_[1]}) {
> return 0 unless keys(%f) && $f{$_};
> delete($f{$_});
> }
>
> return keys(%f) == 0;
> }
Additional disclaimer: This simple algorithm doesn't work for 'unordered
bags', ie, sets where equivalent items can appear more than one time
(and the keys(%f) is very likely not needed as the next element from the
2nd list won't be found in case the hash became empty after the last
deletion).
------------------------------
Date: Fri, 05 Jun 2015 00:22:09 +0200
From: gamo <gamo@telecable.es>
Subject: Re: Comparing Lists
Message-Id: <mkqj2j$q7d$1@speranza.aioe.org>
El 04/06/15 a las 20:57, Rainer Weikusat escribió:
> But this code has a pretty glaring, other problem (I also just spotted):
> The first comparison will cause both values to be converted to a
> number and compare the results. And that's decidedly not sensible if
> strings can actually occur.
>
> ----
> sub eql
> {
> return 0 unless $_[0] == $_[1] || $_[0] eq $_[1];
>
> print STDERR ("\tcompared equal\n");
>
> return 0 unless defined($_[0]) == defined($_[1]);
>
> print STDERR ("\defined equal\n");
>
> return 1;
> }
So we need to use the famous isitanumber() function,
to check $_[0]+0 ne $_[0];
--
http://www.telecable.es/personales/gamo/
The generation of random numbers is too important to be left to chance
------------------------------
Date: Fri, 05 Jun 2015 06:56:58 -0400
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: Comparing Lists
Message-Id: <87fv66mnid.fsf@lifelogs.com>
On Thu, 04 Jun 2015 22:38:39 +0100 Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
RW> Ted Zlatanov <tzz@lifelogs.com> writes:
>> On Thu, 04 Jun 2015 15:18:25 +0100 Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
RW> [...]
>> The problem, as given: "I need to compare two lists item-for-item"
>>
>> As I explained already, join/pack is the wrong approach because 1) undef
>> and "" are not the same thing; and 2) it's inefficient. This is basic
>> stuff, usually taught in first-year algorithms courses.
RW> I think I've meanwhile also decrypted this semi-sensical statement:
RW> While there shouldn't be much of a difference for comparing two ordered
RW> sets as the algorithm is O(n) either way, this is not true for the naive
RW> implementation for (non-destructively) testing equivalence of two
RW> unordered sets (what List::Compare really is about as far as I know
RW> this). The naive implementation would loop through all members of the
RW> first set and loop through all members of the second set for each member
RW> of the first in order to determine if it exists. And this is O(n*n). A
RW> more sensible approach for doing that is to utilize a hash because the
RW> lookup then becomes (amortized) O(1) and the whole algorithm O(n).
Comparing two sets, which you seem to be discussing, is completely
irrelevant here.
Ted
------------------------------
Date: Fri, 05 Jun 2015 13:27:17 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Comparing Lists
Message-Id: <87y4jypcgq.fsf@doppelsaurus.mobileactivedefense.com>
Ted Zlatanov <tzz@lifelogs.com> writes:
> On Thu, 04 Jun 2015 22:38:39 +0100 Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
>
> RW> Ted Zlatanov <tzz@lifelogs.com> writes:
>>> On Thu, 04 Jun 2015 15:18:25 +0100 Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
>
> RW> [...]
>
>>> The problem, as given: "I need to compare two lists item-for-item"
>>>
>>> As I explained already, join/pack is the wrong approach because 1) undef
>>> and "" are not the same thing; and 2) it's inefficient. This is basic
>>> stuff, usually taught in first-year algorithms courses.
>
> RW> I think I've meanwhile also decrypted this semi-sensical statement:
> RW> While there shouldn't be much of a difference for comparing two ordered
> RW> sets as the algorithm is O(n) either way, this is not true for the naive
> RW> implementation for (non-destructively) testing equivalence of two
> RW> unordered sets (what List::Compare really is about as far as I know
> RW> this). The naive implementation would loop through all members of the
> RW> first set and loop through all members of the second set for each member
> RW> of the first in order to determine if it exists. And this is O(n*n). A
> RW> more sensible approach for doing that is to utilize a hash because the
> RW> lookup then becomes (amortized) O(1) and the whole algorithm O(n).
>
> Comparing two sets, which you seem to be discussing, is completely
> irrelevant here.
The algorithms themselves are of some interest and the only way the
'mad' List::Compare equivalence test can ever be considered 'efficient'
is when comparing it with a naive implemention of determining whether or
not two unordered sets represented as arrays which may contain the same
element multiple times are equivalent (in the sense that they contain
the same elements). As to comparing two ordered sets, there is simply no
more 'efficient' algorithm than comparing them element by element.
------------------------------
Date: Fri, 05 Jun 2015 15:25:05 -0400
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: Comparing Lists
Message-Id: <878ubylzzi.fsf@lifelogs.com>
On Fri, 05 Jun 2015 13:27:17 +0100 Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
RW> Ted Zlatanov <tzz@lifelogs.com> writes:
>> Comparing two sets, which you seem to be discussing, is completely
>> irrelevant here.
RW> The [set comparison] algorithms themselves are of some interest
...to set problems, but we were talking about lists...
RW> and the only way the 'mad' List::Compare equivalence test can ever
RW> be considered 'efficient'
...is if you use it correctly with the "-a -u" options...
RW> is when comparing it with a naive implemention of determining
RW> whether or not two unordered sets represented as arrays which may
RW> contain the same element multiple times are equivalent (in the sense
RW> that they contain the same elements). As to comparing two ordered
RW> sets, there is simply no more 'efficient' algorithm than comparing
RW> them element by element
...unless you check their sizes first or have heard about bloom filters,
for instance...
Ted
------------------------------
Date: Fri, 05 Jun 2015 21:06:26 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Comparing Lists
Message-Id: <87zj4dudh9.fsf@doppelsaurus.mobileactivedefense.com>
Ted Zlatanov <tzz@lifelogs.com> writes:
> On Fri, 05 Jun 2015 13:27:17 +0100 Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
> RW> Ted Zlatanov <tzz@lifelogs.com> writes:
>
>>> Comparing two sets, which you seem to be discussing, is completely
>>> irrelevant here.
>
> RW> The [set comparison] algorithms themselves are of some interest
>
> ...to set problems, but we were talking about lists...
I was writing about 'set comparisons'.
> RW> and the only way the 'mad' List::Compare equivalence test can ever
> RW> be considered 'efficient'
>
> ...is if you use it correctly with the "-a -u" options...
Again, I was writing about the List::Compare equiv_engine algorithm,
also a set comparison. That's not a particularly good way of comparing
two ordered sets and I was possibly looking at the wrong algorithm. In
case you actually know that I was and know which is the right one, how
about sharing your knowledged instead of just asserting that you sure
have it?
> RW> is when comparing it with a naive implemention of determining
> RW> whether or not two unordered sets represented as arrays which may
> RW> contain the same element multiple times are equivalent (in the sense
> RW> that they contain the same elements). As to comparing two ordered
> RW> sets, there is simply no more 'efficient' algorithm than comparing
> RW> them element by element
>
> ...unless you check their sizes first or have heard about bloom filters,
> for instance...
At this point of the discussion, only a particularly obtuse observer
could have failed to notice the size comparisons prior to doing the
element-by-element comparison which kept being posted. Consequently, I
don't quite understand why you bring them up here as 'new'. 'Bloom
filters' are something supposed to be useful for optimizing
lookup operations in 'large', unordered sets. For the given case, as far
as my understanding goes (feel free to prove me wrong with actual code),
a bloom filter can be simulated with a hash table, leading to a
comparison function which could roughly look like this:
--------
sub compare_bizarre
{
my ($a, $b) = @_;
my %filter;
return unless @$a == @$b;
$filter{$_} = 1 for @$a;
for (0 .. $#b) {
return 0 unless $filter{$b[$_]};
return 0 unless $a[$_] == $b[$_];
}
return 1;
}
---------
I don't expect this to have any speed advantages over just omitting the
redundant lookups.
------------------------------
Date: Fri, 05 Jun 2015 16:32:50 -0400
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: Comparing Lists
Message-Id: <87r3pplwul.fsf@lifelogs.com>
On Fri, 05 Jun 2015 21:06:26 +0100 Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
RW> and the only way the 'mad' List::Compare equivalence test can ever
RW> be considered 'efficient'
>>
>> ...is if you use it correctly with the "-a -u" options...
RW> Again, I was writing about the List::Compare equiv_engine algorithm,
RW> also a set comparison. That's not a particularly good way of comparing
RW> two ordered sets and I was possibly looking at the wrong algorithm. In
RW> case you actually know that I was and know which is the right one, how
RW> about sharing your knowledged instead of just asserting that you sure
RW> have it?
I did!!! The "-a -u" option!!!
http://search.cpan.org/~jkeenan/List-Compare-0.52/lib/List/Compare.pm#Accelerated_Case:_When_User_Only_Wants_a_Single_Comparison
As with List::Compare's Regular case, should you not need to have a
sorted list returned by an accelerated List::Compare method, you may
achieve a speed boost by constructing the accelerated List::Compare
object with the unsorted option:
$lca = List::Compare->new('-u', '-a', \@Llist, \@Rlist);
RW> 'Bloom filters' are something supposed to be useful for optimizing
RW> lookup operations in 'large', unordered sets.
Yes. And you said "comparing element by element" was the most efficient
way. I gave a counter-example. To be clear, there are many other set
existence algorithms that will not use hash tables. Range trees are
another one, but they require numeric elements and lots of memory.
RW> For the given case, as far as my understanding goes (feel free to
RW> prove me wrong with actual code), a bloom filter can be simulated
RW> with a hash table
Bloom filters can't be simulated with a hash table.
If you have trouble finding implementations, look at
http://search.cpan.org/~xaerxess/Bloom-Filter-1.2/lib/Bloom/Filter.pm
RW> I don't expect this to have any speed advantages over just omitting the
RW> redundant lookups.
I look forward to your benchmarks.
Ted
------------------------------
Date: Fri, 05 Jun 2015 22:07:03 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Comparing Lists
Message-Id: <87vbf1uao8.fsf@doppelsaurus.mobileactivedefense.com>
Ted Zlatanov <tzz@lifelogs.com> writes:
> On Fri, 05 Jun 2015 21:06:26 +0100 Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
>
>
> RW> and the only way the 'mad' List::Compare equivalence test can ever
> RW> be considered 'efficient'
>>>
>>> ...is if you use it correctly with the "-a -u" options...
>
> RW> Again, I was writing about the List::Compare equiv_engine algorithm,
> RW> also a set comparison. That's not a particularly good way of comparing
> RW> two ordered sets and I was possibly looking at the wrong algorithm. In
> RW> case you actually know that I was and know which is the right one, how
> RW> about sharing your knowledged instead of just asserting that you sure
> RW> have it?
>
> I did!!! The "-a -u" option!!!
No you didn't. I specifically asked you about the code implementing the
comparison in case it isn't the equiv_engine ...
>
> http://search.cpan.org/~jkeenan/List-Compare-0.52/lib/List/Compare.pm#Accelerated_Case:_When_User_Only_Wants_a_Single_Comparison
>
> As with List::Compare's Regular case, should you not need to have a
> sorted list returned by an accelerated List::Compare method, you may
> achieve a speed boost by constructing the accelerated List::Compare
> object with the unsorted option:
>
> $lca = List::Compare->new('-u', '-a', \@Llist, \@Rlist);
... and answer came there none.
[...]
> RW> For the given case, as far as my understanding goes (feel free to
> RW> prove me wrong with actual code), a bloom filter can be simulated
> RW> with a hash table
>
> Bloom filters can't be simulated with a hash table.
Considering
http://www.perl.com/pub/2004/04/08/bloom_filters.html
and a lot of other texts which are easily accessible on the internet,
they absolutely can.
NB: I'm going to assume that this discussion is a dead end and will thus
cease to partake in it.
------------------------------
Date: Fri, 05 Jun 2015 16:43:15 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: One encoding to rule them all
Message-Id: <87k2viupnw.fsf@doppelsaurus.mobileactivedefense.com>
This is mostly off topic and could be considered inflammatory.
Interesting statement from the Perl 5.22 documentation:
qr/\b{gcb}/
gcb stands for Grapheme Cluster Boundary. It is a Unicode
property that finds the boundary between sequences of characters
that look like a single character to a native speaker of a
language.
In line with something I posted earlier in a completely different group,
I hereby humbly propose to create the following two 'extended grapheme
clusters', "overline plus combining vertical bar" and "capital lambda
combining hyphen". There's a consortium of natives somewhere who
mistakenly assume that these were the letters A and T.
------------------------------
Date: Thu, 4 Jun 2015 20:08:16 +0000 (UTC)
From: Eli the Bearded <*@eli.users.panix.com>
Subject: Perl module (or something) for emoji short codes
Message-Id: <eli$1506041559@qz.little-neck.ny.us>
First a definition. An emoji "short code" is a name in form of
colon-latin-text-colon that is sometimes used to type in an emoji
symbol.
For U+1F35F "FRENCH FRIES", the "short code" is ":fries:" here:
http://www.iemoji.com/view/emoji/434/objects/french-fries
and in other places I look.
I'd like to be able to map short codes to UTF-8 and UTF-8 to short
codes.
The emoji modules I've found don't offer anything like that. There are
several modules that deal with converting between the various
incompatible Shift-JIS variants and Unicode variants, and some general
Unicode modules that can help you turn a name like "FRENCH FRIES" into a
codepoint like 1F35F, and vice-versa, but I'm not seeing these short
codes anywhere.
Elijah
------
Unicode codepoint to UTF-8 and back is very easy
------------------------------
Date: Thu, 4 Jun 2015 23:18:01 -0700 (PDT)
From: mentificium@gmail.com
Subject: Perlmind Programming Journal (PMPJ) -- details for 2015 June 04
Message-Id: <b1267c32-df3f-4458-a812-94a2f14a4b1f@googlegroups.com>
Next we need to stub in the EnParser (English Parser) module,
not so much for its own sake, but rather as a bridge to calling
the InStantiate module. We have EnParser merely announce that
it has been called by the NewConcept module, so that we may see
that the AI still runs with no apparent problems. We declare the
http://code.google.com/p/mindforth/wiki/var#bias $bias and
http://mind.sourceforge.net/variable.html#pov $pov
variables associated with EnParser so as to make sure that
they are not reserved words in Perl. We clean up some lines
of code previously commented out but left intact for at least
one archival release iteration. We caution here that the
http://code.google.com/p/mindforth/wiki/EnParser
EnParser module is extremely primitive and relies upon
very strict input formats such as subject-verb-object (SVO),
so that EnParser can expect a subject-noun, then a verb,
and then an object-noun or a predicate nominative.
We are more interested in the demonstration of thinking
than in the demonstration of parsing. Perl AI coders
may be able to adapt pre-existing
http://en.wikipedia.org/wiki/CPAN CPAN or other
parsing code for use with the AI
http://ai.neocities.org/perlmind.txt Perlmind.
--
http://ai.neocities.org/AiSteps.html
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 4446
***************************************
