Bio::S...esultI(3pm)

🌸 NAME 🌸

okay so bestie, this is the manual page for Bio::Search::Result::PullResultI(3pm) — she's the Bio::Search::Result::ResultI interface for 'pull' parsers. iconic behavior, truly. 🫶

---

✨ SYNOPSIS ✨

# This is an interface and cannot be instantiated

# typically one gets Results from a SearchIO stream
use Bio::SearchIO;
my $io = Bio::SearchIO->new(-format => 'hmmer_pull',
                            -file   => 't/data/hmmpfam.out');

my $result = $io->next_result;

while( $hit = $result->next_hit()) {
    # enter code here for hit processing
}

my $id = $result->query_name();
my $desc = $result->query_description();
my $dbname = $result->database_name();
my $size = $result->database_letters();
my $num_entries = $result->database_entries();
my $gap_ext = $result->get_parameter('gapext');
my @params = $result->available_parameters;
my $kappa = $result->get_statistic('kappa');
my @statnames = $result->available_statistics;

not me reminding you that this is an interface, so like… you literally cannot instantiate her. she's a concept. a vibe. 💅

---

🦋 DESCRIPTION 🦋

Bio::Search::Result::ResultI objects are the data structures that hold the results from running a search algorithm. so obviously they can carry all kinds of algorithm-specific info plus the deets of the execution itself — but they always have a few fundamental things going on, including the ability to hand you back Bio::Search::Hit::HitI objects. bestie behavior fr fr.

PullResultI is for the fast implementations — the ones that only do parsing work on the result data when you actually ask for information by calling one of the ResultI methods. no pre-chewing, just vibes on demand ✨

a lot of the methods in ResultI are implemented in a way that's suitable for inheriting classes that use Bio::PullParserI. and ngl, it only really makes sense for PullResult modules to be created by (and to have as a -parent) SearchIO modules written using PullParserI. that's just the lore. 🧚

---

💌 FEEDBACK 💌

📬 Mailing Lists

user feedback is an integral part of the evolution of this and other Bioperl modules — like, genuinely, your voice matters here. send your comments and suggestions preferably to one of the Bioperl mailing lists. your participation is much appreciated. 🥹

bioperl-l@bioperl.org                  - General discussion
http://bioperl.org/wiki/Mailing_lists  - About the mailing lists

🫶 Support

please direct usage questions or support issues to the mailing list:

bioperl-l@bioperl.org

rather than to the module maintainer directly. the reason is that many experienced and responsive experts will be able look at the problem and quickly address it. please include a thorough description of the problem with code and data examples if at all possible. give them the full picture bestie, they'll eat it up. 🍓

🐛 Reporting Bugs

report bugs to the Bioperl bug tracking system to help us keep track of the bugs and their resolution. bug reports can be submitted via the web:

https://github.com/bioperl/bioperl-live/issues

---

👑 AUTHOR

Sendu Bala

Email bix@sendu.me.uk

---

📝 COPYRIGHT

Copyright (c) 2006 Sendu Bala.

---

💀 DISCLAIMER

This software is provided "as is" without warranty of any kind.

---

🔥 APPENDIX 🔥

the rest of the documentation details each of the object methods. internal methods are usually preceded with a _. iykyk. 🌈

_setup

• Title: _setup
• Usage: $self->_setup(@args)
• Function: implementers should call this to setup common fields and deal with common arguments to new().
• Returns: n/a
• Args: @args received in new().

next_hit

• Title: next_hit
• Usage: while( $hit = $result->next_hit()) { ... }
• Function: returns the next available Hit object, representing potential matches between the query and various entities from the database.
• Returns: a Bio::Search::Hit::HitI object or undef if there are no more.
• Args: none

sort_hits

• Title: sort_hits
• Usage: $result->sort_hits(\&sort_function)
• Function: sorts the available hit objects by a user-supplied function. defaults to sort by descending score.
• Returns: n/a
• Args: a coderef for the sort function. see the documentation on the Perl sort() function for guidelines on writing sort functions.
• Note: to access the special variables $a and $b used by the Perl sort() function the user function must access Bio::Search::Result::ResultI namespace. For example, use :

$result->sort_hits(sub{$Bio::Search::Result::ResultI::a->length <=>
                                           $Bio::Search::Result::ResultI::b->length});
NOT $result->sort_hits($a->length <=>$b->length);

the $a and $b thing is a whole trap, bestie. use the fully-qualified namespace or perish. 😭

query_name

• Title: query_name
• Usage: $id = $result->query_name();
• Function: get the string identifier of the query used by the algorithm that performed the search.
• Returns: a string.
• Args: none

