% Generated by roxygen2: do not edit by hand
% Please edit documentation in R/segment.R
\name{segment}
\alias{segment}
\title{Segment text with a jieba worker}
\usage{
segment(
  code,
  jiebar,
  ...,
  mod = NULL,
  batch = c("list", "data.frame", "flatten")
)
}
\arguments{
\item{code}{A character vector to segment.}

\item{jiebar}{A \code{jieba_worker} object.}

\item{...}{Must be empty. This enforces that optional arguments such as
\code{mod} and \code{batch} are supplied with explicit names.}

\item{mod}{\link{Deprecated} Compatibility argument retained from \code{jiebaR}. This
argument no longer has any effect.}

\item{batch}{Batch aggregation mode for \strong{multi-string input}. Must be
one of \code{"list"}, \code{"data.frame"}, or \code{"flatten"}. The default is \code{"list"}.}
}
\value{
Segmented tokens in the requested aggregation form.
}
\description{
Segment one or more strings with a \code{jieba_worker} created by \code{\link[=worker]{worker()}}.
}
\details{
For a single input string, \code{segment()} always returns a character vector of
segmented tokens.

When the worker was created with \code{symbol = TRUE}, symbol-like characters are
retained during preprocessing. For example, \code{AK-47}, \code{N95}, \code{X-900}, and
\code{4.55} remain intact. With \code{symbol = FALSE} (the default), non-letter,
non-number, and non-mark characters are replaced with spaces before
segmentation, so the same input is returned as \code{AK}, \code{47}, \code{N95}, \code{X},
\code{900}, \code{4}, and \code{55}.

In the current release benchmarks on the bundled \emph{Fortress Besieged} and
\emph{Dream of the Red Chamber} texts, \code{jiebaRS::segment()} is about \strong{1.7x to
1.9x faster} than \code{jiebaR::segment()} when each novel is segmented as one
long string. When the input is many short strings segmented in parallel,
\code{jiebaRS::segment()} reaches about \strong{7x to 12x speedup} over \code{jiebaR}.

For very long texts, splitting into about \strong{32 to 128 chunks} before
segmentation is recommended for good throughput.

For multiple input strings, the argument \code{batch} controls how the
per-string token vectors are aggregated:
\itemize{
\item \code{"list"}: one character vector per input string.
\item \code{"data.frame"}: a data frame with \code{doc_id} and \code{word} columns.
\item \code{"flatten"}: all token vectors concatenated into one character vector.
}

When \code{batch} is omitted, \code{jiebaRS} returns list output for multi-string
input.

The \code{mod} argument from \code{jiebaR::segment()} is retained only as a deprecated
compatibility placeholder. In \code{jiebaRS}, segmentation behavior should be
controlled by the worker type itself (for example, \code{worker(type = "mix")} or
\code{worker(type = "query")}), not by mutating behavior at call time. When \code{mod}
is supplied, \code{jiebaRS} warns and ignores it.
}
\examples{
seg <- worker()
text1 <- "\u5357\u4eac\u5e02\u957f\u6c5f\u5927\u6865"
text2 <- "\u8fd9\u662f\u4e00\u4e2a\u6d4b\u8bd5"
segment(text1, seg)
segment(c(text1, text2), seg, batch = "list")
segment(c(text1, text2), seg, batch = "data.frame")
}
