Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 0.6
    • Component/s: Math

      Description

      Convert ARFF to Vector. See http://www.cs.waikato.ac.nz/~ml/weka/arff.html

      Create a VectorIterable implementation for ARFF.

      1. MAHOUT-155.patch
        2 kB
        Joe Prasanna Kumar
      2. MAHOUT-155-DateTestAndFix.patch
        26 kB
        Joe Prasanna Kumar
      3. MAHOUT-155-DateTestAndFix.patch
        27 kB
        Joe Prasanna Kumar
      4. MAHOUT-155-DateTestAndLabelFix.patch
        26 kB
        Joe Prasanna Kumar

        Issue Links

          Activity

          Hide
          Steve Rowe added a comment -

          I think that the most current description of this format is on the WEKA wiki, but there's a problem: WEKA switched their wiki to SF.net's Wikispaces platform at the end of last year, but then in July, SF decided to dump support for Wikispaces, and WEKA's SF.net wiki is no longer accessible.

          Google's cache still has the SF.net wiki pages, though. Here's the developer version of the ARFF format wiki page: http://74.125.47.132/search?q=cache:C2fRvODUfCAJ:weka.wiki.sourceforge.net/ARFF%2B%28developer%2Bversion%29+arff+site:sourceforge.net+developer+version&cd=1&hl=en&ct=clnk&gl=us&client=firefox-a

          Down at the bottom of the above wiki page, there's a link to the ANTLR grammar for ARFF that I mentioned on the Mahout list last year.

          Show
          Steve Rowe added a comment - I think that the most current description of this format is on the WEKA wiki, but there's a problem: WEKA switched their wiki to SF.net's Wikispaces platform at the end of last year, but then in July, SF decided to dump support for Wikispaces, and WEKA's SF.net wiki is no longer accessible. Google's cache still has the SF.net wiki pages, though. Here's the developer version of the ARFF format wiki page: http://74.125.47.132/search?q=cache:C2fRvODUfCAJ:weka.wiki.sourceforge.net/ARFF%2B%28developer%2Bversion%29+arff+site:sourceforge.net+developer+version&cd=1&hl=en&ct=clnk&gl=us&client=firefox-a Down at the bottom of the above wiki page, there's a link to the ANTLR grammar for ARFF that I mentioned on the Mahout list last year.
          Hide
          Grant Ingersoll added a comment -

          Committed some interim work, but still needs to handle nominals across files in a directory and needs to output the mappings, etc.

          Show
          Grant Ingersoll added a comment - Committed some interim work, but still needs to handle nominals across files in a directory and needs to output the mappings, etc.
          Hide
          Sean Owen added a comment -

          Is this one still live?

          Show
          Sean Owen added a comment - Is this one still live?
          Hide
          Steve Rowe added a comment -

          Looks like the WEKA wiki has been moved yet again - here's a link to the current wiki page for ARFF:

          http://weka.wikispaces.com/ARFF

          Show
          Steve Rowe added a comment - Looks like the WEKA wiki has been moved yet again - here's a link to the current wiki page for ARFF: http://weka.wikispaces.com/ARFF
          Hide
          Ted Dunning added a comment -

          This would be a great small project for a student. I don't think it is critical for 0.4

          Show
          Ted Dunning added a comment - This would be a great small project for a student. I don't think it is critical for 0.4
          Hide
          Sean Owen added a comment -

          This looks stalled. It's a reasonable idea but seems like a mini-project for mahout-utils. Mapping all these attribute types meaningfully to a Vector is cool but needs to be done right. Is there a use case here – a system besides Weka that produces ARFF, or common data sets out there in ARFF format?

          Show
          Sean Owen added a comment - This looks stalled. It's a reasonable idea but seems like a mini-project for mahout-utils. Mapping all these attribute types meaningfully to a Vector is cool but needs to be done right. Is there a use case here – a system besides Weka that produces ARFF, or common data sets out there in ARFF format?
          Hide
          Sean Owen added a comment -

          Seems to have died

          Show
          Sean Owen added a comment - Seems to have died
          Hide
          Grant Ingersoll added a comment -

          Sean, just b/c something isn't active doesn't mean it has to be marked as Won't Fix. We can just put the version number as unset. The primary motivation for this one is that Weka is pretty broadly used and it would be good to be able to ingest Weka input docs into Mahout.

          Show
          Grant Ingersoll added a comment - Sean, just b/c something isn't active doesn't mean it has to be marked as Won't Fix. We can just put the version number as unset. The primary motivation for this one is that Weka is pretty broadly used and it would be good to be able to ingest Weka input docs into Mahout.
          Hide
          Sean Owen added a comment -

          "Later" is probably a better label, yes. I don't think anyone objects to implementing this.

          I do think it's worth reflecting reality in JIRA – if nobody has touched it in 17 months, it's not only not planned for 0.5 but not something that, apparently, anyone plans to implement at all.

          This makes JIRA a more reliable reference for newcomers about what is realistically on anybody's radar to work on. (All issues can always be searched, should anyone wonder if anyone thought about ARFF.) I also think closing issues after a large degree of inactivity calls attention to the problem of issue rot (not really this one – it's just an improvement with no patch) and whether we shouldn't pay more attention to bugs and issues with patches ready. It risks discouraging contributors and future committers; this sort of exercise is the "messenger" of this situation.

          Show
          Sean Owen added a comment - "Later" is probably a better label, yes. I don't think anyone objects to implementing this. I do think it's worth reflecting reality in JIRA – if nobody has touched it in 17 months, it's not only not planned for 0.5 but not something that, apparently, anyone plans to implement at all. This makes JIRA a more reliable reference for newcomers about what is realistically on anybody's radar to work on. (All issues can always be searched, should anyone wonder if anyone thought about ARFF.) I also think closing issues after a large degree of inactivity calls attention to the problem of issue rot (not really this one – it's just an improvement with no patch) and whether we shouldn't pay more attention to bugs and issues with patches ready. It risks discouraging contributors and future committers; this sort of exercise is the "messenger" of this situation.
          Hide
          Sean Owen added a comment -

          Coincidentally – I was applying another patch and noticed the class ARFFVectorIterable, which effectively does this conversion. So... was this actually implemented? well, that's good.

          Show
          Sean Owen added a comment - Coincidentally – I was applying another patch and noticed the class ARFFVectorIterable, which effectively does this conversion. So... was this actually implemented? well, that's good.
          Hide
          Grant Ingersoll added a comment -

          It is in the code (since 0.3) as a baseline (see comments above), but there is still some support needed, which is why I left it open.

          Show
          Grant Ingersoll added a comment - It is in the code (since 0.3) as a baseline (see comments above), but there is still some support needed, which is why I left it open.
          Hide
          Grant Ingersoll added a comment -

          I'd like to see full ARFF support

          Show
          Grant Ingersoll added a comment - I'd like to see full ARFF support
          Hide
          Sean Owen added a comment -

          Grant are you tagging this for GSoC? Sounds like a fine project. It would be great to get you back in action too with a patch. This has been open a long time and if it's useful would be great to get it done.

          Show
          Sean Owen added a comment - Grant are you tagging this for GSoC? Sounds like a fine project. It would be great to get you back in action too with a patch. This has been open a long time and if it's useful would be great to get it done.
          Hide
          Grant Ingersoll added a comment -

          Yep, I added a task that is designed to bring more content into Mahout, so this should become a sub-task of that one.

          Show
          Grant Ingersoll added a comment - Yep, I added a task that is designed to bring more content into Mahout, so this should become a sub-task of that one.
          Hide
          Joe Prasanna Kumar added a comment -

          Problem:
          Nominal attributes in ARFF format are not getting completely converted to vector format. When the nominal attribute is mapped to a value of 0, it is not getting reflected in the vector. For example consider the below bank.ARFF file from WEKA site

          @relation bank

          @attribute age numeric
          @attribute sex {MALE,FEMALE}
          @attribute region {INNER_CITY,RURAL,TOWN,SUBURBAN}
          @attribute income numeric
          @attribute married {YES,NO}
          @attribute children {YES,NO}
          @attribute car {YES,NO}
          @attribute mortgage {YES,NO}
          @attribute pep {YES,NO}

          @data

          40,MALE,TOWN,30085.1,YES,YES,YES,YES,NO

          The nominal mappings for the above arff file is
          {sex=

          {FEMALE=1, MALE=0}

          , region=

          {INNER_CITY=0, TOWN=2, RURAL=1, SUBURBAN=3}

          , children=

          {YES=0, NO=1}, married={YES=0, NO=1}

          ,car=

          {YES=0, NO=1}, mortgage={YES=0, NO=1}

          , pep={YES=0, NO=1}}
          When this arff gets converted to vector format, it outputs
          {0:40.0,2:2.0,3:30085.1,8:1.0}
          Because the attribute married assigns 0 to YES and 1 to NO, this attribute (attribute # 5) doesn't show up in the vector

          Issue:
          When I try to convert a nominal attribute in ARFF format to vector format, ARFFIterator by default creates a Dense vector. Since the nominal attribute (here itz married) has value 0, the dense vector ignores this attribute.

          Solution:
          1. In ARFFVectorIterable, when we add the nominal attributes to the ARFFModel, we'll start the class values from 1 instead of 0. This will fix the issue.
          So in the above bank.ARFF, the nominal mappings would be
          {sex=

          {FEMALE=2, MALE=1}

          , region=

          {INNER_CITY=1, TOWN=3, RURAL=2, SUBURBAN=4}

          , children=

          {YES=1, NO=2}, married={YES=1, NO=2}

          ,car=

          {YES=1, NO=2}, mortgage={YES=1, NO=2}

          , pep=

          {YES=1, NO=2}

          }
          and the output of the vector is {0:40.0,1:1.0,2:3.0,3:30085.1,4:1.0,5:1.0,6:1.0,7:1.0,8:2.0}
          If this issue and solution looks right, I can upload a patch with the fix.
          Please let me know your thoughts.
          Joe.

          Show
          Joe Prasanna Kumar added a comment - Problem: Nominal attributes in ARFF format are not getting completely converted to vector format. When the nominal attribute is mapped to a value of 0, it is not getting reflected in the vector. For example consider the below bank.ARFF file from WEKA site @relation bank @attribute age numeric @attribute sex {MALE,FEMALE} @attribute region {INNER_CITY,RURAL,TOWN,SUBURBAN} @attribute income numeric @attribute married {YES,NO} @attribute children {YES,NO} @attribute car {YES,NO} @attribute mortgage {YES,NO} @attribute pep {YES,NO} @data 40,MALE,TOWN,30085.1,YES,YES,YES,YES,NO The nominal mappings for the above arff file is {sex= {FEMALE=1, MALE=0} , region= {INNER_CITY=0, TOWN=2, RURAL=1, SUBURBAN=3} , children= {YES=0, NO=1}, married={YES=0, NO=1} ,car= {YES=0, NO=1}, mortgage={YES=0, NO=1} , pep={YES=0, NO=1}} When this arff gets converted to vector format, it outputs {0:40.0,2:2.0,3:30085.1,8:1.0} Because the attribute married assigns 0 to YES and 1 to NO, this attribute (attribute # 5) doesn't show up in the vector Issue: When I try to convert a nominal attribute in ARFF format to vector format, ARFFIterator by default creates a Dense vector. Since the nominal attribute (here itz married) has value 0, the dense vector ignores this attribute. Solution: 1. In ARFFVectorIterable, when we add the nominal attributes to the ARFFModel, we'll start the class values from 1 instead of 0. This will fix the issue. So in the above bank.ARFF, the nominal mappings would be {sex= {FEMALE=2, MALE=1} , region= {INNER_CITY=1, TOWN=3, RURAL=2, SUBURBAN=4} , children= {YES=1, NO=2}, married={YES=1, NO=2} ,car= {YES=1, NO=2}, mortgage={YES=1, NO=2} , pep= {YES=1, NO=2} } and the output of the vector is {0:40.0,1:1.0,2:3.0,3:30085.1,4:1.0,5:1.0,6:1.0,7:1.0,8:2.0} If this issue and solution looks right, I can upload a patch with the fix. Please let me know your thoughts. Joe.
          Hide
          Joe Prasanna Kumar added a comment -

          Any thoughts on the above anyone ?
          ARFFVectorIterableTest is not checking for the content in the vector that is being produced from the ARFFModel but just the size. I'll create a patch to fix the test case as well. It shud check and make sure the vectors have the proper data in them as well.

          Show
          Joe Prasanna Kumar added a comment - Any thoughts on the above anyone ? ARFFVectorIterableTest is not checking for the content in the vector that is being produced from the ARFFModel but just the size. I'll create a patch to fix the test case as well. It shud check and make sure the vectors have the proper data in them as well.
          Hide
          Grant Ingersoll added a comment -

          Hey Joe,

          Since these are categorical values, I suspect it should not be a problem. A patch would be great.

          Show
          Grant Ingersoll added a comment - Hey Joe, Since these are categorical values, I suspect it should not be a problem. A patch would be great.
          Hide
          Joe Prasanna Kumar added a comment -

          Grant, Thanks for ur feedback.
          After I fix the test case, I'll upload a patch.

          Also I was wondering about the scope of this issue. you had earlier mentioned about these nominal attribs and its mapping. I guess this patch will fix it. I cudnt quickly find one but is there any other problem that you see with the ARFF -> Vector conversion functionality.

          Show
          Joe Prasanna Kumar added a comment - Grant, Thanks for ur feedback. After I fix the test case, I'll upload a patch. Also I was wondering about the scope of this issue. you had earlier mentioned about these nominal attribs and its mapping. I guess this patch will fix it. I cudnt quickly find one but is there any other problem that you see with the ARFF -> Vector conversion functionality.
          Hide
          Joe Prasanna Kumar added a comment -

          1. fixed ARFFVectorIterable to handle nominal attributes
          2. ARFFVectorIterableTest to validate the actual data that is being loaded into the vector from arff

          Show
          Joe Prasanna Kumar added a comment - 1. fixed ARFFVectorIterable to handle nominal attributes 2. ARFFVectorIterableTest to validate the actual data that is being loaded into the vector from arff
          Hide
          Sean Owen added a comment -

          Committed, with a small change to spilt out your test into a separate test method. This doesn't address the original issue in this JIRA right, just a sidebar?

          Show
          Sean Owen added a comment - Committed, with a small change to spilt out your test into a separate test method. This doesn't address the original issue in this JIRA right, just a sidebar?
          Hide
          Hudson added a comment -

          Integrated in Mahout-Quality #1134 (See https://builds.apache.org/job/Mahout-Quality/1134/)
          MAHOUT-155 Joe's fix for nominal attributes

          srowen : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1196494
          Files :

          • /mahout/trunk/integration/src/main/java/org/apache/mahout/utils/vectors/arff/ARFFVectorIterable.java
          • /mahout/trunk/integration/src/test/java/org/apache/mahout/utils/vectors/arff/ARFFVectorIterableTest.java
          Show
          Hudson added a comment - Integrated in Mahout-Quality #1134 (See https://builds.apache.org/job/Mahout-Quality/1134/ ) MAHOUT-155 Joe's fix for nominal attributes srowen : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1196494 Files : /mahout/trunk/integration/src/main/java/org/apache/mahout/utils/vectors/arff/ARFFVectorIterable.java /mahout/trunk/integration/src/test/java/org/apache/mahout/utils/vectors/arff/ARFFVectorIterableTest.java
          Hide
          Joe Prasanna Kumar added a comment -

          Sean,

          I modified the existing test case method because it should consider testing the actual data and not just the size of the maps in the model. If the test case had done this, then the issue with nominal attribs would have been uncovered earlier.

          Also I am not just testing the date datatype but also a nominal attribute (in this case bar). So having this method name as testDate should not mislead anyone.

          regards
          Joe.

          Show
          Joe Prasanna Kumar added a comment - Sean, I modified the existing test case method because it should consider testing the actual data and not just the size of the maps in the model. If the test case had done this, then the issue with nominal attribs would have been uncovered earlier. Also I am not just testing the date datatype but also a nominal attribute (in this case bar). So having this method name as testDate should not mislead anyone. regards Joe.
          Hide
          Joe Prasanna Kumar added a comment -

          In ARFFVectorIterable, I see 2 TODO's
          1. TODO: create a map so we know which
          This has already been taken care of in MapBackedARFFModel.processString. The Map<String,Long> words in MapBackedARFFModel contains a mapping of all the values in a String attribute.
          2. TODO: DateFormatter map
          MapBackedARFFModel.addDateFormat(labelNumInt, format) is already setting the dateMap in the model class. Is this what we are looking for ?
          Please let me know if there is any other open issue / item for this task.

          reg
          Joe.

          Show
          Joe Prasanna Kumar added a comment - In ARFFVectorIterable, I see 2 TODO's 1. TODO: create a map so we know which This has already been taken care of in MapBackedARFFModel.processString. The Map<String,Long> words in MapBackedARFFModel contains a mapping of all the values in a String attribute. 2. TODO: DateFormatter map MapBackedARFFModel.addDateFormat(labelNumInt, format) is already setting the dateMap in the model class. Is this what we are looking for ? Please let me know if there is any other open issue / item for this task. reg Joe.
          Hide
          Grant Ingersoll added a comment -

          Joe,

          1. TODO: create a map so we know which

          I removed this one.

          2. TODO: DateFormatter map

          I think the TODO here is about handling other kind of date formatting. If I recall, I'm not sure ARFF locks down dates to be of only 1 format or not. If not, then ideally we would be able to try different parsing approaches. It sounds like you know more about ARFF than me, so what do you think?

          Show
          Grant Ingersoll added a comment - Joe, 1. TODO: create a map so we know which I removed this one. 2. TODO: DateFormatter map I think the TODO here is about handling other kind of date formatting. If I recall, I'm not sure ARFF locks down dates to be of only 1 format or not. If not, then ideally we would be able to try different parsing approaches. It sounds like you know more about ARFF than me, so what do you think?
          Hide
          Hudson added a comment -

          Integrated in Mahout-Quality #1142 (See https://builds.apache.org/job/Mahout-Quality/1142/)
          MAHOUT-155: remove a todo comment

          gsingers : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1197089
          Files :

          • /mahout/trunk/integration/src/main/java/org/apache/mahout/utils/vectors/arff/ARFFVectorIterable.java
          Show
          Hudson added a comment - Integrated in Mahout-Quality #1142 (See https://builds.apache.org/job/Mahout-Quality/1142/ ) MAHOUT-155 : remove a todo comment gsingers : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1197089 Files : /mahout/trunk/integration/src/main/java/org/apache/mahout/utils/vectors/arff/ARFFVectorIterable.java
          Hide
          Joe Prasanna Kumar added a comment -

          Grant,

          You are right. ARFF doesnt lock down date formats. The format of a date is an optional parameter to the Date attribute. If no format is provided, it takes the default "yyyy-MM-dd'T'HH:mm:ss" format.
          We are currently checking if a format has been specified for a date attribute and using that to create a DateFormat in ARFFVectorIterable. If not, we are using "yyyy-MM-dd'T'HH:mm:ss" as the default format. So we are handling different date formats. Infact the Testcase checks for date data with "yyyy-MM-dd" format.
          I am thinking of adding few more date format related test case just so we make sure. I'll submit a patch for this during weekend.

          reg,
          Joe.

          Show
          Joe Prasanna Kumar added a comment - Grant, You are right. ARFF doesnt lock down date formats. The format of a date is an optional parameter to the Date attribute. If no format is provided, it takes the default "yyyy-MM-dd'T'HH:mm:ss" format. We are currently checking if a format has been specified for a date attribute and using that to create a DateFormat in ARFFVectorIterable. If not, we are using "yyyy-MM-dd'T'HH:mm:ss" as the default format. So we are handling different date formats. Infact the Testcase checks for date data with "yyyy-MM-dd" format. I am thinking of adding few more date format related test case just so we make sure. I'll submit a patch for this during weekend. reg, Joe.
          Hide
          Joe Prasanna Kumar added a comment -

          After adding few more test data related to date format, I encountered some interesting issues.

          1. When the name of the attribute starts with any of the data types like say "dateOfFirstPurchase" then the Iterator was considering this as date type and tries to create a date out of "OfFirstPurchase". I've modified the ARFFVectorIterable and ARFFType to fix this.

          2. If there was a commma in a date / String data, then it was considered as a data on its own. For eg, "0:08 PM, PDT" was treated as 2 strings "0:08 PM" as one and "PDT" as the second. In ARFFIterator, I've added modified COMMA_PATTERN to be ",(?=([^\"]\"[^\"]\")[^\"]$)" This does a split on the comma only if that comma has zero, or an even number of quotes in ahead of it. Credit for this regex pattern goes to an answer in stackoverflow.

          I have modified the test case for few more date formats and they all seem to work now.
          The patch has been updated in this task. After formatting the code using the template available in https://cwiki.apache.org/MAHOUT/how-to-contribute.data/Mahout-Eclipse-Codeformatter.xml , the diff seems to be quite a lot.

          Please test with this patch and if it all looks good maybe we can close this issue.

          Joe.

          Show
          Joe Prasanna Kumar added a comment - After adding few more test data related to date format, I encountered some interesting issues. 1. When the name of the attribute starts with any of the data types like say "dateOfFirstPurchase" then the Iterator was considering this as date type and tries to create a date out of "OfFirstPurchase". I've modified the ARFFVectorIterable and ARFFType to fix this. 2. If there was a commma in a date / String data, then it was considered as a data on its own. For eg, "0:08 PM, PDT" was treated as 2 strings "0:08 PM" as one and "PDT" as the second. In ARFFIterator, I've added modified COMMA_PATTERN to be ",(?=( [^\"] \" [^\"] \") [^\"] $)" This does a split on the comma only if that comma has zero, or an even number of quotes in ahead of it. Credit for this regex pattern goes to an answer in stackoverflow. I have modified the test case for few more date formats and they all seem to work now. The patch has been updated in this task. After formatting the code using the template available in https://cwiki.apache.org/MAHOUT/how-to-contribute.data/Mahout-Eclipse-Codeformatter.xml , the diff seems to be quite a lot. Please test with this patch and if it all looks good maybe we can close this issue. Joe.
          Hide
          Joe Prasanna Kumar added a comment -

          More date formats in the test case and few more fixes

          Show
          Joe Prasanna Kumar added a comment - More date formats in the test case and few more fixes
          Hide
          Joe Prasanna Kumar added a comment -

          This patch doesnt have some of the debug logs that is present in the previous one

          Show
          Joe Prasanna Kumar added a comment - This patch doesnt have some of the debug logs that is present in the previous one
          Hide
          Joe Prasanna Kumar added a comment -

          no logs in the latest patch

          Show
          Joe Prasanna Kumar added a comment - no logs in the latest patch
          Hide
          Joe Prasanna Kumar added a comment -

          While testing from the command line, the labels were not getting written to the file provided through the -t option. I have modified the Driver code to write the label bindings to the file. If there are more than 1 arff file in the directory then their label bindings would be appended to the file provided through the -t option.

          So the file would look like
          Relation Timestampslabel bindings
          timestamp 0

          Relation irislabel bindings
          sepallength 0
          sepalwidth 1
          petalwidth 3
          petallength 2

          Relation iris-testlabel bindings
          class 4
          sepallength 0
          sepalwidth 1
          petalwidth 3
          petallength 2

          Show
          Joe Prasanna Kumar added a comment - While testing from the command line, the labels were not getting written to the file provided through the -t option. I have modified the Driver code to write the label bindings to the file. If there are more than 1 arff file in the directory then their label bindings would be appended to the file provided through the -t option. So the file would look like Relation Timestampslabel bindings timestamp 0 Relation irislabel bindings sepallength 0 sepalwidth 1 petalwidth 3 petallength 2 Relation iris-testlabel bindings class 4 sepallength 0 sepalwidth 1 petalwidth 3 petallength 2
          Hide
          Joe Prasanna Kumar added a comment -

          This is the latest patch which contains the fix with the Date Test and also has fix for writing the label bindings to file

          Show
          Joe Prasanna Kumar added a comment - This is the latest patch which contains the fix with the Date Test and also has fix for writing the label bindings to file
          Hide
          Hudson added a comment -

          Integrated in Mahout-Quality #1157 (See https://builds.apache.org/job/Mahout-Quality/1157/)
          MAHOUT-155 DateTestAndLabelFix

          srowen : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1198330
          Files :

          • /mahout/trunk/integration/src/main/java/org/apache/mahout/utils/vectors/arff/ARFFIterator.java
          • /mahout/trunk/integration/src/main/java/org/apache/mahout/utils/vectors/arff/ARFFType.java
          • /mahout/trunk/integration/src/main/java/org/apache/mahout/utils/vectors/arff/ARFFVectorIterable.java
          • /mahout/trunk/integration/src/main/java/org/apache/mahout/utils/vectors/arff/Driver.java
          • /mahout/trunk/integration/src/test/java/org/apache/mahout/utils/vectors/arff/ARFFVectorIterableTest.java
          Show
          Hudson added a comment - Integrated in Mahout-Quality #1157 (See https://builds.apache.org/job/Mahout-Quality/1157/ ) MAHOUT-155 DateTestAndLabelFix srowen : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1198330 Files : /mahout/trunk/integration/src/main/java/org/apache/mahout/utils/vectors/arff/ARFFIterator.java /mahout/trunk/integration/src/main/java/org/apache/mahout/utils/vectors/arff/ARFFType.java /mahout/trunk/integration/src/main/java/org/apache/mahout/utils/vectors/arff/ARFFVectorIterable.java /mahout/trunk/integration/src/main/java/org/apache/mahout/utils/vectors/arff/Driver.java /mahout/trunk/integration/src/test/java/org/apache/mahout/utils/vectors/arff/ARFFVectorIterableTest.java

            People

            • Assignee:
              Sean Owen
              Reporter:
              Grant Ingersoll
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development