Algorithm-LBFGS

 view release on metacpan or  search on metacpan

README  view on Meta::CPAN

      s = progress_cb(x, g, fx, xnorm, gnorm, step, k, ls, user_data)

    "x" (array ref) is the current values of variables. "g" (array ref) is
    the current gradient vector. "fx" is the current function value. "xnorm"
    and "gnorm" is the L2 norm of "x" and "g". "step" is the line-search
    step used for this iteration. "k" is the iteration count. "ls" is the
    number of evaluations in this iteration. "user_data" is the extra user
    data specified when calling "fmin".

    The progress callback subroutine is supposed to return an indicating
    value "s" for "fmin" to decide whether the optimization should continue
    or stop. "fmin" continues to the next iteration when "s=0", otherwise,
    it terminates with status code "LBFGSERR_CANCELED".

    The client program can also pass string values to "progress_cb", which
    means it want to use a predefined progress callback subroutine. There
    are two predefined progress callback subroutines, 'verbose' and
    'logging'. 'verbose' just prints out all information of each iteration,
    while 'logging' logs the same information in an array ref provided by
    "user_data".

inc/Module/Install.pm  view on Meta::CPAN

#     2. $INC{inc/Module/Install.pm} set to ./inc/ version of Module::Install
#     3. The ./inc/ version of Module::Install loads
# }

use 5.004;
use strict 'vars';

use vars qw{$VERSION};
BEGIN {
    # All Module::Install core packages now require synchronised versions.
    # This will be used to ensure we don't accidentally load old or
    # different versions of modules.
    # This is not enforced yet, but will be some time in the next few
    # releases once we can make sure it won't clash with custom
    # Module::Install extensions.
    $VERSION = '0.68';
}

# Whether or not inc::Module::Install is actually loaded, the
# $INC{inc/Module/Install.pm} is what will still get set as long as
# the caller loaded module this in the documented manner.

inc/Test/Builder.pm  view on Meta::CPAN

    $self->_print($out) unless $self->no_header;
    exit(0);
}

#line 382

sub ok {
    my($self, $test, $name) = @_;

    # $test might contain an object which we don't want to accidentally
    # store, so we turn it into a boolean.
    $test = $test ? 1 : 0;

    $self->_plan_check;

    lock $self->{Curr_Test};
    $self->{Curr_Test}++;

    # In case $name is a string overloaded object, force it to stringify.
    $self->_unoverload_str(\$name);

inc/Test/More.pm  view on Meta::CPAN

#line 1
package Test::More;

use 5.004;

use strict;


# Can't use Carp because it might cause use_ok() to accidentally succeed
# even though the module being used forgot to use Carp.  Yes, this
# actually happened.
sub _carp {
    my($file, $line) = (caller(1))[1,2];
    warn @_, " at $file line $line\n";
}



use vars qw($VERSION @ISA @EXPORT %EXPORT_TAGS $TODO);

inc/Test/More.pm  view on Meta::CPAN

sub eq_set  {
    my($a1, $a2) = @_;
    return 0 unless @$a1 == @$a2;

    # There's faster ways to do this, but this is easiest.
    local $^W = 0;

    # It really doesn't matter how we sort them, as long as both arrays are 
    # sorted with the same algorithm.
    #
    # Ensure that references are not accidentally treated the same as a
    # string containing the reference.
    #
    # Have to inline the sort routine due to a threading/sort bug.
    # See [rt.cpan.org 6782]
    #
    # I don't know how references would be sorted so we just don't sort
    # them.  This means eq_set doesn't really work with refs.
    return eq_array(
           [grep(ref, @$a1), sort( grep(!ref, @$a1) )],
           [grep(ref, @$a2), sort( grep(!ref, @$a2) )],

lib/Algorithm/LBFGS.pm  view on Meta::CPAN

  s = progress_cb(x, g, fx, xnorm, gnorm, step, k, ls, user_data)

C<x> (array ref) is the current values of variables. C<g> (array ref) is the
current gradient vector. C<fx> is the current function value. C<xnorm>
and C<gnorm> is the L2 norm of C<x> and C<g>. C<step> is the line-search
step used for this iteration. C<k> is the iteration count. C<ls> is the
number of evaluations in this iteration. L</"user_data"> is the extra
user data specified when calling L</"fmin">. 

The progress callback subroutine is supposed to return an indicating value
C<s> for L</"fmin"> to decide whether the optimization should continue or
stop. C<fmin> continues to the next iteration when C<s=0>, otherwise, it
terminates with status code L</"LBFGSERR_CANCELED">.

The client program can also pass string values to L</"progress_cb">, which
means it want to use a predefined progress callback subroutine. There are
two predefined progress callback subroutines, 'verbose' and 'logging'.
'verbose' just prints out all information of each iteration, while 'logging'
logs the same information in an array ref provided by L</"user_data">.

  ...