java协同过滤算法代码

❶ 协同过滤的算法细分

这是最早应用协同过滤系统的设计，主要是解决Xerox公司在Palo Alto的研究中心资讯过载的问题。这个研究中心的员工每天会收到非常多的电子邮件却无从筛选分类，于是研究中心便发展这项实验性的邮件系统来帮助员工解决这项问题。 其运作机制大致如下：
个人决定自己的感兴趣的邮件类型；个人旋即随机发出一项资讯需求，可预测的结果是会收到非常多相关的文件；从这些文件中个人选出至少三笔资料是其认为有用、会想要看的；系统便将之记录起来成为个人邮件系统内的过滤器，从此以后经过过滤的文件会最先送达信箱；以上是协同过滤最早的应用，接下来的里程碑为GroupLens。 这个系统主要是应用在新闻的筛选上，帮助新闻的阅听者过滤其感兴趣的新闻内容，阅听者看过内容后给一个评比的分数，系统会将分数记录起来以备未来参考之用，假设前提是阅听者以前感兴趣的东西在未来也会有兴趣阅听，若阅听者不愿揭露自己的身分也可以匿名进行评分。 和Tapestry不同之处有两点，首先，Tapestry专指一个点（如一个网站内、一个系统内）的过滤机制；GroupLens则是跨点跨系统的新闻过滤机制。再来，Tapestry不会将同一笔资料的评比总和起来；GroupLens会将同一笔资料从不同使用者得到的评比加总。
GroupLens具有以下特点：开放性：所有的新闻阅听者皆可使用，虽然系统委托Better Bit Bureau设计给分的系统，但若有不同的评分机制也适用于GroupLens。方便性：给分并不是一件困难的事情且沟通上非常方便，评分结果容易诠释。规模性：有可能发展成大规模的系统，一旦发展成大规模，储存空间与计算成本问题显得相当棘手。隐密性：如果使用者不想让别人知道他是谁，别人就不会知道。由此可以看出，现今网络各个推荐系统的雏形已然形成，在GroupLens之后还有性质相近的MovieLens，电影推荐系统；Ringo，音乐推荐系统；Video Recommender，影音推荐系统；以及Jster，笑话推荐系统等等。乃至于今日的YouTube、aNobii皆是相似性值得网络推荐平台，较不同的是经过时间推移，网络越来越发达，使用者越来越多，系统也发展得越来越严密。 最着名的电子商务推荐系统应属亚马逊网络书店，顾客选择一本自己感兴趣的书籍，马上会在底下看到一行“Customer Who Bought This Item Also Bought”，亚马逊是在“对同样一本书有兴趣的读者们兴趣在某种程度上相近”的假设前提下提供这样的推荐，此举也成为亚马逊网络书店为人所津津乐道的一项服务，各网络书店也跟进做这样的推荐服务如台湾的博客来网络书店。 另外一个着名的例子是Facebook的广告，系统根据个人资料、周遭朋友感兴趣的广告等等对个人提供广告推销，也是一项协同过滤重要的里程碑，和前二者Tapestry、GroupLens不同的是在这里虽然商业气息浓厚同时还是带给使用者很大的方便。 以上为三项协同过滤发展上重要的里程碑，从早期单一系统内的邮件、文件过滤，到跨系统的新闻、电影、音乐过滤，乃至于今日横行互联网的电子商务，虽然目的不太相同，但带给使用者的方便是大家都不能否定的。

❷ 协同过滤java用什么实现

