K-Means Clustering Advantages and Disadvantages

K-Means Advantages :

1) If variables are huge, then  K-Means most of the times computationally faster than hierarchical clustering, if we keep k smalls.

2) K-Means produce tighter clusters than hierarchical clustering, especially if the clusters are globular.

K-Means Disadvantages :

1) Difficult to predict K-Value.
2) With global cluster, it didn't work well.
3) Different initial partitions can result in different final clusters.
4) It does not work well with clusters (in the original data) of Different size and Different density

K-Means Algorithm(Clustering Algorithm)

1) Basic Algorithm (Based on Relocation Algo)

Step1. select K data points as the initial representatives

Step2. for i = 1 to N, assign item xi to the most similar centroid (this gives K clusters)

Step3. for j = 1 to K, recalculate the cluster centroid Cj

Step4. repeat steps 2 and 3 until these is (little or) no change in clusters

2) Example (Clustering Term) :

Step 1:Initial arbitrary assignment as:
C1 ={ T1,T2} , C2={T3,T4}, C3 = {T5,T6}

Step 2:
Doc -Document
T - Terms in Doc
C - Clusters



Step3 : Cluster Term Similarity Matrix

i

Step 4 : Using new cluster centroid original Document - Term Matrix



Step5 : The process repeats until no further changes are made to Clusters.

Stored Procedure

Stored Procedures are compiled SQL code stored in the database. Calling stored procedures as opposed to sending over query strings improves the performance of a web application. Not only is there less network traffic since only short commands are sent instead of long query stings, but the execution of the actually code itself also improves. The reason is because a stored procedure is already compiled ahead of time. Stored procedures are also cached by SQL Server when they are run to speed things up for subsequent calls.

Other than performance, stored procedures are also helpful because they provide another layer of abstraction for your web application. For instance, you can change a query in a stored procedure and get different results without having to recompile your objects. Using stored procedures also makes your objects cleaner, and SQL Server’s convenient backup tool makes it easy to back them up.


Suppose we have the following query that retrieves messages from a given thread:

SELECT message_id,
       thread_id,
       user_id,
       first_names,
       last_name,
       email,
       subject,
       body,
       date_submitted,
       category_name,
       category_id,

       last_edited
FROM    message_view
WHERE thread_id = @iThreadID
ORDER BY date_submitted asc

To put this query in a stored procedure using the query analyzer, we simply have to give it a name (GetThreadMessages) and tell it what inputs (@iThreadID int) it requires. The name of the procedure goes in the create statement, then come the comma separated inputs, and finally the AS keyword followed by the procedure. The resulting statement would look like this:


Create Procedure GetThreadMessages
@iThreadID int

AS

SELECT message_id,
       thread_id,
       user_id,
       first_names,
       last_name,
       email,
       subject,
       body,
       date_submitted,
       category_name,
       category_id,

       last_edited
FROM    message_view
WHERE thread_id = @iThreadID
ORDER BY date_submitted asc

mmap() System call

mmap(void * start, size_t length, int prot, int flags, int sg_fd, off_t offset). This system call returns a pointer to the beginning of the reserved buffer associated with the sg file descriptor 'sg_fd'. The 'start' argument is a hint to the kernel and is ignored by this driver; best set it to 0. The 'length' argument should be less than or equal to the size of the reserved buffer associated with 'sg_fd'. If it exceeds the reserved buffer size (after 'length' has been rounded up to a page size multiple) then MAP_FAILED is returned and ENOMEM is placed in errno. The 'prot' argument should either be PROT_READ or (PROT_READ | PROT_WRITE). The 'flags' argument should contain MAP_SHARED. In a sense, the user application is "sharing" data with the sg driver. The MAP_PRIVATE flag does not play well with compiler optimization flags such as '-O2'. The 'offset' argument must be set to 0 (or NULL).

