博文

FreeSpan 和 PrefixSpan 算法对比(2009-10-10 16:28:00)

摘要:在序列模式挖掘中,FreeSpan和PrefixSpan是两个常用的算法。其中,PrefixSpan是从FreeSpan中推导演化而来的。这两个算法都比传统的Apriori-like的序列模式挖掘算法(GSP)都有效。而PrefixSpan又比FreeSpan又更有效。这是因为PrefixSpan的收缩速度比FreeSpan还要更快些。 下面将分别介绍这两种算法 1. FreeSpan算法 FreeSpan算法的核心思想是分治算法。下面通过一个例子来描述: 假设有一个序列数据库有如下四条序列记录 首先求得一项频繁集合为 a(4) b(4) c(4) d(3) e(3) f(3) 然后,频繁序列肯定是以这两个元素为开始的。 下面以求 a 开头的频繁序列模式为例子, 包含六中可能 (1) 序列中只包含a (2) 序列中只包含 a , b (3) 序列中只包含 a , b , c (4) 序列中只包含 a , b , c, d (5) 序列中只包含 a , b , c, d, e (6) 序列中只包含 a , b , c, d, e , f 在求第一种可能的时候,对数据库中的每条序列记录来说,去掉不包含在一项频繁集合中的元素,并且去掉 a 以外的元素。得到映射数据库为: 这里,求二项集合,可见,次数为2,是频繁序列。就这一个二项频繁序列,没有三项或以上的频繁序列。 求第二中情况, 同样,去掉非频繁元素及 a , b 以外的其他元素。 可见,该情况下有三个频繁二项序列。 为 ab(4), ba(2), (ab)(2)。 然后,再扫描一遍该映射数据库,分别从二项频繁序列中扩展三项频繁序列集,得到一项频繁三项序列为 aba(2) 同样,将其他集中情况一次的求解。得到以a 开始的频繁序列集。然后分别求以 b, d, e, f开头的频繁序列。就得到了所有的频繁序列集合。 2. PrefixSpan 算法 还以上面这个序列数据库为例,开头还是一样, 首先求得一项频繁集合为 a(4) b(4) c(4) d(3) e(3) f(3) 然后,频繁序列肯定是以这两个元素为开始的。 下面以求 a 开头的频繁序列模式为例子, 求的 a 的映射数据库为 ......

阅读全文(7012) | 评论:1

gtk+ 下绘图及图片显示相结合并对图像进行缩放(2009-08-07 16:07:00)