众所周知，java在处理数据量比较大的时候，加载到内存必然会导致内存溢出，而在一些数据处理中我们不得不去处理海量数据，在做数据处理中，我们常见的手段是分解，压缩，并行，临时文件等方法;例如，我们要将数据库(不论是什么数据库)的数据导出到一个文件，一般是Excel或文本格式的CSV;对于Excel来讲，对于POI和JXL的接口，你很多时候没有法去控制内存什么时候向磁盘写入，很恶心，而且这些API在内存构造的对象大小将比数据原有的大小要大很多倍数，所以你不得不去拆分Excel，还好，POI开始意识到这个问题，在3.8.4的版本后，开始提供cache的行数，提供了SXSSFWorkbook的接口，可以设置在内存中的行数，不过可惜的是，他当你超过这个行数，每添加一行，它就将相对行数前面的一行写入磁盘(如你设置2000行的话，当你写第20001行的时候，他会将第一行写入磁盘)，其实这个时候他些的临时文件，以至于不消耗内存，不过这样你会发现，刷磁盘的频率会非常高，我们的确不想这样，因为我们想让他达到一个范围一次性将数据刷如磁盘，比如一次刷1M之类的做法，可惜现在还没有这种API，很痛苦，我自己做过测试，通过写小的Excel比使用目前提供刷磁盘的API来写大文件，效率要高一些，而且这样如果访问的人稍微多一些磁盘IO可能会扛不住，因为IO资源是非常有限的，所以还是拆文件才是上策;而当我们写CSV，也就是文本类型的文件，我们很多时候是可以自己控制的，不过你不要用CSV自己提供的API，也是不太可控的，CSV本身就是文本文件，你按照文本格式写入即可被CSV识别出来;如何写入呢？下面来说说。。。在处理数据层面，如从数据库中读取数据，生成本地文件，写代码为了方便，我们未必要1M怎么来处理，这个交给底层的驱动程序去拆分，对于我们的程序来讲我们认为它是连续写即可;我们比如想将一个1000W数据的数据库表，导出到文件;此时，你要么进行分页，oracle当然用三层包装即可，mysql用limit，不过分页每次都会新的查询，而且随着翻页，会越来越慢，其实我们想拿到一个句柄，然后向下游动，编译一部分数据(如10000行)将写文件一次(写文件细节不多说了，这个是最基本的)，需要注意的时候每次buffer的数据，在用outputstream写入的时候，最好flush一下，将缓冲区清空下;接下来，执行一个没有where条件的SQL，会不会将内存撑爆？是的，这个问题我们值得去思考下，通过API发现可以对SQL进行一些操作，例如，通过：PreparedStatementstatement=connection.prepareStatement(sql)，这是默认得到的预编译，还可以通过设置：PreparedStatementstatement=connection.prepareStatement(sql，ResultSet.TYPE_FORWARD_ONLY，ResultSet.CONCUR_READ_ONLY);来设置游标的方式，以至于游标不是将数据直接cache到本地内存，然后通过设置statement.setFetchSize(200);设置游标每次遍历的大小;OK，这个其实我用过，oracle用了和没用没区别，因为oracle的jdbcAPI默认就是不会将数据cache到java的内存中的，而mysql里头设置根本无效，我上面说了一堆废话，呵呵，我只是想说，java提供的标准API也未必有效，很多时候要看厂商的实现机制，还有这个设置是很多网上说有效的，但是这纯属抄袭;对于oracle上面说了不用关心，他本身就不是cache到内存，所以java内存不会导致什么问题，如果是mysql，首先必须使用5以上的版本，然后在连接参数上加上useCursorFetch=true这个参数，至于游标大小可以通过连接参数上加上：defaultFetchSize=1000来设置，例如：jdbc：mysql：//xxx.xxx.xxx.xxx：3306/abc？zeroDateTimeconvertToNull&useCursorFetch=true&defaultFetchSize=1000上次被这个问题纠结了很久(mysql的数据老导致程序内存膨胀，并行2个直接系统就宕了)，还去看了很多源码才发现奇迹竟然在这里，最后经过mysql文档的确认，然后进行测试，并行多个，而且数据量都是500W以上的，都不会导致内存膨胀，GC一切正常，这个问题终于完结了。我们再聊聊其他的，数据拆分和合并，当数据文件多的时候我们想合并，当文件太大想要拆分，合并和拆分的过程也会遇到类似的问题，还好，这个在我们可控制的范围内，如果文件中的数据最终是可以组织的，那么在拆分和合并的时候，此时就不要按照数据逻辑行数来做了，因为行数最终你需要解释数据本身来判定，但是只是做拆分是没有必要的，你需要的是做二进制处理，在这个二进制处理过程，你要注意了，和平时read文件不要使用一样的方式，平时大多对一个文件读取只是用一次read操作，如果对于大文件内存肯定直接挂掉了，不用多说，你此时因该每次读取一个可控范围的数据，read方法提供了重载的offset和length的范围，这个在循环过程中自己可以计算出来，写入大文件和上面一样，不要读取到一定程序就要通过写入流flush到磁盘;其实对于小数据量的处理在现代的NIO技术的中也有用到，例如多个终端同时请求一个大文件下载，例如视频下载吧，在常规的情况下，如果用java的容器来处理，一般会发生两种情况：其一为内存溢出，因为每个请求都要加载一个文件大小的内存甚至于，因为java包装的时候会产生很多其他的内存开销，如果使用二进制会产生得少一些，而且在经过输入输出流的过程中还会经历几次内存拷贝，当然如果有你类似nginx之类的中间件，那么你可以通过send_file模式发送出去，但是如果你要用程序来处理的时候，内存除非你足够大，但是java内存再大也会有GC的时候，如果你内存真的很大，GC的时候死定了，当然这个地方也可以考虑自己通过直接内存的调用和释放来实现，不过要求剩余的物理内存也足够大才行，那么足够大是多大呢？这个不好说，要看文件本身的大小和访问的频率;其二为假如内存足够大，无限制大，那么此时的限制就是线程，传统的IO模型是线程是一个请求一个线程，这个线程从主线程从线程池中分配后，就开始工作，经过你的Context包装、Filter、拦截器、业务代码各个层次和业务逻辑、访问数据库、访问文件、渲染结果等等，其实整个过程线程都是被挂住的，所以这部分资源非常有限，而且如果是大文件操作是属于IO密集型的操作，大量的CPU时间是空余的，方法最直接当然是增加线程数来控制，当然内存足够大也有足够的空间来申请线程池，不过一般来讲一个进程的线程池一般会受到限制也不建议太多的，而在有限的系统资源下，要提高性能，我们开始有了newIO技术，也就是NIO技术，新版的里面又有了AIO技术，NIO只能算是异步IO，但是在中间读写过程仍然是阻塞的(也就是在真正的读写过程，但是不会去关心中途的响应)，还未做到真正的异步IO，在监听connect的时候他是不需要很多线程参与的，有单独的线程去处理，连接也又传统的socket变成了selector，对于不需要进行数据处理的是无需分配线程处理的;而AIO通过了一种所谓的回调注册来完成，当然还需要OS的支持，当会掉的时候会去分配线程，目前还不是很成熟，性能最多和NIO吃平，不过随着技术发展，AIO必然会超越NIO，目前谷歌V8虚拟机引擎所驱动的node.js就是类似的模式，有关这种技术不是本文的说明重点;将上面两者结合起来就是要解决大文件，还要并行度，最土的方法是将文件每次请求的大小降低到一定程度，如8K(这个大小是经过测试后网络传输较为适宜的大小，本地读取文件并不需要这么小)，如果再做深入一些，可以做一定程度的cache，将多个请求的一样的文件，cache在内存或分布式缓存中，你不用将整个文件cache在内存中，将近期使用的cache几秒左右即可，或你可以采用一些热点的算法来配合;类似迅雷下载的断点传送中(不过迅雷的网络协议不太一样)，它在处理下载数据的时候未必是连续的，只要最终能合并即可，在服务器端可以反过来，谁正好需要这块的数据，就给它就可以;才用NIO后，可以支持很大的连接和并发，本地通过NIO做socket连接测试，100个终端同时请求一个线程的服务器，正常的WEB应用是第一个文件没有发送完成，第二个请求要么等待，要么超时，要么直接拒绝得不到连接，改成NIO后此时100个请求都能连接上服务器端，服务端只需要1个线程来处理数据就可以，将很多数据传递给这些连接请求资源，每次读取一部分数据传递出去，不过可以计算的是，在总体长连接传输过程中总体效率并不会提升，只是相对相应和所开销的内存得到量化控制，这就是技术的魅力，也许不要太多的算法，不过你得懂他。类似的数据处理还有很多，有些时候还会将就效率问题，比如在HBase的文件拆分和合并过程中，要不影响线上业务是比较难的事情，很多问题值得我们去研究场景，因为不同的场景有不同的方法去解决，但是大同小异，明白思想和方法，明白内存和体系架构，明白你所面临的是沈阳的场景，只是细节上改变可以带来惊人的效果。