The mmap() system call can be made multiple times on the same sg_fd. The munmap() system call is not required if close() is called on sg_fd. Mmap-ed IO is well-behaved when a process is fork()-ed (or the equivalent finer grained clone() system call is made). In the case of a fork(), 2 processes will be sharing the same memory mapped area together with the sg driver for a sg_fd and the last one to close the sg_fd (or exit) will cause the shared memory to be freed.
It is assumed that if the default reserved buffer size of 32 KB is not sufficient then a ioctl(SG_SET_RESERVED_SIZE) call is made prior to any calls to mmap(). If the required size is not a multiple of the kernel's page size (returned by getpagesize() system call) then the size passed to ioctl(SG_SET_RESERVED_SIZE) should be rounded up to the next page size multiple.
Mmap-ed IO is requested by setting (or or-ing in) the SG_FLAG_MMAP_IO constant into the flag member of the the sg_io_hdr structure prior to a call to write() or ioctl(SG_IO). The logic to do mmap-ed IO _assumes_ that an appropriate mmap() call has been made by the application



Example of open file for read mode


#include
#include
#include
#include
#include
#include
#include

#define FILEPATH "/home/tarun/c_prog/mmap_test.txt"
#define NUMINTS (10)
#define FILESIZE (NUMINTS * sizeof(int))

int main(int argc, char *argv[])
{
int i;
int fd;
int *map; /* mmapped array of int's */

fd = open(FILEPATH, O_RDONLY);
if (fd == -1) {
perror("Error opening file for reading");
exit(EXIT_FAILURE);
}

map = mmap(0, FILESIZE, PROT_READ, MAP_SHARED, fd, 0);
if (map == MAP_FAILED) {
close(fd);
perror("Error mmapping the file");
exit(EXIT_FAILURE);
}

/* Read the file int-by-int from the mmap
*/
for (i = 1; i <=NUMINTS; ++i) {
printf("%d: %d\n", i, map[i]);
}

if (munmap(map, FILESIZE) == -1) {
perror("Error un-mmapping the file");
}
close(fd);
return 0;
}

Log Information in Android Application Development

For java file :

import android.util.Log;

Log.v(TAG, "Message");

Log.v(TAG, "Message" + msg);

For getting Log information

In eclipse Window->open perspective->DDMS

Here we can see log information

An EDF scheduling class for the Linux kernel

Linux is a General Purpose Operating System (GPOS) originally designed to be used in server or desktop environments. Since then, Linux has evolved and grown to be used in almost all computer areas.

An important part of Linux is the process scheduler (or simply the scheduler). This component of the kernel selects which process to execute at any instant of time, and is responsible of dividing the finite resource of processor time between all runnable processes on the system.

During the last years, there has been a considerable interest in using Linux also for real-time control systems, from both academic institutions and companies. The main reason for this raising interest is the free availability of the source code, under the terms of the GPL license. The free availability implies that using Linux in industrial devices is more convenient than using other commercial operating systems (which are typically very expensive or subject to royalties). The availability of the source code, moreover, allows software developers to further improve the already excellent performance of Linux by customizing the source code according to their specific needs.

Unfortunately, Linux has not been designed to be a Real-Time Operating System (RTOS), thus not much attention has been given to real-time issues. The default scheduling policies of Linux (i.e., SCHED_NORMAL and SCHED_BATCH) perform very well in their own domains of application, but cannot provide any guarantee to time-sensitive tasks. To make an example, there is no way of specifying that a task must execute for 20msec every 100msec. In addition, the time between two consecutive executions of a task is not deterministic and highly depends on the number of tasks running in the system at that time.

Linux also provides some POSIX-compliant fixed-priority scheduling policies (i.e., SCHED_RR and SCHED_FIFO). These policies, however, are not much sophisticated and often do not suit the specific application requirements. No concept of time is associated to these policies, therefore it is not possible to set any deadline for the tasks. Moreover, it is known from the real-time literature that, on uniprocessor systems, fixed-priority policies cannot guarantee real-time constraints when the processor is fully loaded: schedulability analysis for fixed-priority algorithms, in fact, can guarantee real-time constraints only for processor utilizations below a certain threshold, which depends on the characteristics of the task set and that can be as lower as 69% for uniprocessors.

These issues are particularly critical when designing time-sensitive or control applications (e.g., MPEG players) for embedded devices like smart-phones. These devices, in fact, are characterized by constraints on size, power consumption and cost. Embedded system designers, therefore, need to obtain the maximum performance from the embedded processor, in order to meet the timing constraints of the application even with not powerful hardware. Fixed-priority policies cannot ensure real-time constraints when the processor utilization is above a certain threshold, therefore they do not allow to fully exploit the performance of embedded systems. On the other hand, without a deterministic real-time policy, it is not possible to make a feasibility study of the system under development, and developers cannot be sure that the timing requirements of tasks will be met under any circumstance. These issues are among the ones that prevent the usage of Linux in real industrial contexts.