query_accession

• Title: query_accession
• Usage: $id = $result->query_accession();
• Function: get the accession (if available) for the query sequence
• Returns: a string
• Args: none

query_length

• Title: query_length
• Usage: $id = $result->query_length();
• Function: get the length of the query sequence used in the search.
• Returns: a number
• Args: none

query_description

• Title: query_description
• Usage: $id = $result->query_description();
• Function: get the description of the query sequence used in the search.
• Returns: a string
• Args: none

database_name

• Title: database_name
• Usage: $name = $result->database_name()
• Function: used to obtain the name of the database that the query was searched against by the algorithm.
• Returns: a scalar string
• Args: none

database_letters

• Title: database_letters
• Usage: $size = $result->database_letters()
• Function: used to obtain the size of database that was searched against.
• Returns: a scalar integer (units specific to algorithm, but probably the total number of residues in the database, if available) or undef if the information was not available to the Processor object.
• Args: none

database_entries

• Title: database_entries
• Usage: $num_entries = $result->database_entries()
• Function: used to obtain the number of entries contained in the database.
• Returns: a scalar integer representing the number of entities in the database or undef if the information was not available.
• Args: none

algorithm

• Title: algorithm
• Usage: my $r_type = $result->algorithm
• Function: obtain the name of the algorithm used to obtain the Result
• Returns: string (e.g., BLASTP)
• Args: [optional] scalar string to set value

algorithm_version

• Title: algorithm_version
• Usage: my $r_version = $result->algorithm_version
• Function: obtain the version of the algorithm used to obtain the Result
• Returns: string (e.g., 2.1.2)
• Args: [optional] scalar string to set algorithm version value

algorithm_reference

• Title: algorithm_reference
• Usage: $obj->algorithm_reference($newval)
• Function:
• Returns: value of the literature reference for the algorithm
• Args: newvalue (optional)
• Comments: the default implementation in ResultI returns an empty string rather than throwing a NotImplemented exception, since the ref may not always be available and is not critical.

num_hits

• Title: num_hits
• Usage: my $hitcount= $result->num_hits
• Function: returns the number of hits for this query result
• Returns: integer
• Args: none

hits

• Title: hits
• Usage: my @hits = $result->hits
• Function: returns the HitI objects contained within this Result
• Returns: Array of Bio::Search::Hit::HitI objects
• Args: none

See Also: Bio::Search::Hit::HitI

no_hits_found

• Usage: $nohits = $blast->no_hits_found();
• Function: get boolean indicator indicating whether or not any hits were present in the report.

this is NOT the same as determining the number of hits via the hits() method, which will return zero hits if there were no hits in the report or if all hits were filtered out during the parse.

thus, this method can be used to distinguish these possibilities for hitless reports generated when filtering.

• Returns: Boolean
• Args: none

okay this one matters!! "zero hits" and "no hits found" are two different stories and this is how you tell them apart. periodt. 💅

rewind

• Title: rewind
• Usage: $result->rewind;
• Function: allow one to reset the Hit iterator to the beginning. Since this is an in-memory implementation
• Returns: none
• Args: none

get_parameter

• Title: get_parameter
• Usage: my $gap_ext = $result->get_parameter('gapext')
• Function: returns the value for a specific parameter used when running this result
• Returns: string
• Args: name of parameter (string)

available_parameters

• Title: available_parameters
• Usage: my @params = $result->available_parameters
• Function: returns the names of the available parameters
• Returns: return list of available parameters used for this result
• Args: none

add_parameter

• Title: add_parameter
• Usage: $result->add_parameter('gapext', 11);
• Function: adds a parameter
• Returns: none
• Args:
  • key — key value name for this parama
  • value — value for this parameter

get_statistic

• Title: get_statistic
• Usage: my $gap_ext = $result->get_statistic('kappa')
• Function: returns the value for a specific statistic available from this result
• Returns: string
• Args: name of statistic (string)

available_statistics

• Title: available_statistics
• Usage: my @statnames = $result->available_statistics
• Function: returns the names of the available statistics
• Returns: return list of available statistics used for this result
• Args: none

add_statistic

• Title: add_statistic
• Usage: $result->add_statistic('lambda', 2.3);
• Function: adds a statistic
• Returns: none
• Args:
  • key — key value name for this statistic
  • value — value for this statistic

---

and that's the whole page bestie!! 🎀 this doc came from perl v5.32.1, dated 2021-08-15 — shoutout to the User Contributed Perl Documentation crew for keeping the archive cute. go parse something iconic. 💖✨