❸ 关于java新闻网站的算法

问:新闻网站，如新浪网站，比如说国际足球频道，每天会有跟新。请问这块在代码设计的地方，是从数据库中读取5条最新的（按照日期）还是说做一个程序由编辑强制置顶?
答:是从数据库中读取5条最新的（按照日期）

问:如果是论坛，需要把点击最高的新闻自动排到前面，这个怎么处理，需要用到servletcontext吗 ?
答:读取点击最高的新闻记录(你想读取几条就几条),然后放到网页上去,就怎么回事.......跟你平时放其他数据没什么区别,都是根据条件取数据而已.

❹ 求基于用户的协同过滤算法matlab代码

什么是推荐算法
推荐算法最早在1992年就提出来了，但是火起来实际上是最近这些年的事情，因为互联网的爆发，有了更大的数据量可以供我们使用，推荐算法才有了很大的用武之地。
最开始，所以我们在网上找资料，都是进yahoo，然后分门别类的点进去，找到你想要的东西，这是一个人工过程，到后来，我们用google，直接搜索自己需要的内容，这些都可以比较精准的找到你想要的东西，但是，如果我自己都不知道自己要找什么肿么办？最典型的例子就是，如果我打开豆瓣找电影，或者我去买说，我实际上不知道我想要买什么或者看什么，这时候推荐系统就可以派上用场了。
推荐算法的条件
推荐算法从92年开始，发展到现在也有20年了，当然，也出了各种各样的推荐算法，但是不管怎么样，都绕不开几个条件，这是推荐的基本条件
根据和你共同喜好的人来给你推荐
根据你喜欢的物品找出和它相似的来给你推荐
根据你给出的关键字来给你推荐，这实际上就退化成搜索算法了
根据上面的几种条件组合起来给你推荐
实际上，现有的条件就这些啦，至于怎么发挥这些条件就是八仙过海各显神通了，这么多年沉淀了一些好的算法，今天这篇文章要讲的基于用户的协同过滤算法就是其中的一个，这也是最早出现的推荐算法，并且发展到今天，基本思想没有什么变化，无非就是在处理速度上，计算相似度的算法上出现了一些差别而已。
基于用户的协同过滤算法
我们先做个词法分析基于用户说明这个算法是以用户为主体的算法，这种以用户为主体的算法比较强调的是社会性的属性，也就是说这类算法更加强调把和你有相似爱好的其他的用户的物品推荐给你，与之对应的是基于物品的推荐算法，这种更加强调把和你你喜欢的物品相似的物品推荐给你。
然后就是协同过滤了，所谓协同就是大家一起帮助你啦，然后后面跟个过滤，就是大家是商量过后才把结果告诉你的，不然信息量太大了。。
所以，综合起来说就是这么一个算法，那些和你有相似爱好的小伙伴们一起来商量一下，然后告诉你什么东西你会喜欢。
算法描述
相似性计算
我们尽量不使用复杂的数学公式，一是怕大家看不懂，难理解，二是我是用mac写的blog,公式不好画，太麻烦了。。
所谓计算相似度，有两个比较经典的算法
Jaccard算法，就是交集除以并集，详细可以看看我这篇文章。
余弦距离相似性算法，这个算法应用很广，一般用来计算向量间的相似度，具体公式大家google一下吧，或者看看这里
各种其他算法，比如欧氏距离算法等等。
不管使用Jaccard还是用余弦算法，本质上需要做的还是求两个向量的相似程度，使用哪种算法完全取决于现实情况。
我们在本文中用的是余弦距离相似性来计算两个用户之间的相似度。
与目标用户最相邻的K个用户
我们知道，在找和你兴趣爱好相似的小伙伴的时候，我们可能可以找到几百个，但是有些是好基友，但有些只是普通朋友，那么一般的，我们会定一个数K，和你最相似的K个小伙伴就是你的好基友了，他们的爱好可能和你的爱好相差不大，让他们来推荐东西给你（比如肥皂）是最好不过了。