To overcome these problems, some companies operating in the industrial market started selling modified versions of the Linux kernel with some kind of support for real-time scheduling. However, these non-standard versions of Linux often are not free, vanishing the main reason for using Linux in industrial contexts. Moreover, they do not have the support of the huge development community of the standard kernel.

Real-time institutions and independent developers, on the other hand, have proposed some real-time extensions to the Linux scheduler during the last years. Unfortunately, none of these extensions eventually became part of the official Linux kernel. In the meantime, the Linux scheduler has been rewritten from scratch more than once. Very recently, the addition of further scheduling policies has been made easier through the integration of some mechanisms inside the standard scheduler itself. The latest Linux scheduler (i.e., CFS), in fact, is a modular scheduler: It allows to define further scheduling policies and to add new schedulers to handle the policies introduced. The binding between the new policy and the new scheduler is done through a set of "hooks'' (i.e., function pointers) at kernel level.

We believe that to be very "general'', Linux should also provide enhanced real-time scheduling support, still allowing to schedule non-real-time tasks in the usual way. In this paper, thus, we propose an implementation of the Earliest Deadline First (EDF) algorithm. This is a dynamic-priority algorithm well-known in the real-time literature. One interesting feature of this algorithm is that, on single processor systems, it can guarantee real-time constraints even when the processor is fully utilized (i.e., utilization equal to 100%). The new scheduling policy introduced by our implementation has been called SCHED_EDF.

With respect to similar work proposed in the past, our implementation takes advantage of the modularity offered by the new Linux scheduler, leaving the current behavior of existing policies unchanged. The new scheduling class is integrated with the latest Linux scheduler, and relies on standard Linux mechanisms (e.g., control groups), thus it natively supports multicore platforms and provides hierarchical scheduling through a standard API. Our implementation does not make any restrictive assumption on the characteristics of the task. Thus, unlike other schedulers, it can handle both periodic and aperiodic tasks.

A very interesting feature of this scheduling class is the "temporal isolation'' among the tasks handled. The temporal behavior of each task (i.e., its ability to meet its deadlines) is not affected by the behavior of the other tasks: if a task misbehaves and requires a large execution time, it cannot monopolize the processor. Thanks to the temporal isolation property, each task executes as it were on a slower dedicated processor, so that it is possible to provide real-time guarantees on a per-task basis. Such property is particularly useful when mixing hard and soft real-time tasks on the same system.

The paper is organized as follows. At the beginning we introduce definitions and characteristics concerning real-time systems as well as the scheduling model that will be used throughout the rest of the paper. Then, a brief overview of most notable approaches and implementations proposed in the last decade is provided. The current Linux scheduler (i.e., CFS) is explained, focusing on the modular facilities that it offers. We then describe the internals of the proposed implementation (i.e., SCHED_EDF), and we show how it has been integrated with existing mechanisms available on Linux (e.g., control groups). A full description of the API available at user-level is provided. Last but not least, our implementation is evaluated and validated through a set of tests and experiments on real hardware that will help understanding the main differences between SCHED_EDF and the existing scheduling policies already available on Linux.

Testing Losless Join Algorithm

Testing algorithm
input: A relation R, a decomposition D = {R1, R2,..., Rm} of R, and
a set F of function dependencies.

1. Create an initial matrix S with one row i for each relation Ri in
D, and one column j for each attribute Aj in R.
2. Set S(i, j) := bij for all matrix entries.
3. For each row i representing relation schema Ri Do
{for each column j representing Aj do
{if relation Ri includes attribute Aj then
set S(i, j) := aj;}
4. Repeat the following loop until a complete loop execution results
in no changes to S.

{for each function dependency X  Y in F do
for all rows in S which have the same symbols in the
columns corresponding to attributes in X do
{make the symbols in each column that correspond to
an attribute in Y be the same in all these rows as follows:
if any of the rows has an “a” symbol for the column,
set the other rows to the same “a” symbol in the column.
If no “a” symbol exists for the attribute in any of the
rows, choose one of the “b” symbols that appear in one
of the rows for the attribute and set the other rows to
that same “b” symbol in the column;}}
5. If a row is made up entirely of “a” symbols, then the decompo-
sition has the lossless join property; otherwise it does not.