【问题标题】:Weka attribute date doesn't workWeka 属性日期不起作用
【发布时间】:2015-09-03 08:50:38
【问题描述】:

我创建了一个带有日期属性的 .arff 文件:

@attribute 数据日期“yyyy-MM-dd”

还有其他属性。

数据的一个例子是:

@数据

"2014-01-02",11.27,11.44,11.03,11.18,11.07,11.07,11.12,9419,2003400,2240946600,1

然而,Weka 似乎无法识别日期属性。那是因为当我查看图形时(来自日期属性),轴 x 的边距(对应于日期)从 1388628000000 开始,到 1419904800000 结束,这根本没有意义。

当我尝试分类时,分类器(我用 J48 树和 SVM 测试)只接受一个类并尊重整个测试集。显然是有问题,我相信这是因为日期属性。

关于如何解决这个问题的任何想法?

【问题讨论】:

    标签: date weka


    【解决方案1】:

    通过一些研究,我独立发现了与您的问题相关的内容。看看对你有没有帮助。

    https://stackoverflow.com/questions/32738822/weka-doesnt-differentiate-between-date-and-numeric-attributes-features

    最严重的问题是一些 Weka 算法(非常理想)根本不承认日期属性。

    编辑:

    当比较两个日期类型的属性与数字类型时,Weka 不会区分它们,也就是说,日期属性将其类型返回为数字,因此,当这不应该是正确答案时,它们具有重合类型。如果您检查日期属性,则出于某些目的,它是从 Weka 视为日期的,但在内部,Weka 将日期视为一个数字(如果我是对的话,距离参考日期的毫秒数)。问题是从用户的角度来看,不是同类型的属性,应该是指向的。

    我一直在考虑将日期转换为数字(可能通过过滤器),但日期固有的信息能力将毫无意义。

    另一种方法涉及将日期属性转换为几个数字+名义属性,例如:年、月、日、一年中的星期、星期几。

    【讨论】:

    • 上面的答案涉及到这一点,但只是为了让其他读者清楚:OP(原始海报)提供的x轴上的数字实际上是有意义的;原始日期已转换为毫秒。使用毫秒至今的转换站点(如currentmillis.com),我们看到:1388628000000 --> Thu Jan 02 2014 02:00:00, and 1419904800000 --> Tue Dec 30 2014 02:00:00.
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2014-07-08
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2016-10-24
    • 2018-11-08
    • 1970-01-01
    相关资源
    最近更新 更多