❺ 协同过滤算法

用户行为数据在网站上最简单的存在形式就是日志，比如用户在电子商务网站中的网页浏览、购买、点击、评分和评论等活动。 用户行为在个性化推荐系统中一般分两种——显性反馈行为(explicit feedback)和隐性反馈 行为(implicit feedback)。显性反馈行为包括用户明确表示对物品喜好的行为。网站中收集显性反馈的主要方式就是评分和喜欢/不喜欢。隐性反馈行为指的是那些不能明确反应用户喜好 的行为。最具代表性的隐性反馈行为就是页面浏览行为。 按照反馈的明确性分，用户行为数据可以分为显性反馈和隐性反馈，但按照反馈的方向分， 又可以分为正反馈和负反馈。正反馈指用户的行为倾向于指用户喜欢该物品，而负反馈指用户的 行为倾向于指用户不喜欢该物品。在显性反馈中，很容易区分一个用户行为是正反馈还是负反馈， 而在隐性反馈行为中，就相对比较难以确定。

在利用用户行为数据设计推荐算法之前，研究人员首先需要对用户行为数据进行分析，了解 数据中蕴含的一般规律，这样才能对算法的设计起到指导作用。

(1) 用户活跃度和物品流行度

(2) 用户活跃度和物品流行度的关系

