Mailing-List: contact issues-help@spark.apache.org; run by ezmlm
Precedence: bulk
Date: Wed, 30 Sep 2015 01:20:04 +0000 (UTC)
From: "Seth Hendrickson (JIRA)" <jira@apache.org>
To: issues@spark.apache.org
Message-ID: <JIRA.12896005.1443071226000.109015.1443576004389@Atlassian.JIRA>
In-Reply-To: <JIRA.12896005.1443071226000@Atlassian.JIRA>
References: <JIRA.12896005.1443071226000@Atlassian.JIRA>
 <JIRA.12896005.1443071226734@arcas>
Subject: [jira] [Commented] (SPARK-10788) Decision Tree duplicates bins for
 unordered categorical features
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/SPARK-10788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14936219#comment-14936219 ] 

Seth Hendrickson commented on SPARK-10788:
------------------------------------------

[~josephkb] I'm interested in working on this issue, but I'm not sure I see the problem. Looking through ML RandomForest implementation I found that {{numBins}} for unordered features is {{def numUnorderedBins(arity: Int): Int = 2 * ((1 << arity - 1) - 1)}} and that {{numSplits}} is just {{numBins / 2}}. 

In the 3 category example: {{numBins = 2 * (( 1 << (3 - 1)) - 1) = 6}} and so the number of splits considered is {{numSplits = 6 / 2 = 3}}. This seems to be the same as in the MLlib implementation. Perhaps I am overlooking something. I'd appreciate any feedback...

> Decision Tree duplicates bins for unordered categorical features
> ----------------------------------------------------------------
>
>                 Key: SPARK-10788
>                 URL: https://issues.apache.org/jira/browse/SPARK-10788
>             Project: Spark
>          Issue Type: Improvement
>          Components: ML
>            Reporter: Joseph K. Bradley
>
> Decision trees in spark.ml (RandomForest.scala) effectively creates a second copy of each split. E.g., if there are 3 categories A, B, C, then we should consider 3 splits:
> * A vs. B, C
> * A, B vs. C
> * A, C vs. B
> Currently, we also consider the 3 flipped splits:
> * B,C vs. A
> * C vs. A, B
> * B vs. A, C
> This means we communicate twice as much data as needed for these features.
> We should eliminate these duplicate splits within the spark.ml implementation since the spark.mllib implementation will be removed before long (and will instead call into spark.ml).


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@spark.apache.org
For additional commands, e-mail: issues-help@spark.apache.org