Github user sethah commented on a diff in the pull request:
https://github.com/apache/spark/pull/13796#discussion_r75006012
--- Diff:
mllib/src/main/scala/org/apache/spark/ml/classification/LogisticRegression.scala
---
@@ -952,13 +963,160 @@ private class LogisticAggregator(
val bcFeaturesStd: Broadcast[Array[Double]],
private val numFeatures: Int,
numClasses: Int,
- fitIntercept: Boolean) extends Serializable {
+ fitIntercept: Boolean,
+ multinomial: Boolean) extends Serializable with Logging {
+
+ private val numFeaturesPlusIntercept = if (fitIntercept) numFeatures + 1
else numFeatures
+ private val coefficientSize = bcCoefficients.value.size
+ if (multinomial) {
+ require(numClasses == coefficientSize / numFeaturesPlusIntercept,
s"The number of " +
+ s"coefficients should be ${numClasses * numFeaturesPlusIntercept}
but was $coefficientSize")
+ } else {
+ require(coefficientSize == numFeaturesPlusIntercept, s"Expected
$numFeaturesPlusIntercept " +
+ s"coefficients but got $coefficientSize")
+ require(numClasses <= 2, s"Binary logistic aggregator requires
numClasses in {1, 2}" +
+ s" but found $numClasses.")
+ }
private var weightSum = 0.0
private var lossSum = 0.0
- private val gradientSumArray =
- Array.ofDim[Double](if (fitIntercept) numFeatures + 1 else numFeatures)
+ private val totalCoefficientLength = {
+ val cols = if (fitIntercept) numFeatures + 1 else numFeatures
+ val rows = if (multinomial) numClasses else 1
+ rows * cols
+ }
+
+ private val gradientSumArray =
Array.ofDim[Double](totalCoefficientLength)
+
+ if (multinomial && numClasses < 2) {
+ logInfo(s"Multinomial logistic regression for binary classification
yields separate " +
+ s"coefficients for positive and negative classes. When no
regularization is applied, the" +
+ s"result will be effectively the same as binary logistic regression.
When regularization" +
+ s"is applied, multinomial loss will produce a result different from
binary loss.")
+ }
+
+ /** Update gradient and loss using binary loss function. */
+ private def binaryUpdateInPlace(
+ features: Vector,
+ weight: Double,
+ label: Double,
+ coefficients: Array[Double],
+ gradient: Array[Double],
+ featuresStd: Array[Double],
+ numFeaturesPlusIntercept: Int): Unit = {
+ val margin = - {
+ var sum = 0.0
+ features.foreachActive { (index, value) =>
+ if (featuresStd(index) != 0.0 && value != 0.0) {
+ sum += coefficients(index) * value / featuresStd(index)
+ }
+ }
+ sum + {
+ if (fitIntercept) coefficients(numFeaturesPlusIntercept - 1) else
0.0
+ }
+ }
+
+ val multiplier = weight * (1.0 / (1.0 + math.exp(margin)) - label)
+
+ features.foreachActive { (index, value) =>
+ if (featuresStd(index) != 0.0 && value != 0.0) {
+ gradient(index) += multiplier * value / featuresStd(index)
+ }
+ }
+
+ if (fitIntercept) {
+ gradient(numFeaturesPlusIntercept - 1) += multiplier
+ }
+
+ if (label > 0) {
+ // The following is equivalent to log(1 + exp(margin)) but more
numerically stable.
+ lossSum += weight * MLUtils.log1pExp(margin)
+ } else {
+ lossSum += weight * (MLUtils.log1pExp(margin) - margin)
+ }
+ }
+
+ /** Update gradient and loss using multinomial (softmax) loss function.
*/
+ private def multinomialUpdateInPlace(
+ features: Vector,
+ weight: Double,
+ label: Double,
+ coefficients: Array[Double],
+ gradient: Array[Double],
+ featuresStd: Array[Double],
+ numFeaturesPlusIntercept: Int): Unit = {
+ // TODO: use level 2 BLAS operations
+ /*
+ Note: this can still be used when numClasses = 2 for binary
+ logistic regression without pivoting.
+ */
+
+ // marginOfLabel is margins(label) in the formula
+ var marginOfLabel = 0.0
+ var maxMargin = Double.NegativeInfinity
+
+ val margins = Array.tabulate(numClasses) { i =>
+ var margin = 0.0
+ features.foreachActive { (index, value) =>
--- End diff --
If I'm interpreting your suggestion correctly, then we will indeed avoid
the extra divisions, but we lose the advantage of sequential memory access into
the coefficients array. This could cause problems when the coefficients array
is too big to fit into the CPU cache. I'd guess in some scenarios, these random
memory lookups could outweigh the benefit of avoiding the divisions. Thoughts?
I'm ok changing it in this PR, but I don't think it's a bad idea to leave
it for a follow up, when we can run extensive testing and possibly use BLAS ops
instead of loops. Let me know what you think.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