一般认为，新用户倾向于浏览热门的物品，因为他 们对网站还不熟悉，只能点击首页的热门物品，而老用户会逐渐开始浏览冷门的物品。如果用横坐标表示用户活跃度，纵坐标表示具有某个活跃度的所有用户评过分的物品的平均流行度。图中曲线呈明显下 降的趋势，这表明用户越活跃，越倾向于浏览冷门的物品。

仅仅基于用户行为数据设计的推荐算法一般称为协同过滤算法。学术界对协同过滤算法进行了深入研究，提出了很多方法，比如基于邻域的方法(neighborhood-based)、隐语义模型 (latent factor model)、基于图的随机游走算法(random walk on graph)等。在这些方法中， 最着名的、在业界得到最广泛应用的算法是基于邻域的方法，而基于邻域的方法主要包含下面两种算法。

基于用户的协同过滤算法 ：这种算法给用户推荐和他兴趣相似的其他用户喜欢的物品

基于物品的协同过滤算法： 这种算法给用户推荐和他之前喜欢的物品相似的物品

基于邻域的算法是推荐系统中最基本的算法，该算法不仅在学术界得到了深入研究，而且在 业界得到了广泛应用。基于邻域的算法分为两大类，一类是基于用户的协同过滤算法，另一类是 基于物品的协同过滤算法。现在我们所说的协同过滤，基本上就就是指基于用户或者是基于物品的协同过滤算法，因此，我们可以说基于邻域的算法即是我们常说的协同过滤算法

(1) 基于用户的协同过滤算法（UserCF）

基于用户的协同过滤算法的基本思想是：在一个在线个性化推荐系统中，当一个用户A需要个性化推荐 时，可以先找到和他有相似兴趣的其他用户，然后把那些用户喜欢的、而用户A没有听说过的物品推荐给A。

Ø 从上面的描述中可以看到，基于用户的协同过滤算法主要包括两个步骤。 第一步：找到和目标用户兴趣相似的用户集合。 第二步： 找到这个集合中的用户喜欢的，且目标用户没有听说过的物品推荐给目标用户。

这里，步骤1的关键是计算两个用户的兴趣相似度，协同过滤算法主要利用行为的相似度计算兴趣的相似度。给定用户u和用户v，令N(u)表示用户u曾经有过正反馈的物品集合，令N(v) 为用户v曾经有过正反馈的物品集合。那么我们可以通过以下方法计算用户的相似度：

