view release on metacpan or search on metacpan
lib/Algorithm/Shape/RandomTree.pm view on Meta::CPAN
A detailed synopsis with examples will be released soon.
=head1 EXPORT
A list of functions that can be exported. You can delete this section
if you don't export anything, such as for a purely object-oriented module.
=head1 SUBROUTINES/METHODS
=head2 calc_new_deltas
view all matches for this distribution
view release on metacpan or search on metacpan
lib/Algorithm/SixDegrees.pm view on Meta::CPAN
A linked data type must return identifiers that relate across the
link; that is, for an actor/movie relationship, an actor subroutine
should return movies, and a movie subroutine should return actors.
Additional arguments can be provided; these will be stored in the
object and passed through as the second and further arguments to
the subroutine. This may be useful, for example, if you're using
some form of results caching and need to pass a C<tie>d handle
around.
If you return explicit undef, please set C<$Algorithm::SixDegrees::ERROR>
view all matches for this distribution
view release on metacpan or search on metacpan
lib/Algorithm/SkipList.pm view on Meta::CPAN
($cmp == 0) ? $node->value : undef;
}
sub _first_node { # actually this is the second node
my $self = shift;
my $list = $self->list;
my $node = $list->header()->[0];
}
lib/Algorithm/SkipList.pm view on Meta::CPAN
=head1 DESCRIPTION
This is an implementation of I<skip lists> in Perl.
Skip lists are similar to linked lists, except that they have random
links at various I<levels> that allow searches to skip over sections
of the list, like so:
4 +---------------------------> +----------------------> +
| | |
3 +------------> +------------> +-------> +-------> +--> +
lib/Algorithm/SkipList.pm view on Meta::CPAN
Skip lists generally perform as well as balanced trees for searching
but do not have the overhead with respect to inserting new items. See
the included file C<Benchmark.txt> for a comparison of performance
with other Perl modules.
For more information on skip lists, see the L</"SEE ALSO"> section below.
Only alphanumeric keys are supported "out of the box". To use numeric
or other types of keys, see L</"Customizing the Node Class"> below.
=head2 Methods
lib/Algorithm/SkipList.pm view on Meta::CPAN
customized L<comparison|/"key_cmp"> routines, you will need to specify a
different class:
$list = new Algorithm::SkipList( node_class => 'MyNodeClass' );
See the L</"Customizing the Node Class"> section below.
Specialized internal parameters may be configured:
$list = new Algorithm::SkipList( max_level => 32 );
lib/Algorithm/SkipList.pm view on Meta::CPAN
You can enable duplicate keys by using the following:
$list = new Algorithm::SkipList( duplicates => 1 );
This is an experimental feature. See the L</KNOWN ISSUES> section
below.
=item insert
$list->insert( $key, $value );
lib/Algorithm/SkipList.pm view on Meta::CPAN
$list->k( $k );
Sets the I<k> value.
Higher values will on the average have less pointers per node, but
take longer for searches. See the section on the L<P|/p> value.
=item p
$plevel = $list->p;
lib/Algorithm/SkipList.pm view on Meta::CPAN
The probability that a particular node will have a forward pointer at
level I<i> is: I<p**(i+k-1)>.
For more information, consult the references below in the
L</"SEE ALSO"> section.
=item max_level
$max = $list->max_level;
lib/Algorithm/SkipList.pm view on Meta::CPAN
=item _first_node
$node = $list->_first_node;
Returns the first node with a key (the second node) in a list. This
is used by the L</first_key>, L</least>, L</append> and L</merge>
methods.
=item _greatest_node
view all matches for this distribution
view release on metacpan or search on metacpan
lib/Algorithm/SpiralSearch.pm view on Meta::CPAN
croak 'A valid input/output funtion reference must be passed in'
unless $f =~ /CODE/;
croak 'Two or more iterations are required : ' if $iters < 2;
croak 'Upper boundary on first parameter must be non-zero : ' if $ubx == 0.0;
croak 'Upper boundary on second parameter must be non-zero : '
if $uby == 0.0;
croak 'Final parameter must be set to MAX or MIN : '
unless $max_or_min =~ /MAX|MIN/i;
view all matches for this distribution
view release on metacpan or search on metacpan
The default namespace is C<DPPP_>.
=back
The good thing is that most of the above can be checked by running
F<ppport.h> on your source code. See the next section for
details.
=head1 EXAMPLES
To verify whether F<ppport.h> is needed for your module, whether you
* 1. #define MY_CXT_KEY to a unique string, e.g. "DynaLoader_guts"
* 2. Declare a typedef named my_cxt_t that is a structure that contains
* all the data that needs to be interpreter-local.
* 3. Use the START_MY_CXT macro after the declaration of my_cxt_t.
* 4. Use the MY_CXT_INIT macro such that it is called exactly once
* (typically put in the BOOT: section).
* 5. Use the members of the my_cxt_t structure everywhere as
* MY_CXT.member.
* 6. Use the dMY_CXT macro (a declaration) in all the functions that
* access MY_CXT.
*/
view all matches for this distribution
view release on metacpan or search on metacpan
lib/Algorithm/Step.pm view on Meta::CPAN
=over 4
=item B<algorithm>
Begins an algorithm. It takes two arguments. The first one is the name of this
algorithm, the second one is the short description.
=item B<end_algorithm>
Ends an algorithm.
view all matches for this distribution
view release on metacpan or search on metacpan
The default namespace is C<DPPP_>.
=back
The good thing is that most of the above can be checked by running
F<ppport.h> on your source code. See the next section for
details.
=head1 EXAMPLES
To verify whether F<ppport.h> is needed for your module, whether you
* 1. #define MY_CXT_KEY to a unique string, e.g. "DynaLoader_guts"
* 2. Declare a typedef named my_cxt_t that is a structure that contains
* all the data that needs to be interpreter-local.
* 3. Use the START_MY_CXT macro after the declaration of my_cxt_t.
* 4. Use the MY_CXT_INIT macro such that it is called exactly once
* (typically put in the BOOT: section).
* 5. Use the members of the my_cxt_t structure everywhere as
* MY_CXT.member.
* 6. Use the dMY_CXT macro (a declaration) in all the functions that
* access MY_CXT.
*/
view all matches for this distribution
view release on metacpan or search on metacpan
lib/Algorithm/TicketClusterer.pm view on Meta::CPAN
# Of the various constructor parameters shown above, the following two
# are critical to how information is extracted from an Excel
# spreadsheet: `clustering_fieldname' and `unique_id_fieldname'. The
# first is the heading of the column that contains the textual content
# of the tickets. The second is the heading of the column that
# contains a unique integer identifier for each ticket.
# The nine database related constructor parameters (these end in the
# suffix `_db') are there in order to avoid repeated parsing of the
# spreadsheet and preprocessing of the tickets every time you need to
lib/Algorithm/TicketClusterer.pm view on Meta::CPAN
and corrects would, in general, depend on the application domain of the
tickets. (It is not uncommon for engineering services to use jargon words
and acronyms that look like spelling errors to those not familiar with the
services.) The module expects to see a file that is supplied through the
constructor parameter C<misspelled_words_file> that contains misspelled
words in the first column and their corrected versions in the second
column. An example of such a file is included in the C<examples>
directory. You would need to create your own version of such a file for
your application domain. Since conjuring up the misspellings that your
ticket submitters are likely to throw at you is futile, you might consider
using the following approach which I prefer to actually reading the tickets
lib/Algorithm/TicketClusterer.pm view on Meta::CPAN
WordNet.
=item I<min_idf_threshold:>
First recall that IDF stands for Inverse Document Frequency. It is calculated during
the second of the three-stage processing of the tickets as described in the section
B<THE THREE STAGES OF PROCESSING TICKETS>. The IDF value of a word gives us a
measure of the discriminatory power of the word. Let's say you have a word that
occurs in only one out of 1000 tickets. Such a word is obviously highly
discriminatory and its IDF would be the logarithm (to base 10) of the ratio of 1000
to 1, which is 3. On the other hand, for a word that occurs in every one of 1000
lib/Algorithm/TicketClusterer.pm view on Meta::CPAN
As to what extent you can improve ticket retrieval precision with the addition of
synonyms depends on the degree to which you can make corrections on the fly for the
spelling errors that occur frequently in tickets. That fact makes the file you
supply through this constructor parameter very important. For the current version of
the module, this file must contain exactly two columns, with the first entry in each
row the misspelled word and the second entry the correctly spelled word. See this
file in the C<examples> directory for how to format it.
=item I<processed_tickets_db:>
As mentioned earlier in B<DESCRIPTION>, the tickets must be subject to various
lib/Algorithm/TicketClusterer.pm view on Meta::CPAN
faster to load the database back into the runtime environment than to process a large
spreadsheet.
=item I<stemmed_tickets_db:>
As mentioned in the section B<THE THREE STAGES OF PROCESSING>, one of the first
things you do in the second stage of processing is to stem the words in the tickets.
Stemming is important because it reduces the size of the vocabulary. To illustrate,
stemming would reduce both the words `programming' and `programmed' to the common
root 'program'. This module uses a very simple stemmer whose rules can be found in
the utility subroutine C<_simple_stemmer()>. It would be trivial to expand on these
rules, or, for that matter, to use the Perl module C<Lingua::Stem::En> for a full
lib/Algorithm/TicketClusterer.pm view on Meta::CPAN
given word regardless of how many times the word appears in all of the tickets.
=item I<which_worksheet:>
This specifies the Excel worksheet that contains the tickets. Its value should be 1
for the first sheet, 2 for the second, and so on.
=back
=begin html
lib/Algorithm/TicketClusterer.pm view on Meta::CPAN
=item B<display_inverted_index_for_given_query( $ticket_id )>
The above three methods are useful for troubleshooting the issues that are related to
the generation of the inverted index. The first method shows the entire inverted
index, the second the inverted index for a single specified word, and the third for
all the words in a query ticket.
=item B<display_tickets_vocab()>
$clusterer->display_tickets_vocab()
lib/Algorithm/TicketClusterer.pm view on Meta::CPAN
=item B<get_ticket_vocabulary_and_construct_inverted_index()>
$clusterer->get_ticket_vocabulary_and_construct_inverted_index()
As mentioned in B<THE THREE STAGES OF PROCESSING>, the second stage of processing ---
doc modeling of the tickets --- starts with the stemming of the words in the tickets,
constructing a vocabulary of all the stemmed words in all the tickets, and
constructing an inverted index for the vocabulary words. All of these things are
accomplished by this method.
lib/Algorithm/TicketClusterer.pm view on Meta::CPAN
=item B<store_stemmed_tickets_and_inverted_index_on_disk()>
$clusterer->store_stemmed_tickets_and_inverted_index_on_disk()
This method stores in a database file the stemmed tickets and the inverted index that
are produced at the end of the second stage of processing.
=item B<show_stemmed_ticket_clustering_data_for_given_id()>
$clusterer->show_stemmed_ticket_clustering_data_for_given_id( $ticket_num );
lib/Algorithm/TicketClusterer.pm view on Meta::CPAN
WordNet::QueryData
Storable
SDBM_File
the first for extracting information from the old-style Excel sheets that are
commonly used for storing tickets, the second for extracting the same information
from the new-style Excel sheets, the third for interfacing with WordNet for
extracting the synonyms and antonyms, the fourth for creating the various disk-based
database files needed by the module, and the last for disk-based hashes used to lend
persistence to the extraction of the alphabet used by the tickets and the inverse
document frequencies of the words.
view all matches for this distribution
view release on metacpan or search on metacpan
lib/Algorithm/Time/ToNumber.pm view on Meta::CPAN
=head2 suricata_to_circle_both
Convert .timestamp from Suricata EVE output to a sin/cos pair encoding both
the day of week and time of day as a single position within the week. The
week is treated as a 604800-second circle (7 days * 86400 seconds).
my $hour = 0;
while ($hour < 24) {
my $time = '2026-07-03T' . $hour . ':00:31.121465-0500';
view all matches for this distribution
view release on metacpan or search on metacpan
lib/Algorithm/TimelinePacking.pm view on Meta::CPAN
use POSIX qw(floor);
use List::Util qw(max shuffle);
our $VERSION = '0.01';
# minimum space (in units, i.e. most frequently pixels) between 2 consecutive
# items on a line
has space => (
is => 'rw',
isa => Int->where('$_ >= 0'),
default => 0,
lib/Algorithm/TimelinePacking.pm view on Meta::CPAN
=head2 space
my $packer = Algorithm::TimelinePacking->new(space => 10);
Minimum space (in the same units as your timestamps) required between
consecutive intervals on the same line. Default: 0.
=head2 width
my $packer = Algorithm::TimelinePacking->new(width => 800);
lib/Algorithm/TimelinePacking.pm view on Meta::CPAN
=over 4
=item 1.
Sort intervals by start time (secondary sort by end time)
=item 2.
Normalize all timestamps to start at 0
view all matches for this distribution
view release on metacpan or search on metacpan
lib/Algorithm/ToNumberMunger.pm view on Meta::CPAN
my $code = ...->build( \%spec, $tag_name ); # $tag_name only sharpens errors
Compile a single munger spec into a coderef. C<%spec> must contain a C<munger>
key naming one of the L</BUILT-IN MUNGERS>; the remaining keys are that munger's
parameters. Croaks on an unknown munger name or an invalid parameter set. The
optional second argument is only used to make error messages point at a tag.
=cut
# name => builder. Each builder validates its slice of the spec up front and
# returns the per-value closure. Keeping them in a table (rather than a big
lib/Algorithm/ToNumberMunger.pm view on Meta::CPAN
{ munger => 'syslog_facility_enum' }
Named-map enum (lookup rules as L</dns_rcode_enum>; numeric inputs pass
through) mapping syslog facility names to their RFC 5424 codes: C<kern> 0,
C<user> 1, C<mail> 2, C<daemon> 3, C<auth> 4 (alias C<security>), C<syslog> 5,
C<lpr> 6, C<news> 7, C<uucp> 8, C<cron> 9, C<authpriv> 10, C<ftp> 11, C<ntp>
12, C<audit> 13, C<alert> 14, C<clock> 15, and C<local0>-C<local7> 16-23.
=head2 ip_proto_enum
lib/Algorithm/ToNumberMunger.pm view on Meta::CPAN
# same set is numbered alphabetically for sasl_mech_iana_enum, so the two
# mungers can never end up covering different mechanisms. Includes the IANA
# registry plus the ubiquitous non-registered login/xoauth2/apop.
my @SASL_MECHS_BY_STRENGTH = qw(
anonymous plain login
apop cram-md5 digest-md5 ntlm skey otp securid rpa kerberos_v4
srp scram-sha-1 scram-sha-1-plus scram-sha-256 scram-sha-256-plus
xoauth2 oauthbearer openid20 saml20
gssapi gs2-krb5 gss-spnego external
);
lib/Algorithm/ToNumberMunger.pm view on Meta::CPAN
cert => 37,
dname => 39,
opt => 41,
ds => 43,
sshfp => 44,
ipseckey => 45,
rrsig => 46,
nsec => 47,
dnskey => 48,
dhcid => 49,
nsec3 => 50,
nsec3param => 51,
tlsa => 52,
smimea => 53,
hip => 55,
cds => 59,
cdnskey => 60,
lib/Algorithm/ToNumberMunger.pm view on Meta::CPAN
kern => 0,
user => 1,
mail => 2,
daemon => 3,
auth => 4,
security => 4,
syslog => 5,
lpr => 6,
news => 7,
uucp => 8,
cron => 9,
lib/Algorithm/ToNumberMunger.pm view on Meta::CPAN
'50144' => 5, # AD password expired
'50074' => 6, # strong auth (MFA) required
'50076' => 6, # MFA required by conditional access
'50079' => 6, # user must enroll for MFA
'500121' => 7, # MFA denied / authentication failed
'50158' => 7, # external security challenge not satisfied
'53003' => 8, # blocked by conditional access
'53000' => 8, # device not compliant (CA)
'53001' => 8, # device not domain joined (CA)
'530032' => 8, # blocked by security policy (CA)
'50173' => 9, # fresh auth token required (session expired)
},
},
risk_level => {
numeric => 0,
lib/Algorithm/ToNumberMunger.pm view on Meta::CPAN
# 'io_ratio' is a tag; bytes_out and bytes_in are input fields
"io_ratio": { "munger": "ratio", "from": ["bytes_out", "bytes_in"] }
{ munger => 'ratio', from => [qw(bytes_out bytes_in)], zero => -1 }
First source divided by the second: with C<< from => [a, b] >> the column gets
C<a / b>. Asymmetry between two counters is a classic feature the counters
alone cannot express -- bytes out over bytes in flags exfiltration, requests
over responses flags scanning -- and the division has to happen at munge time
because a forest split only ever sees one column. A zero denominator yields
C<zero> (default C<0>) instead of dying, since "nothing came back" is a
lib/Algorithm/ToNumberMunger.pm view on Meta::CPAN
{ munger => 'combine', op => 'sum', from => [qw(bytes_in bytes_out)] }
{ munger => 'combine', op => 'max', from => [qw(req_time resp_time)] }
Fold two or more numeric source fields into one column with C<op>: C<sum>,
C<diff> (first minus second; exactly two sources), C<product>, C<min>, C<max>,
or C<mean>. The general-purpose sibling of L</ratio> for when the interesting
feature is a total, a gap, or an extreme across fields rather than any one
field. Every input must be numeric.
Like C<ratio>, this is a B<multi-input> munger: only usable through
lib/Algorithm/ToNumberMunger.pm view on Meta::CPAN
Parse a formatted timestamp with L<Time::Piece> (C<strptime>, so C<format> is a
standard strptime pattern) and extract one numeric C<part>:
=over 4
=item * C<epoch> (default) - seconds since the epoch.
=item * C<year>, C<mon> (1-12), C<mday> (1-31), C<hour>, C<min>, C<sec>.
=item * C<wday> - day of week, C<0>=Sunday .. C<6>=Saturday.
=item * C<yday> - day of year, C<0>-based.
=item * C<frac_day> - time of day as a fraction in C<[0, 1)>, i.e.
C<(hour*3600 + min*60 + sec) / 86400>. Handy as a cyclic-ish time-of-day feature.
=item * C<frac_week> - position within the week as a fraction in C<[0, 1)>, the
week starting Sunday to match C<wday>: C<(wday*86400 + hour*3600 + min*60 + sec)
/ 604800>. Like C<frac_day> but cycling over a week, so a weekly rhythm (weekend
vs. weekday, or a Monday-morning batch) shows up as a feature.
=item * C<sin_day> / C<cos_day>, C<sin_week> / C<cos_week> - the C<frac_*> value
mapped onto a circle, C<sin(2*pi*frac)> and C<cos(2*pi*frac)>. Prefer these over
lib/Algorithm/ToNumberMunger.pm view on Meta::CPAN
# Fraction (in [0,1)) of the way through the day / week, shared by the frac_*
# parts and their sin/cos cyclic encodings.
sub _frac_day {
my $t = shift;
return ( $t->hour * 3600 + $t->min * 60 + $t->sec ) / 86400;
}
sub _frac_week {
my $t = shift;
return ( $t->day_of_week * 86400 + $t->hour * 3600 + $t->min * 60 + $t->sec ) / 604800;
}
my $TWO_PI = 2 * atan2( 0, -1 ); # atan2(0,-1) == pi, core-only, no POSIX
# part name => how to pull it off a Time::Piece object.
lib/Algorithm/ToNumberMunger.pm view on Meta::CPAN
year => sub { $_[0]->year },
mon => sub { $_[0]->mon },
mday => sub { $_[0]->mday },
hour => sub { $_[0]->hour },
min => sub { $_[0]->min },
sec => sub { $_[0]->sec },
wday => sub { $_[0]->day_of_week },
yday => sub { $_[0]->yday },
frac_day => \&_frac_day,
frac_week => \&_frac_week,
sin_day => sub { sin( $TWO_PI * _frac_day( $_[0] ) ) },
lib/Algorithm/ToNumberMunger.pm view on Meta::CPAN
cos_week => sub { cos( $TWO_PI * _frac_week( $_[0] ) ) },
);
# ---- fast fixed-format engine ----------------------------------------------
#
# Time::Piece->strptime costs microseconds per call. When the format is built
# from only the six all-numeric codes below (once each, e.g. the ubiquitous
# '%Y-%m-%dT%H:%M:%S'), we can compile it to a capture regex and derive every
# part with integer math instead -- several times faster, and bit-identical:
# both paths treat the stamp as UTC (strptime with no zone does the same).
# Anything fancier (%b, %z, %j, ...) stays on strptime.
lib/Algorithm/ToNumberMunger.pm view on Meta::CPAN
Y => [ 'year', '[0-9]{4}' ],
m => [ 'mon', '[0-9]{2}' ],
d => [ 'mday', '[0-9]{2}' ],
H => [ 'hour', '[0-9]{2}' ],
M => [ 'min', '[0-9]{2}' ],
S => [ 'sec', '[0-9]{2}' ],
);
# Compile a strptime format into { re, idx } for the arithmetic fast path --
# idx maps field name (year/mon/...) to its capture position -- or return undef
# when the format is not fast-eligible. All six codes must appear exactly once
lib/Algorithm/ToNumberMunger.pm view on Meta::CPAN
# not that the six of them form a real timestamp: '2026-13-01T25:00:00' matches
# the shape. Fields out of range (month 13, hour 24, Feb 30) must not reach the
# blind integer date math -- they are routed to strptime instead, which stays
# the judge of whether such a stamp croaks or normalizes (Time::Piece rolls
# Feb 30 over into March), keeping the two paths value-identical. Seconds stop
# at 59: a :60 leap second is not representable in epoch math, so strptime
# arbitrates it too.
my @DAYS_IN_MONTH = ( 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 );
sub _fast_fields_in_range {
my ( $c, $idx ) = @_;
my ( $y, $m, $d, $H, $M, $S ) = @{$c}[ @{$idx}{qw(year mon mday hour min sec)} ];
return 0 if $m < 1 || $m > 12;
my $dim = $DAYS_IN_MONTH[ $m - 1 ];
$dim = 29 if $m == 2 && ( ( !( $y % 4 ) && $y % 100 ) || !( $y % 400 ) );
return 0 if $d < 1 || $d > $dim;
return 0 if $H > 23 || $M > 59 || $S > 59;
lib/Algorithm/ToNumberMunger.pm view on Meta::CPAN
? $c->[6]
: ( $c->[6] = _days_from_civil( $c->[$iy], $c->[$im], $c->[$id] ) );
};
};
my $sod_of = sub {
my ( $ih, $in, $is ) = @{ $_[0] }{qw(hour min sec)};
return sub { $_[0][$ih] * 3600 + $_[0][$in] * 60 + $_[0][$is] };
};
my $frac_day_of = sub {
my $sod = $sod_of->( $_[0] );
return sub { $sod->( $_[0] ) / 86400 };
lib/Algorithm/ToNumberMunger.pm view on Meta::CPAN
year => $field_of->('year'),
mon => $field_of->('mon'),
mday => $field_of->('mday'),
hour => $field_of->('hour'),
min => $field_of->('min'),
sec => $field_of->('sec'),
epoch => sub {
my ( $days, $sod ) = ( $days_of->( $_[0] ), $sod_of->( $_[0] ) );
return sub { $days->( $_[0] ) * 86400 + $sod->( $_[0] ) };
},
wday => sub { # epoch day 0 = Thursday = 4
lib/Algorithm/ToNumberMunger.pm view on Meta::CPAN
# Regex mismatch or out-of-range fields: let strptime be the judge,
# rebuilding the capture array (normalized, when strptime chooses
# to normalize rather than reject) in this format's capture order.
my $t = $strptime->($v);
my @c;
@c[ @{$idx}{qw(year mon mday hour min sec)} ]
= ( $t->year, $t->mon, $t->mday, $t->hour, $t->min, $t->sec );
return \@c;
}; ## end $parse = sub
my $getter_for = sub {
my ($part) = @_;
my $factory = $DATETIME_PART_FAST{$part}
lib/Algorithm/ToNumberMunger.pm view on Meta::CPAN
if defined $spec->{parts};
my ( $parse, $getter_for ) = _datetime_engine( $spec->{format}, $where );
my $get = $getter_for->( defined $spec->{part} ? $spec->{part} : 'epoch' );
# One-slot memo: event streams repeat the same stamp within a second
# constantly, so the previous input usually answers the next call with a
# string compare. A parse failure leaves the memo untouched.
my ( $memo_in, $memo_out );
return sub {
my ($v) = @_;
lib/Algorithm/ToNumberMunger.pm view on Meta::CPAN
Per-entity sliding-window event rates via the C<iqbi-damiq> daemon shipped with
L<Algorithm::EventsPerSecond> (see
L<Algorithm::EventsPerSecond::Sukkal>). The input value becomes a meter B<key>
(after C<prefix> is prepended); by default the munger B<marks> one event against
that key and returns the key's current events-per-second, using the daemon's
C<MARKRATE> command -- mark and query in a single command with a single reply.
This is the munger behind rate columns like a per-source request rate: every
event marks its source's meter and stores the rate the meter now reads.
Unlike every other munger this one consults external state -- but the state
lib/Algorithm/ToNumberMunger.pm view on Meta::CPAN
reply is discarded), so a marking failure still comes back as an ordinary
first reply. With C<< mark => 0 >> the munger only reads, for columns whose
marking is done elsewhere -- e.g. an NXDOMAIN rate is I<marked> by the pipeline
only on NXDOMAIN responses but I<read> on every row.
=item * C<read> - what to read: C<rate> (events/sec over the daemon's window,
default), C<count> (events inside the window), or C<total> (lifetime).
=item * C<parts> + C<into> - multi-output form (see L</compile>): read several
of C<rate>/C<count>/C<total> for the one key in a single round trip, filling one
column each. When marking, the C<MARKRATE> reply itself serves the first C<rate>
lib/Algorithm/ToNumberMunger.pm view on Meta::CPAN
=item * C<on_error> - C<'die'> (default) croaks the write when the daemon is
unreachable or replies C<ERR>; a number is returned instead as a quiet fallback.
Note C<0> is indistinguishable from a genuinely idle key, so quiet fallback
biases the column -- loud is the default on purpose.
=item * C<timeout> - per-operation socket timeout in seconds (default 5,
best-effort via C<SO_RCVTIMEO>/C<SO_SNDTIMEO>), so a wedged daemon cannot hang a
writer forever.
=back
view all matches for this distribution
view release on metacpan or search on metacpan
lib/Algorithm/TokenBucket.pm view on Meta::CPAN
=over 4
=item new($$;$$)
The constructor requires at least the C<rate of information> in items per
second and the C<burst size> in items as its input parameters. It can also
take the current token counter and last check time but this usage is mostly
intended for restoring a saved bucket. See L</state()>.
=cut
lib/Algorithm/TokenBucket.pm view on Meta::CPAN
($self->{_tokens} -= $size) < 0 and $self->{_tokens} = 0;
}
=item until($)
This method returns the number of seconds until I<N> tokens can be removed
from the bucket. It is especially useful in multitasking environments like
L<POE> where you cannot busy-wait. One can safely schedule the next
C<< conform($N) >> check in C<< until($N) >> seconds instead of checking
repeatedly.
Note that C<until()> does not take into account C<burst size>. This means
that a bucket will not conform to I<N> even after sleeping for C<< until($N) >>
seconds if I<N> is greater than C<burst size>.
=cut
sub until {
my Algorithm::TokenBucket $self = shift;
lib/Algorithm/TokenBucket.pm view on Meta::CPAN
Documentation lacks the actual algorithm description. See links or read
the source (there are about 20 lines of sparse Perl in several subs).
C<until($N)> does not return infinity if C<$N> is greater than C<burst
size>. Sleeping for infinity seconds is both useless and hard to debug.
=head1 ACKNOWLEDGMENTS
Yuval Kogman contributed the L</until($)> method, proper L<Storable> support
and other things.
view all matches for this distribution
view release on metacpan or search on metacpan
lib/Algorithm/Toy/HashSC.pm view on Meta::CPAN
#
# Toy deterministic separate chain hash implementation, based on code in
# "Algorithms (4th Edition)" by Robert Sedgewick and Kevin Wayne. This
# code is not for any sort of use where performance is critical, or
# where malicious input may cause "Algorithmic Complexity Attacks" (see
# perlsec(1)).
#
# run perldoc(1) on this file for additional documentation
package Algorithm::Toy::HashSC;
lib/Algorithm/Toy/HashSC.pm view on Meta::CPAN
be added by varying the modulus, or changing the B<hash> or
B<hashcode> methods.
This module is not for use where performance is a concern, or where
untrusted user input may be supplied for the key material.
L<perlsec/"Algorithmic Complexity Attacks"> discusses why Perl's hash
are no longer deterministic and thus not suitable for deterministic
music composition.
=head1 CONSTRUCTOR
lib/Algorithm/Toy/HashSC.pm view on Meta::CPAN
the hash key can be an object that provides a B<hashcode> method, in
which case this issue falls out of scope of this module.
=head1 SEE ALSO
L<perlsec/"Algorithmic Complexity Attacks"> - details on why Perl's hash
do not behave so simply as that of this module do.
"Algorithms" (4th Edition) by Robert Sedgewick and Kevin Wayne.
L<Hash::Util> - insight into Perl's hashes.
view all matches for this distribution
view release on metacpan or search on metacpan
lib/Algorithm/TravelingSalesman/BitonicTour.pm view on Meta::CPAN
=over 4
=item
Cormen, Thomas H.; Leiserson, Charles E.; Rivest, Ronald L.; Stein, Clifford
(2001). Introduction to Algorithms, second edition, MIT Press and McGraw-Hill.
ISBN 978-0-262-53196-2.
=item
Bentley, Jon L. (1990), "Experiments on traveling salesman heuristics", Proc.
view all matches for this distribution
view release on metacpan or search on metacpan
=head1 EXAMPLES
=head2 ALGORITHM
This section describes the algorithm used for preprocessing and for
nearest common ancestor retrieval. It does not provide any intuition
to I<why> the algorithm works, just a description how it works. For
the algorithm description, it is assumed that the nodes themself
contain all necessary information. The algorithm is described in a
Pascal-like fashion. For detailed information about the algorithm,
Done
node.max := num;
Return (num,node.run)
End;
In the second phase, we compute the I<leader> for each run (which we
can since we know the run for each node) and the I<magic> number. The
leader I<has> to be stored so that we can access is through a node
number, so we store it in an array.
VAR Leader : Array [1..NODE_COUNT] of NodePtr;
view all matches for this distribution
view release on metacpan or search on metacpan
lib/Algorithm/TrunkClassifier/Util.pm view on Meta::CPAN
use strict;
our $VERSION = 'v1.0.1';
#Description: Sorts two arrays in accending order based on values in the first
#Parameters: (1) Numerical array reference, (2) second array reference
#Return value: None
sub dataSort($ $){
my ($numArrayRef, $secondArrayRef) = @_;
my $limiter = 1;
for(my $outer = 0; $outer < scalar(@{$numArrayRef}); $outer++){
for(my $inner = 0; $inner < scalar(@{$numArrayRef}) - $limiter; $inner++){
if(${$numArrayRef}[$inner] > ${$numArrayRef}[$inner+1]){
my $buffer = ${$numArrayRef}[$inner];
${$numArrayRef}[$inner] = ${$numArrayRef}[$inner+1];
${$numArrayRef}[$inner+1] = $buffer;
$buffer = ${$secondArrayRef}[$inner];
${$secondArrayRef}[$inner] = ${$secondArrayRef}[$inner+1];
${$secondArrayRef}[$inner+1] = $buffer;
}
}
$limiter++;
}
}
view all matches for this distribution
view release on metacpan or search on metacpan
examples/calculate_precision_and_recall_from_file_based_relevancies_for_VSM.pl view on Meta::CPAN
# the documents relevant to each of the queries:
#$vsm->display_doc_relevancies();
# Use only one of the following statements. If you wish to carry out
# precision vs. recall analysis for LSA, comment out the first and
# uncomment the second.
$vsm->precision_and_recall_calculator('vsm');
$vsm->display_precision_vs_recall_for_queries();
$vsm->display_average_precision_for_queries_and_map();
view all matches for this distribution
view release on metacpan or search on metacpan
t/sortition/10-rfc3797.t view on Meta::CPAN
my $avs = 'Algorithm::Voting::Sortition';
use_ok($avs);
# verify that A::V::S generates the same keystring as in
# L<http://tools.ietf.org/html/rfc3797#section-6>
{
my @source = (
"9319",
[ qw/ 2 5 12 8 10 / ], # <= this one gets sorted
[ qw/ 9 18 26 34 41 45 /],
t/sortition/10-rfc3797.t view on Meta::CPAN
my $ks = q(9319./2.5.8.10.12./9.18.26.34.41.45./);
is ($avs->make_keystring(@source), $ks);
}
# verify that A::V::S generates checksums identical to
# L<http://tools.ietf.org/html/rfc3797#section-6>
{
my $ks = q(9319./2.5.8.10.12./9.18.26.34.41.45./);
my $box = Algorithm::Voting::Sortition->new(candidates => [], n => 10, keystring => $ks);
is($box->n, 10);
is($box->keystring, $ks);
view all matches for this distribution
view release on metacpan or search on metacpan
t/Relativity.test view on Meta::CPAN
sufficiently obvious to ensure that differences of opinion are
scarcely likely to arise as to its applicability in practice.
*** A refinement and modification of these views does not become
necessary until we come to deal with the general theory of relativity,
treated in the second part of this book.
SPACE AND TIME IN CLASSICAL MECHANICS
t/Relativity.test view on Meta::CPAN
see the stone descend in a straight line. A pedestrian who observes
the misdeed from the footpath notices that the stone falls to earth in
a parabolic curve. I now ask: Do the "positions" traversed by the
stone lie "in reality" on a straight line or on a parabola? Moreover,
what is meant here by motion "in space" ? From the considerations of
the previous section the answer is self-evident. In the first place we
entirely shun the vague word "space," of which, we must honestly
acknowledge, we cannot form the slightest conception, and we replace
it by "motion relative to a practically rigid body of reference." The
positions relative to the body of reference (railway carriage or
embankment) have already been defined in detail in the preceding
section. If instead of " body of reference " we insert " system of
co-ordinates," which is a useful idea for mathematical description, we
are in a position to say : The stone traverses a straight line
relative to a system of co-ordinates rigidly attached to the carriage,
but relative to a system of co-ordinates rigidly attached to the
ground (embankment) it describes a parabola. With the aid of this
t/Relativity.test view on Meta::CPAN
the man at the railway-carriage window is holding one of them, and the
man on the footpath the other. Each of the observers determines the
position on his own reference-body occupied by the stone at each tick
of the clock he is holding in his hand. In this connection we have not
taken account of the inaccuracy involved by the finiteness of the
velocity of propagation of light. With this and with a second
difficulty prevailing here we shall have to deal in detail later.
Notes
t/Relativity.test view on Meta::CPAN
the motion of the raven would be one of different velocity and
direction, but that it would still be uniform and in a straight line.
Expressed in an abstract manner we may say : If a mass m is moving
uniformly in a straight line with respect to a co-ordinate system K,
then it will also be moving uniformly and in a straight line relative
to a second co-ordinate system K1 provided that the latter is
executing a uniform translatory motion with respect to K. In
accordance with the discussion contained in the preceding section, it
follows that:
If K is a Galileian co-ordinate system. then every other co-ordinate
system K' is a Galileian one, when, in relation to K, it is in a
condition of uniform motion of translation. Relative to K1 the
t/Relativity.test view on Meta::CPAN
relativity must therefore apply with great accuracy in the domain of
mechanics. But that a principle of such broad generality should hold
with such exactness in one domain of phenomena, and yet should be
invalid for another, is a priori not very probable.
We now proceed to the second argument, to which, moreover, we shall
return later. If the principle of relativity (in the restricted sense)
does not hold, then the Galileian co-ordinate systems K, K1, K2, etc.,
which are moving uniformly relative to each other, will not be
equivalent for the description of natural phenomena. In this case we
should be constrained to believe that natural laws are capable of
t/Relativity.test view on Meta::CPAN
would be different from that emitted if the axis of the pipe were
placed perpendicular to this direction.
Now in virtue of its motion in an orbit round the sun, our earth is
comparable with a railway carriage travelling with a velocity of about
30 kilometres per second. If the principle of relativity were not
valid we should therefore expect that the direction of motion of the
earth at any moment would enter into the laws of nature, and also that
physical systems in their behaviour would be dependent on the
orientation in space with respect to the earth. For owing to the
alteration in direction of the velocity of revolution of the earth in
t/Relativity.test view on Meta::CPAN
along the rails with a constant velocity v, and that a man traverses
the length of the carriage in the direction of travel with a velocity
w. How quickly or, in other words, with what velocity W does the man
advance relative to the embankment during the process ? The only
possible answer seems to result from the following consideration: If
the man were to stand still for a second, he would advance relative to
the embankment through a distance v equal numerically to the velocity
of the carriage. As a consequence of his walking, however, he
traverses an additional distance w relative to the carriage, and hence
also relative to the embankment, in this second, the distance w being
numerically equal to the velocity with which he is walking. Thus in
total be covers the distance W=v+w relative to the embankment in the
second considered. We shall see later that this result, which
expresses the theorem of the addition of velocities employed in
classical mechanics, cannot be maintained ; in other words, the law
that we have just written down does not hold in reality. For the time
being, however, we shall assume its correctness.
t/Relativity.test view on Meta::CPAN
There is hardly a simpler law in physics than that according to which
light is propagated in empty space. Every child at school knows, or
believes he knows, that this propagation takes place in straight lines
with a velocity c= 300,000 km./sec. At all events we know with great
exactness that this velocity is the same for all colours, because if
this were not the case, the minimum of emission would not be observed
simultaneously for different colours during the eclipse of a fixed
star by its dark neighbour. By means of similar considerations based
on observa- tions of double stars, the Dutch astronomer De Sitter was
t/Relativity.test view on Meta::CPAN
embankment. Now let us suppose that our railway carriage is again
travelling along the railway lines with the velocity v, and that its
direction is the same as that of the ray of light, but its velocity of
course much less. Let us inquire about the velocity of propagation of
the ray of light relative to the carriage. It is obvious that we can
here apply the consideration of the previous section, since the ray of
light plays the part of the man walking along relatively to the
carriage. The velocity w of the man relative to the embankment is here
replaced by the velocity of light relative to the embankment. w is the
required velocity of light with respect to the carriage, and we have
t/Relativity.test view on Meta::CPAN
simultaneity; if we discard this assumption, then the conflict between
the law of the propagation of light in vacuo and the principle of
relativity (developed in Section 7) disappears.
We were led to that conflict by the considerations of Section 6,
which are now no longer tenable. In that section we concluded that the
man in the carriage, who traverses the distance w per second relative
to the carriage, traverses the same distance also with respect to the
embankment in each second of time. But, according to the foregoing
considerations, the time required by a particular occurrence with
respect to the carriage must not be considered equal to the duration
of the same occurrence as judged from the embankment (as
reference-body). Hence it cannot be contended that the man in walking
travels the distance w relative to the railway line in a time which is
equal to one second as judged from the embankment.
Moreover, the considerations of Section 6 are based on yet a second
assumption, which, in the light of a strict consideration, appears to
be arbitrary, although it was always tacitly made even before the
introduction of the theory of relativity.
t/Relativity.test view on Meta::CPAN
A priori it is by no means certain that this last measurement will
supply us with the same result as the first. Thus the length of the
train as measured from the embankment may be different from that
obtained by measuring in the train itself. This circumstance leads us
to a second objection which must be raised against the apparently
obvious consideration of Section 6. Namely, if the man in the
carriage covers the distance w in a unit of time -- measured from the
train, -- then this distance -- as measured from the embankment -- is
not necessarily also equal to w.
t/Relativity.test view on Meta::CPAN
THE LORENTZ TRANSFORMATION
The results of the last three sections show that the apparent
incompatibility of the law of propagation of light with the principle
of relativity (Section 7) has been derived by means of a
consideration which borrowed two unjustifiable hypotheses from
classical mechanics; these are as follows:
t/Relativity.test view on Meta::CPAN
vertical direction by means of a framework of rods, so that an event
which takes place anywhere can be localised with reference to this
framework. Fig. 2 Similarly, we can imagine the train travelling with
the velocity v to be continued across the whole of space, so that
every event, no matter how far off it may be, could also be localised
with respect to the second framework. Without committing any
fundamental error, we can disregard the fact that in reality these
frameworks would continually interfere with each other, owing to the
impenetrability of solid bodies. In every such framework we imagine
three surfaces perpendicular to each other marked out, and designated
as " co-ordinate planes " (" co-ordinate system "). A co-ordinate
t/Relativity.test view on Meta::CPAN
nothing more nor less than the results of measurements obtainable by
means of measuring-rods and clocks. If we had based our considerations
on the Galileian transformation we should not have obtained a
contraction of the rod as a consequence of its motion.
Let us now consider a seconds-clock which is permanently situated at
the origin (x1=0) of K1. t1=0 and t1=I are two successive ticks of
this clock. The first and fourth equations of the Lorentz
transformation give for these two ticks :
t = 0
t/Relativity.test view on Meta::CPAN
eq. 07: file eq07.gif
As judged from K, the clock is moving with the velocity v; as judged
from this reference-body, the time which elapses between two strokes
of the clock is not one second, but
eq. 08: file eq08.gif
seconds, i.e. a somewhat larger time. As a consequence of its motion
the clock goes more slowly than when at rest. Here also the velocity c
plays the part of an unattainable limiting velocity.
t/Relativity.test view on Meta::CPAN
THE EXPERIMENT OF FIZEAU
Now in practice we can move clocks and measuring-rods only with
velocities that are small compared with the velocity of light; hence
we shall hardly be able to compare the results of the previous section
directly with the reality. But, on the other hand, these results must
strike you as being very singular, and for that reason I shall now
draw another conclusion from the theory, one which can easily be
derived from the foregoing considerations, and which has been most
elegantly confirmed by experiment.
t/Relativity.test view on Meta::CPAN
Figure 03: file fig03.gif
man walking along the carriage, or of the moving point in the present
section. If we denote the velocity of the light relative to the tube
by W, then this is given by the equation (A) or (B), according as the
Galilei transformation or the Lorentz transformation corresponds to
the facts. Experiment * decides in favour of equation (B) derived
from the theory of relativity, and the agreement is, indeed, very
exact. According to recent and most excellent measurements by Zeeman,
t/Relativity.test view on Meta::CPAN
eq. 17: file eq17.gif
When eq. 18 is small compared with unity, the third of these terms is
always small in comparison with the second,
which last is alone considered in classical mechanics. The first term
mc^2 does not contain the velocity, and requires no consideration if
we are only dealing with the question as to how the energy of a
point-mass; depends on the velocity. We shall speak of its essential
t/Relativity.test view on Meta::CPAN
the behaviour of the electron. We arrived at a similar conclusion in
Section 13 in connection with the experiment of Fizeau, the result
of which is foretold by the theory of relativity without the necessity
of drawing on hypotheses as to the physical nature of the liquid.
The second class of facts to which we have alluded has reference to
the question whether or not the motion of the earth in space can be
made perceptible in terrestrial experiments. We have already remarked
in Section 5 that all attempts of this nature led to a negative
result. Before the theory of relativity was put forward, it was
difficult to become reconciled to this negative result, for reasons
t/Relativity.test view on Meta::CPAN
It is true that this important law had hitherto been recorded in
mechanics, but it had not been interpreted. A satisfactory
interpretation can be obtained only if we recognise the following fact
: The same quality of a body manifests itself according to
circumstances as " inertia " or as " weight " (lit. " heaviness '). In
the following section we shall show to what extent this is actually
the case, and how this question is connected with the general
postulate of relativity.
t/Relativity.test view on Meta::CPAN
acceleration of the body towards the floor of the chest is always of
the same magnitude, whatever kind of body he may happen to use for the
experiment.
Relying on his knowledge of the gravitational field (as it was
discussed in the preceding section), the man in the chest will thus
come to the conclusion that he and the chest are in a gravitational
field which is constant with regard to time. Of course he will be
puzzled for a moment as to why the chest does not fall in this
gravitational field. just then, however, he discovers the hook in the
middle of the lid of the chest and the rope which is attached to it,
t/Relativity.test view on Meta::CPAN
In the first place, it can be compared with the reality. Although a
detailed examination of the question shows that the curvature of light
rays required by the general theory of relativity is only exceedingly
small for the gravitational fields at our disposal in practice, its
estimated magnitude for light rays passing the sun at grazing
incidence is nevertheless 1.7 seconds of arc. This ought to manifest
itself in the following way. As seen from the earth, certain fixed
stars appear to be in the neighbourhood of the sun, and are thus
capable of observation during a total eclipse of the sun. At such
times, these stars ought to appear to be displaced outwards from the
sun by an amount indicated above, as compared with their apparent
position in the sky when the sun is situated at another part of the
heavens. The examination of the correctness or otherwise of this
deduction is a problem of the greatest importance, the early solution
of which is to be expected of astronomers.[2]*
In the second place our result shows that, according to the general
theory of relativity, the law of the constancy of the velocity of
light in vacuo, which constitutes one of the two fundamental
assumptions in the special theory of relativity and to which we have
already frequently referred, cannot claim any unlimited validity. A
curvature of rays of light can only take place when the velocity of
t/Relativity.test view on Meta::CPAN
used before. Let us consider a space time domain in which no
gravitational field exists relative to a reference-body K whose state
of motion has been suitably chosen. K is then a Galileian
reference-body as regards the domain considered, and the results of
the special theory of relativity hold relative to K. Let us supposse
the same domain referred to a second body of reference K1, which is
rotating uniformly with respect to K. In order to fix our ideas, we
shall imagine K1 to be in the form of a plane circular disc, which
rotates uniformly in its own plane about its centre. An observer who
is sitting eccentrically on the disc K1 is sensible of a force which
acts outwards in a radial direction, and which would be interpreted as
t/Relativity.test view on Meta::CPAN
them by means of a number. The Curves u= 1, u= 2 and u= 3 are drawn in
the diagram. Between the curves u= 1 and u= 2 we must imagine an
infinitely large number to be drawn, all of which correspond to real
numbers lying between 1 and 2. fig. 04 We have then a system of
u-curves, and this "infinitely dense" system covers the whole surface
of the table. These u-curves must not intersect each other, and
through each point of the surface one and only one curve must pass.
Thus a perfectly definite value of u belongs to every point on the
surface of the marble slab. In like manner we imagine a system of
v-curves drawn on the surface. These satisfy the same conditions as
the u-curves, they are provided with numbers in a corresponding
t/Relativity.test view on Meta::CPAN
continua. For example, this obviously holds in the case of the marble
slab of the table and local variation of temperature. The temperature
is practically constant for a small part of the slab, and thus the
geometrical behaviour of the rods is almost as it ought to be
according to the rules of Euclidean geometry. Hence the imperfections
of the construction of squares in the previous section do not show
themselves clearly until this construction is extended over a
considerable portion of the surface of the table.
We can sum this up as follows: Gauss invented a method for the
mathematical treatment of continua in general, in which "
t/Relativity.test view on Meta::CPAN
Minkowski found that the Lorentz transformations satisfy the following
simple conditions. Let us consider two neighbouring events, the
relative position of which in the four-dimensional continuum is given
with respect to a Galileian reference-body K by the space co-ordinate
differences dx, dy, dz and the time-difference dt. With reference to a
second Galileian system we shall suppose that the corresponding
differences for these two events are dx1, dy1, dz1, dt1. Then these
magnitudes always fulfil the condition*
dx2 + dy2 + dz2 - c^2dt2 = dx1 2 + dy1 2 + dz1 2 - c^2dt1 2.
t/Relativity.test view on Meta::CPAN
Thus, if we choose as time-variable the imaginary variable sq. rt. -I
. ct instead of the real quantity t, we can regard the space-time
contintium -- accordance with the special theory of relativity -- as a
", Euclidean " four-dimensional continuum, a result which follows from
the considerations of the preceding section.
Notes
*) Cf. Appendixes I and 2. The relations which are derived
t/Relativity.test view on Meta::CPAN
been known that the ellipse corresponding to the orbit of Mercury,
after it has been corrected for the influences mentioned above, is not
stationary with respect to the fixed stars, but that it rotates
exceedingly slowly in the plane of the orbit and in the sense of the
orbital motion. The value obtained for this rotary movement of the
orbital ellipse was 43 seconds of arc per century, an amount ensured
to be correct to within a few seconds of arc. This effect can be
explained by means of classical mechanics only on the assumption of
hypotheses which have little probability, and which were devised
solely for this purponse.
On the basis of the general theory of relativity, it is found that the
ellipse of every planet round the sun must necessarily rotate in the
manner indicated above ; that for all the planets, with the exception
of Mercury, this rotation is too small to be detected with the
delicacy of observation possible at the present time ; but that in the
case of Mercury it must amount to 43 seconds of arc per century, a
result which is strictly in agreement with observation.
Apart from this one, it has hitherto been possible to make only two
deductions from the theory which admit of being tested by observation,
to wit, the curvature of light rays by the gravitational field of the
t/Relativity.test view on Meta::CPAN
COSMOLOGICAL DIFFICULTIES OF NEWTON'S THEORY
Part from the difficulty discussed in Section 21, there is a second
fundamental difficulty attending classical celestial mechanics, which,
to the best of my knowledge, was first discussed in detail by the
astronomer Seeliger. If we ponder over the question as to how the
universe, considered as a whole, is to be regarded, the first answer
that suggests itself to us is surely this: As regards space (and time)
t/Relativity.test view on Meta::CPAN
sense in the statement, because they mean that they can perform the
constructions of plane Euclidean geometry with their rods. In this
connection the individual rods always represent the same distance,
independently of their position.
Let us consider now a second two-dimensional existence, but this time
on a spherical surface instead of on a plane. The flat beings with
their measuring-rods and other objects fit exactly on this surface and
they are unable to leave it. Their whole universe of observation
extends exclusively over the surface of the sphere. Are these beings
able to regard the geometry of their universe as being plane geometry
t/Relativity.test view on Meta::CPAN
its eccentricity, c the velocity of light, and T the period of
revolution of the planet. Our result may also be stated as follows :
According to the general theory of relativity, the major axis of the
ellipse rotates round the sun in the same sense as the orbital motion
of the planet. Theory requires that this rotation should amount to 43
seconds of arc per century for the planet Mercury, but for the other
Planets of our solar system its magnitude should be so small that it
would necessarily escape detection. *
In point of fact, astronomers have found that the theory of Newton
does not suffice to calculate the observed motion of Mercury with an
exactness corresponding to that of the delicacy of observation
attainable at the present time. After taking account of all the
disturbing influences exerted on Mercury by the remaining planets, it
was found (Leverrier: 1859; and Newcomb: 1895) that an unexplained
perihelial movement of the orbit of Mercury remained over, the amount
of which does not differ sensibly from the above mentioned +43 seconds
of arc per century. The uncertainty of the empirical result amounts to
a few seconds only.
(b) Deflection of Light by a Gravitational Field
In Section 22 it has been already mentioned that according to the
general theory of relativity, a ray of light will experience a
t/Relativity.test view on Meta::CPAN
D[2], i.e. at a somewhat greater distance from the centre of the sun
than corresponds to its real position.
In practice, the question is tested in the following way. The stars in
the neighbourhood of the sun are photographed during a solar eclipse.
In addition, a second photograph of the same stars is taken when the
sun is situated at another position in the sky, i.e. a few months
earlier or later. As compared whh the standard photograph, the
positions of the stars on the eclipse-photograph ought to appear
displaced radially outwards (away from the centre of the sun) by an
amount corresponding to the angle a.
t/Relativity.test view on Meta::CPAN
was necessary in making the adjustments required for the taking of the
photographs, and in their subsequent measurement.
The results of the measurements confirmed the theory in a thoroughly
satisfactory manner. The rectangular components of the observed and of
the calculated deviations of the stars (in seconds of arc) are set
forth in the following table of results :
Table 01: file table01.gif
(c) Displacement of Spectral Lines Towards the Red
view all matches for this distribution
view release on metacpan or search on metacpan
examples/dlx.pl view on Meta::CPAN
my $opt_print_solutions = $opts{p} || $opts{v};
my $opt_sparse = $opts{s};
my $opt_print_tree = $opts{t};
chomp(my $line = <STDIN>);
my ($width, $secondary_columns) = split ' ', $line;
my @input_rows;
while (defined($line = <STDIN>)) {
chomp($line);
examples/dlx.pl view on Meta::CPAN
@row = split ' ', $line;
}
push @input_rows, \@row if @row;
}
my $problem = $opt_sparse ? Algorithm::X::ExactCoverProblem->new($width, \@input_rows, $secondary_columns)
: Algorithm::X::ExactCoverProblem->dense(\@input_rows, $secondary_columns);
my $dlx = Algorithm::X::DLX->new($problem);
my $result = $dlx->search();
examples/dlx.pl view on Meta::CPAN
-v print solutions by outputting the rows themselves
-t print nodes inspected for each recursion level
-s input is a sparse matrix
The first line of input states the problem matrix width (all columns), optionally
followed by a space and the number of secondary columns therein, at the right.
All following lines are the matrix rows (space separated).
HELP
;
exit(1);
view all matches for this distribution
view release on metacpan or search on metacpan
inc/Module/Install/Metadata.pm view on Meta::CPAN
my $name = shift;
my $features = ( $self->{values}->{features} ||= [] );
my $mods;
if ( @_ == 1 and ref( $_[0] ) ) {
# The user used ->feature like ->features by passing in the second
# argument as a reference. Accomodate for that.
$mods = $_[0];
} else {
$mods = \@_;
}
view all matches for this distribution
view release on metacpan or search on metacpan
t/00-report-prereqs.t view on Meta::CPAN
my @full_reports;
my @dep_errors;
my $req_hash = $HAS_CPAN_META ? $full_prereqs->as_string_hash : $full_prereqs;
# Add static includes into a fake section
for my $mod (@include) {
$req_hash->{other}{modules}{$mod} = 0;
}
for my $phase ( qw(configure build test runtime develop other) ) {
view all matches for this distribution
view release on metacpan or search on metacpan
inc/Module/Install/AutoInstall.pm view on Meta::CPAN
$self->makemaker_args( Module::AutoInstall::_make_args() );
my $class = ref($self);
$self->postamble(
"# --- $class section:\n" .
Module::AutoInstall::postamble()
);
}
sub installdeps_target {
view all matches for this distribution
view release on metacpan or search on metacpan
perlcritic.rc view on Meta::CPAN
theme = ( core + pbp + security + maintenance ) * bugs
include = CodeLayout::ProhibitSpaceIndentation CodeLayout::ProhibitTrailingWhitespace CodeLayout::RequireConsistentNewlines CodeLayout::TabIndentSpaceAlign
[-Subroutines::ProhibitSubroutinePrototypes]
[TestingAndDebugging::RequireUseStrict]
view all matches for this distribution
view release on metacpan or search on metacpan
and utility programs needed for reproducing the Combined Work from the
Application, but excluding the System Libraries of the Combined Work.
1. Exception to Section 3 of the GNU GPL.
You may convey a covered work under sections 3 and 4 of this License
without being bound by section 3 of the GNU GPL.
2. Conveying Modified Versions.
If you modify a copy of the Library, and, in your modifications, a
facility refers to a function or data to be supplied by an Application
0) Convey the Minimal Corresponding Source under the terms of this
License, and the Corresponding Application Code in a form
suitable for, and under terms that permit, the user to
recombine or relink the Application with a modified version of
the Linked Version to produce a modified Combined Work, in the
manner specified by section 6 of the GNU GPL for conveying
Corresponding Source.
1) Use a suitable shared library mechanism for linking with the
Library. A suitable mechanism is one that (a) uses at run time
a copy of the Library already present on the user's computer
system, and (b) will operate properly with a modified version
of the Library that is interface-compatible with the Linked
Version.
e) Provide Installation Information, but only if you would otherwise
be required to provide such information under section 6 of the
GNU GPL, and only to the extent that such information is
necessary to install and execute a modified version of the
Combined Work produced by recombining or relinking the
Application with a modified version of the Linked Version. (If
you use option 4d0, the Installation Information must accompany
the Minimal Corresponding Source and Corresponding Application
Code. If you use option 4d1, you must provide the Installation
Information in the manner specified by section 6 of the GNU GPL
for conveying Corresponding Source.)
5. Combined Libraries.
You may place library facilities that are a work based on the
A "covered work" means either the unmodified Program or a work based
on the Program.
To "propagate" a work means to do anything with it that, without
permission, would make you directly or secondarily liable for
infringement under applicable copyright law, except executing it on a
computer or modifying a private copy. Propagation includes copying,
distribution (with or without modification), making available to the
public, and in some countries other activities as well.
for you must do so exclusively on your behalf, under your direction
and control, on terms that prohibit them from making any copies of
your copyrighted material outside their relationship with you.
Conveying under any other circumstances is permitted solely under
the conditions stated below. Sublicensing is not allowed; section 10
makes it unnecessary.
3. Protecting Users' Legal Rights From Anti-Circumvention Law.
No covered work shall be deemed part of an effective technological
You may convey verbatim copies of the Program's source code as you
receive it, in any medium, provided that you conspicuously and
appropriately publish on each copy an appropriate copyright notice;
keep intact all notices stating that this License and any
non-permissive terms added in accord with section 7 apply to the code;
keep intact all notices of the absence of any warranty; and give all
recipients a copy of this License along with the Program.
You may charge any price or no price for each copy that you convey,
and you may offer support or warranty protection for a fee.
5. Conveying Modified Source Versions.
You may convey a work based on the Program, or the modifications to
produce it from the Program, in the form of source code under the
terms of section 4, provided that you also meet all of these conditions:
a) The work must carry prominent notices stating that you modified
it, and giving a relevant date.
b) The work must carry prominent notices stating that it is
released under this License and any conditions added under section
7. This requirement modifies the requirement in section 4 to
"keep intact all notices".
c) You must license the entire work, as a whole, under this
License to anyone who comes into possession of a copy. This
License will therefore apply, along with any applicable section 7
additional terms, to the whole of the work, and all its parts,
regardless of how they are packaged. This License gives no
permission to license the work in any other way, but it does not
invalidate such permission if you have separately received it.
parts of the aggregate.
6. Conveying Non-Source Forms.
You may convey a covered work in object code form under the terms
of sections 4 and 5, provided that you also convey the
machine-readable Corresponding Source under the terms of this License,
in one of these ways:
a) Convey the object code in, or embodied in, a physical product
(including a physical distribution medium), accompanied by the
c) Convey individual copies of the object code with a copy of the
written offer to provide the Corresponding Source. This
alternative is allowed only occasionally and noncommercially, and
only if you received the object code with such an offer, in accord
with subsection 6b.
d) Convey the object code by offering access from a designated
place (gratis or for a charge), and offer equivalent access to the
Corresponding Source in the same way through the same place at no
further charge. You need not require recipients to copy the
available for as long as needed to satisfy these requirements.
e) Convey the object code using peer-to-peer transmission, provided
you inform other peers where the object code and Corresponding
Source of the work are being offered to the general public at no
charge under subsection 6d.
A separable portion of the object code, whose source code is excluded
from the Corresponding Source as a System Library, need not be
included in conveying the object code work.
a modified version of its Corresponding Source. The information must
suffice to ensure that the continued functioning of the modified object
code is in no case prevented or interfered with solely because
modification has been made.
If you convey an object code work under this section in, or with, or
specifically for use in, a User Product, and the conveying occurs as
part of a transaction in which the right of possession and use of the
User Product is transferred to the recipient in perpetuity or for a
fixed term (regardless of how the transaction is characterized), the
Corresponding Source conveyed under this section must be accompanied
by the Installation Information. But this requirement does not apply
if neither you nor any third party retains the ability to install
modified object code on the User Product (for example, the work has
been installed in ROM).
network may be denied when the modification itself materially and
adversely affects the operation of the network or violates the rules and
protocols for communication across the network.
Corresponding Source conveyed, and Installation Information provided,
in accord with this section must be in a format that is publicly
documented (and with an implementation available to the public in
source code form), and must require no special password or key for
unpacking, reading or copying.
7. Additional Terms.
Notwithstanding any other provision of this License, for material you
add to a covered work, you may (if authorized by the copyright holders of
that material) supplement the terms of this License with terms:
a) Disclaiming warranty or limiting liability differently from the
terms of sections 15 and 16 of this License; or
b) Requiring preservation of specified reasonable legal notices or
author attributions in that material or in the Appropriate Legal
Notices displayed by works containing it; or
it) with contractual assumptions of liability to the recipient, for
any liability that these contractual assumptions directly impose on
those licensors and authors.
All other non-permissive additional terms are considered "further
restrictions" within the meaning of section 10. If the Program as you
received it, or any part of it, contains a notice stating that it is
governed by this License along with a term that is a further
restriction, you may remove that term. If a license document contains
a further restriction but permits relicensing or conveying under this
License, you may add to a covered work material governed by the terms
of that license document, provided that the further restriction does
not survive such relicensing or conveying.
If you add terms to a covered work in accord with this section, you
must place, in the relevant source files, a statement of the
additional terms that apply to those files, or a notice indicating
where to find the applicable terms.
Additional terms, permissive or non-permissive, may be stated in the
You may not propagate or modify a covered work except as expressly
provided under this License. Any attempt otherwise to propagate or
modify it is void, and will automatically terminate your rights under
this License (including any patent licenses granted under the third
paragraph of section 11).
However, if you cease all violation of this License, then your
license from a particular copyright holder is reinstated (a)
provisionally, unless and until the copyright holder explicitly and
finally terminates your license, and (b) permanently, if the copyright
violation by some reasonable means, this is the first time you have
received notice of violation of this License (for any work) from that
copyright holder, and you cure the violation prior to 30 days after
your receipt of the notice.
Termination of your rights under this section does not terminate the
licenses of parties who have received copies or rights from you under
this License. If your rights have been terminated and not permanently
reinstated, you do not qualify to receive new licenses for the same
material under section 10.
9. Acceptance Not Required for Having Copies.
You are not required to accept this License in order to receive or
run a copy of the Program. Ancillary propagation of a covered work
permission to link or combine any covered work with a work licensed
under version 3 of the GNU Affero General Public License into a single
combined work, and to convey the resulting work. The terms of this
License will continue to apply to the part which is the covered work,
but the special requirements of the GNU Affero General Public License,
section 13, concerning interaction through a network will apply to the
combination as such.
14. Revised Versions of this License.
The Free Software Foundation may publish revised and/or new versions of
view all matches for this distribution
view release on metacpan or search on metacpan
t/00-report-prereqs.t view on Meta::CPAN
my @full_reports;
my @dep_errors;
my $req_hash = $HAS_CPAN_META ? $full_prereqs->as_string_hash : $full_prereqs;
# Add static includes into a fake section
for my $mod (@include) {
$req_hash->{other}{modules}{$mod} = 0;
}
for my $phase ( qw(configure build test runtime develop other) ) {
view all matches for this distribution
view release on metacpan or search on metacpan
lib/Alien/Base/Dino.pm view on Meta::CPAN
B<building> dynamic libraries for an L<Alien> B<share> install introduce
a number of challenges, and honestly I don't see the point of using
them, if you can avoid it. So far I haven't actually seen a situation
where it couldn't be avoided. Just to be clear: dynamic libraries are
fine for Alien, and in fact desirable when you are using the system
provided libraries. You get the patches and security fixes supplied by
your operating system.
Okay, so why not build a dynamic library for a B<share> install?
For this discussion, say you have an alienized library C<Alien::libfoo>
lib/Alien/Base/Dino.pm view on Meta::CPAN
=item Your platform may not be supported
=back
Also, this module should start with the caveat section and then go from
there. Most modules I write are not like that.
These platforms seem to work: Linux, OS X, Windows, Cygwin, FreeBSD,
NetBSD, OpenBSD, Debian kFreeBSD.
view all matches for this distribution
view release on metacpan or search on metacpan
lib/Alien/Base/ModuleBuild.pm view on Meta::CPAN
or C<digest_and_encrypt>. This is based on the C<ALIEN_DOWNLOAD_RULE>
environment variable.
=head1 GUIDE TO DOCUMENTATION
The documentation for C<Module::Build> is broken up into sections:
=over
=item General Usage (L<Module::Build>)
lib/Alien/Base/ModuleBuild.pm view on Meta::CPAN
Set to a true value to install to an arch-specific directory.
=item B<ALIEN_DOWNLOAD_RULE>
This controls security options for fetching alienized packages over the internet.
The legal values are:
=over 4
=item C<warn>
lib/Alien/Base/ModuleBuild.pm view on Meta::CPAN
the L<Alien>. This will be the default in the near future.
=item C<digest_and_encrypt>
Fetch will only happen if the alienized package has a cryptographic signature digest,
and is fetched via a secure protocol (like C<https>). Bundled packages are also
considered fetch via a secure protocol, but will still require a digest.
=back
=item B<ALIEN_FORCE>
view all matches for this distribution
view release on metacpan or search on metacpan
lib/Alien/Base/Wrapper.pm view on Meta::CPAN
compiler and linker that Perl is configured to use. It takes the normal compiler and
linker flags and adds the flags provided by the Aliens specified, and then executes the
command. It will print the command to the console so that you can see exactly what is
happening.
In the second example (from Makefile.PL non-dynamic), this class is used to generate the
appropriate L<ExtUtils::MakeMaker> (EUMM) arguments needed to C<WriteMakefile>.
In the third example (from Makefile.PL dynamic), we do a quick check to see if the simple
linker flag C<-lfoo> will work, if so we use that. If not, we use a wrapper around the
compiler and linker that will use the alien flags that are known at build time. The
view all matches for this distribution
view release on metacpan or search on metacpan
0.022_01 Fri Jul 31, 2015
- Add support for ALIEN_INSTALL_TYPE environment variable
0.022 Mon Jul 20, 2015
- Correction for the section "How do I specify a minumum or exact version
requirement for packages that use pkg-config?" in the FAQ.
0.021_01 Wed Jul 15, 2015
- Added a default %{pkg_config} helper
- Fixed bug introduced in 0.016_01 where using --destdir or $ENV{DESTDIR}
view all matches for this distribution