摘要:这方面的资料确实比较少,通过自己摸索,实现了在GTK+ 2.0下进行图片显示,然后在图片上可以自己绘图的一个程序。啥也不说了,发上源码,以供大家参考。希望对学习GTK+的人有点帮助。 #include <gtk/gtk.h>
#include <stdlib.h>
#include <gdk-pixbuf/gdk-pixbuf.h>   #define DA_WIDTH 300 #define DA_HEIGHT 300 #define SCALE_FACTOR 1.2 #define PEN_MOVE  0
#define PEN_UP    1
#define PEN_DOWN  2
GdkPixmap *pixmap = NULL;
GtkWidget *window, *vbox, *tool_bar, *drawing_area; gboolean status;
gboolean fdiscard = TRUE; gint prev_x, prev_y;
GdkGC *my_gc_red;
GdkColor color; struct ImageData {   GtkWidget *drawing_area;   int width, height;   GdkPixbuf *pixbuf;   float scale; }; struct ImageData data;
static void expose_cb(GtkWidget *da, GdkEventExpose *event, struct ImageData *data)
{
  gdk_pixbuf_render_to_drawable_alpha(data->pixbuf, da->window, 0, 0,           0, 0, data->width, data->heigh......

阅读全文(5988) | 评论:0

GTK 2.0 界面设计工具---glade(2009-07-29 16:03:00)

摘要:注:转自http://www.cqinc.com.tw/coopermaa/xwindow/2000010201.htm Glade 入門介紹 Introduction 在了解 Glade 之前,我想你應該先了解一下 GTK+ 與 Glade 之間的關係: GTK+ (GIMP Tool Kit) 是一套圖形函式庫 (GUI, Graphical User Intreface),可用來建立 X Window  System 以圖形為基礎 (GUI-based) 的應用程式。一開始 GTK+ 是寫來給 GIMP (GNU Image Manipulation Program) 圖形處理軟體使用的,不過隨著 GNU/Linux 與 GNOME Desktop (使用了 GTK+) 的流行,  GTK+ 圖形庫已經慢慢普遍使用在各種工具中。 雖然有了 GTK+,但是要用 GTK+ 來撰寫程式並不是一件輕鬆的事,因為要完成一個 GUI-based 的應用程式,得靠自己用熟悉的文書編輯器,一行一行把 C 程式碼敲出來。如果你是個抽象思考力非常好,又很有耐性寫程式碼的人,也許只要幾個小時就能把 GTK+ 摸透;但如果你和我一樣也是個懶墮的傢伙,我想能撐個一小時來弄清楚 GTK+ 有什用,就可算是一件非常了不起的事了 :-)。還好,Glade 的出現讓我在想放棄前有了回心轉意的念頭。 Glade 是 GTK+ 圖形使用者介面產生器 (User Interface Builder for GTK+). 也就是說,Glade 是個 Visual Programming Tool,和 Microsoft  Windows 平台的 Visual Tools (VB、Delphi) 類似,只要用滑鼠拉一拉,它就會自動幫你產生 C source code。所以我們這些懶人,就不用再去為畫面的設計煩腦,用 Glade 設計好畫面,再用編輯器把程式碼稍為修修減減就 OK 了。(現在也有各種語言如 C++、Ada95、Python、Perl 等的 GTK+ 介面,如果再搭配其它工具,也可以自動產生 C++, Ada95, Python  and Perl 的程式碼)。 本文概括性的介紹如何用 Glade 來建立使用者介面,同時也包含了用 G......

阅读全文(4049) | 评论:0

难搞的typename用法(2009-03-14 16:58:00)

摘要:注: 转载至 http://www.kuqin.com/cpluspluslib/20071210/2872.html /*******************************************************************************
 *  SGI*STL是STL之父Alexander Stepanov和STL巨匠Matt Austern等人的作品, 是当今  *
 *  最富盛名、最出色的STL实现版本,全部源代码和说明文档可从http://www.sgi.com/STL/  下*
 *  载, 是我们学习STL的最佳范本. 但是众所周知, STL使用了大量复杂艰深的C++特性, *
 *  加上STL本身的复杂和庞大, 使得阅读代码本身就成为一件非常困难的工作. 以下文  *
 *  字是我在学习STL过程中得到的一些经验和猜测, 希望能对大家有所帮助, 更希望能  *
 *  得到大家的批评和指正, 以利于我们的共同提高.                                *
 *                                           ......

阅读全文(3221) | 评论:0

Web日志转成.mdb格式的Access数据文件(2009-02-27 11:11:00)

摘要:  对于做Web数据挖掘的人来说,日志分析是一个比较重要的部分。根据一个网站或者服务器的日志文件,可以分析出一些很有用的信息,供网站开发人员或者服务器管理人员进行工作的进一步改进与管理。比如可以通过网站的访问日志分析得出该网站的哪部分是用户比较喜欢的,哪部分是用户很少访问的,一般用户访问了某一部分内容后,接着希望访问一些什么内容等等。这些都可以通过Web日志分析来得到。   对于日志分析来说,数据的前端处理非常重要,一般来说,我们拿到的日志文件是如下图所示,加入命名为Weblog.log。每一行代表一条记录。第一步要做的就是去除其中无用的信息,然后将其转换成数据库形式,这里,我主要介绍如何将文本形式的日志文件转成Access的.mdb数据文件以及sql的.mdf数据文件。并且介绍一下关于SQL 2005的一个问题。 一 SQL 2000和SQL 2005介绍 在SQL2000中,有一个DTS(数据转换工具),该工具可以实现各种数据文件之间的转换。但是该工具在SQL2005中就没有单独的放出来,而是被包含在了其他的工具里面了。 Web日志文件虽然是文本文件,但是它的后缀是.log,如果想将其导入数据库必须首先将其后缀改称.txt。然后打运行SQL Server2000的服务管理器,然后打开企业管理器。 一般安装的时候都是选择服务器是Local形式的,所以非Local形式的企业管理器是不能连接到Local服务器的。解决方法:新建一个SQL Server组,然后对该新建的组进行“新建SQL Server注册”,服务器选择Local服务器就可以了。如果你新建的SQL Server组能够正常运行了,这进行下一步。建立新的数据库Weblog,然后利用工具DTS进行操作,DTS即数据转换服务。操作为“工具—〉数据转换服务—〉导入数据”,出现如下对话框如图2所示。 图2 点击下一步得到如图3所示的对话框。 图3 在图3对话框中的数据源选择文本文件,对话框变成图4所示界面。点击文件名处右边的浏览按钮可以选择所要读取的文本文件形式的日志。这里只能读取.txt文件,所以前面一定要将Web日志的后缀.log改成后缀.txt。 图4 单击下一步进入图5所示界面 图5 这里,我们要注意,如果不正确的选择“行分......

阅读全文(4166) | 评论:0

C语言头文件中定义变量问题(2008-06-19 11:26:00)

摘要:上个星期回学校的时候,刚好碰到一个学弟在写程序,并且刚好碰到一个总编不过去的问题,我看了看,正好是个头文件重复包含问题,问题描述如下: 他在程序中建立了一个global.h的文件,代码如下: #ifndef _GLOBAL_H_ #define _GLOBAL_H_ int a; int b; int c; 然后在其他文件代码中,有多个.cpp文件引用他,编译的时候编译器报变量重复定义。   其实这是个C语言的基本问题,如果学过编译原理的人就很清除问题在哪里。假设上面的头文件global.h,有三个.cpp文件,1.cpp, 2.cpp, 3.cpp都包含了这个头文件。那么在编译的时候分别生成 1.obj, 2.obj, 3.obj。在这三个obj文件中都包含变量a, b, c。那么在链接的时候你让机器怎么去分别三个a变量,三个b变量,三个c变量,那么就只好给你报个错了。   不过,如果是从事Linux或者以前标准C语言开发的人可能会想,我原来编程就是这么编的,怎么就没有报错。对的,有些编译器是具有这种重定义自动检测的,如Linux下C编程。我目前用的编程环境是Visual studio.net 2003。我写了两个小程序测试了一下,一个是标准C程序,如下: head1.h #ifndef _HEADER1_H_
#define _HEADER1_H_ void print_1(); #endif head2.h #ifndef _HEADER2_H_
#define _HEADER2_H_ void print_2(); #endif global.h #ifndef _GLOBAL_H_
#define _GLOBAL_H_ int g_test; #endif   head1.c void print_1()
{
 g_test=1;
 printf("%d\n",g_test);
}   head2.c void print_2()
{
 g_test=2;
 printf("%d\n",g_test);
} main.c void main()
......

阅读全文(13273) | 评论:2

内存分配中的堆与栈(2008-03-31 10:16:00)

摘要:  在标准C语言上,使用malloc等内存分配函数获取内存既是从堆中分配内存,而在一个函数体中例如定义一个数组之类的操作是从栈中分配内存。     从堆中分配的内存需要程序员手动释放,如果不释放,而系统内存管理器又不自动回收这些堆内存的话(实现这一项功能的系统很少),那就一直被占用。而栈内存在函数体内一直存在,你无法丢掉,在离开函数体后,立即被销毁,你无法挽留。     如果老是申请堆内存,而不释放,内存会越来越少,很明显的结果是系统变慢或者申请不到新的堆内存。而过度的申请栈内存(可以试试在函数中申请一个1G的数组!),会导致栈被压爆,结果是灾难性的。栈都爆了,谁知道函数会跑到哪里去?!     我们掌握堆内存的权柄就是返回的指针,一旦丢掉了指针,便无法在我们视野内释放它。这便是内存泄露。而如果在函数中申请一个数组,在函数体外调用使用这块栈内存,结果谁也无法预测。
  
    申请栈内存的时间是基本确定的。核心只要栈指针的偏移和对它进行初始化(如果必要的话)。但堆中的时间是无法预测的,这是内存管理器的任务,跟他的算法和当前的堆内存结构有关,也许很快,也许很慢。两者在这里不存在可比性,尽管大多数情况下栈内存的申请的确比堆内存要快。
    申请的时候,栈内存几乎等同与申请大小,大多数的偏差是内存对齐引发的几个字节影响。但对内存但实际也会会相差很大(这主要源于内存管理器算法)。常见的内存管理都是按照基本内存块大小来分配的。在一个基本单元是1024Byte的管理器上,哪怕你只申请一个Byte,它也会给你1024个。频繁的申请小的堆内存是不明智的。
    在申请和销毁之外的使用过程中,他们是一样,可以同样对待。一般情况下,他们具有同样的访问速度,都不要进行越界访问,哪怕堆内存先后越界暂时不会出错。     栈内存和堆内存的大小也没有可比性。栈内存大小跟IC,编译器,OS相关。而对堆内存的大小一般是内存管理器说了算。X86上Windos下VC编译的代码只是N种情况之一。并不具备多少代表性。至于磁盘是否能......

阅读全文(3462) | 评论:1