基于余弦相似度

(2) 基于物品的协同过滤算法（itemCF）
与UserCF同理
(3) UserCF和itemCF的比 较

首先我们提出一个问题，为什么新闻网站一般使用UserCF，而图书、电商网站一般使用ItemCF呢？ 首先回顾一下UserCF算法和ItemCF算法的推荐原理。UserCF给用户推荐那些和他有共同兴 趣爱好的用户喜欢的物品，而ItemCF给用户推荐那些和他之前喜欢的物品类似的物品。从这个算 法的原理可以看到，UserCF的推荐结果着重于反映和用户兴趣相似的小群体的热点，而ItemCF 的推荐结果着重于维系用户的历史兴趣。换句话说，UserCF的推荐更社会化，反映了用户所在的小型兴趣群体中物品的热门程度，而ItemCF的推荐更加个性化，反映了用户自己的兴趣传承。 在新闻网站中，用户的兴趣不是特别细化，绝大多数用户都喜欢看热门的新闻。个性化新闻推荐更加强调抓住 新闻热点，热门程度和时效性是个性化新闻推荐的重点，而个性化相对于这两点略显次要。因 此，UserCF可以给用户推荐和他有相似爱好的一群其他用户今天都在看的新闻，这样在抓住热 点和时效性的同时，保证了一定程度的个性化。同时，在新闻网站中，物品的更新速度远远快于新用户的加入速度，而且 对于新用户，完全可以给他推荐最热门的新闻，因此UserCF显然是利大于弊。

但是，在图书、电子商务和电影网站，比如亚马逊、豆瓣、Netflix中，ItemCF则能极大地发 挥优势。首先，在这些网站中，用户的兴趣是比较固定和持久的。一个技术人员可能都是在购买 技术方面的书，而且他们对书的热门程度并不是那么敏感，事实上越是资深的技术人员，他们看 的书就越可能不热门。此外，这些系统中的用户大都不太需要流行度来辅助他们判断一个物品的 好坏，而是可以通过自己熟悉领域的知识自己判断物品的质量。因此，这些网站中个性化推荐的 任务是帮助用户发现和他研究领域相关的物品。因此，ItemCF算法成为了这些网站的首选算法。 此外，这些网站的物品更新速度不会特别快，一天一次更新物品相似度矩阵对它们来说不会造成 太大的损失，是可以接受的。同时，从技术上考虑，UserCF需要维护一个用户相似度的矩阵，而ItemCF需要维护一个物品 相似度矩阵。从存储的角度说，如果用户很多，那么维护用户兴趣相似度矩阵需要很大的空间， 同理，如果物品很多，那么维护物品相似度矩阵代价较大

下表是对二者的一个全面的表较：

❻ java,我有一个数据库表userid,bookid,score,用这个表用协同过滤算法找到爱好相似的用户

//皮尔逊相关系数分析
//介于-1到1之间。相关系数越接近与1，说明两个人越相似。
//你先参考下这个虽然里面只有Python的代码：

//我用java去做一下试试

importjava.util.*;

publicclassTest{

publicstaticvoidmain(String[]args){
Map<String,HashMap<String,Double>>cri=newHashMap<String,HashMap<String,Double>>();
//模拟数据库中的数据，实际运用时请灵活变动
getData(cri);
System.out.println(cri.get("Gene").get("LadyintheWater"));
//获得评价值
System.out.println(getSim(cri,"Gene","Lisa"));
}

//模拟数据库中的数据
publicstaticvoidgetData(Map<String,HashMap<String,Double>>cri){
HashMap<String,Double>temp=newHashMap<String,Double>();
temp.put("LadyintheWater",2.5);
temp.put("SnakesonaPlane",3.5);
temp.put("JustMyLuck",3.0);
temp.put("SupermanReturns",3.5);
temp.put("You,MeandDupree",2.5);
temp.put("TheNightListener",3.0);
cri.put("Lisa",temp);
HashMap<String,Double>temp1=newHashMap<String,Double>();
temp1.put("LadyintheWater",3.0);
temp1.put("SnakesonaPlane",3.5);
temp1.put("JustMyLuck",1.5);
temp1.put("SupermanReturns",5.0);
temp1.put("You,MeandDupree",3.5);
temp1.put("TheNightListener",3.0);
cri.put("Gene",temp1);
}

publicstaticdoublegetSim(Map<String,HashMap<String,Double>>cri,Stringp1,Stringp2){
HashMap<String,Double>p1m=cri.get(p1);
HashMap<String,Double>p2m=cri.get(p2);

List<String>simBook=newArrayList<String>();
for(Map.Entry<String,Double>entry:p1m.entrySet()){
if(p2m.containsKey(entry.getKey())){
simBook.add(entry.getKey());
}
}
//判断相同元素的个数
if(simBook.size()==0){
return1;
}
//对所有偏好求和
doublesum1=0d,sum2=0d;
//求平方和
doublesum1Sq=0d,sum2Sq=0d;
//求乘积和
doublepSum=0d;
for(Strings:simBook){
sum1+=p1m.get(s);
sum2+=p2m.get(s);

sum1Sq+=Math.pow(p1m.get(s),2);
sum2Sq+=Math.pow(p2m.get(s),2);

pSum+=p1m.get(s)*p2m.get(s);
}

//计算皮尔逊评价值
doublenum=pSum-(sum1*sum2/simBook.size());
doubleden=Math.sqrt((sum1Sq-Math.pow(sum1,2)/simBook.size())*(sum2Sq-Math.pow(sum2,2)/simBook.size()));

if(den==0){
return0;
}

returnnum/den;
}

}

❼ 谁有基于用户的协同过滤 java代码吗谢谢

下载mahout源码，里面好像有协同过滤算法

❽ 本人要做一个CF协同过滤的毕业设计，可是算法代码下载下来了，matlab完全是小白，根本不知道从何

协同过滤，肯定好
的
确

❾ 我想用协同过滤的算法写了一个java语言的图书推荐系统.能跟我讲一下大概要怎么做吗.有点没头绪

针对完全没有编程经验的初学者，java入门没什么特别好的书，找点视频看看吧，跟着视频敲代码，慢慢就能看懂书了。

----------------------如果坚持要看书的话可以考虑以下----------------------
1. head first java
通俗易懂，重点突出的书，比较薄，适合初学者快速入门，缺点是编辑自以为幽默的加了很多不相干的段子在里面，废话太多。

2. Java A beginner's guide by Herbert Schildt
相比head first java，没有废话，语言精炼。

3. 官方的tutorial
免费的，在线阅读的，也不错。

4. 疯狂java讲义
如果英文不够好的话，可以考虑用这本书入门，中文世界里写的比较好的

5. Introction to java programming by Y. Daniel Liang
梁勇这本书比较厚，讲算法比较多，如果你时间充足的话可以用这本书入门。

----------------------！！一定要避开这两个大坑！！----------------------
很多人推荐的core java 和 Thinking in java 其实并不适合初学者(没有编程经验的)。
1. core java内容太多太杂，没有突出重点，并且结构组织的像本字典，适合入门了以后用来系统复习。
2. Thinking in java 没有编程经验根本看不懂，过几年再看吧，不看也没关系。

❿ Spark 推荐算法-协同过滤-java的语句意思

协同过滤(Collaborative Filtering)的基本概念就是把这种方式变成自动化的流程

协同过滤主要是以属性或兴趣相近的用户经验与建议作为提供个性化的基础。透过协同过滤，有助于搜集具有类似偏好或属性的用户，并将其意见提供给同一集群中的用户作为参考，以满足人们通常在决策之前参考他人意见的心态。

本人认为，协同过滤技术应包括如下几方面:(1)一种比对和搜集每个用户兴趣偏好的过程;(2)它需要许多用户的信息去预测个人的兴趣偏好;(3)通过对用户之间兴趣偏好相关程度的统计去发展建议那些有相同兴趣偏好的用户。