Login or Register to Ask a Question and Join Our Community


Complex Event Processing RSS News

Analytics vs. CEP

Login to Discuss or Reply to this Discussion in Our Community

 
Thread Tools Search this Thread
Special Forums News, Links, Events and Announcements Complex Event Processing RSS News Analytics vs. CEP
# 1  
Old 11-29-2007
Analytics vs. CEP
lundberg
Thu, 29 Nov 2007 00:48:34 +0000
A number of recent articles in the insurance industry press indicates that the concept of real-time (and even predictive) analytics via CEP is becoming more widely understood and adopted...It makes perfect sense to me that Insurance companies can utilize Complex Event Processing in the underwriting and risk analysis part of their business. After all, underwriting is all about prediction, right?
The articles go into sundry details about insurance companies understanding the limitations of current batch-based analytics products, and how CEP has provided useful application for their companies; but surprisingly missing in the articles are stories about how insurance companies are using CEP for detecting insurance fraud, an area which has been problematic, to say the least.
Maybe in reality companies are doing this already, but don't want to, or are forbidden by their PR*departments to talk to the press about it. But it makes even more sense to me and is really a great example of how monitoring insurance related events with the speed and granularity of CEP can help to solve one of the biggest headaches insurance companies face.
Image

Source...
Login or Register to Ask a Question

Previous Thread | Next Thread
Login or Register to Ask a Question

LEARN ABOUT DEBIAN

function::ctime

function::ctime

FUNCTION:(3stap)					      Time utility functions						  FUNCTION:(3stap)

NAME

       function::ctime - Convert seconds since epoch into human readable date/time string

SYNOPSIS

	   ctime:string(epochsecs:long)

ARGUMENTS

       epochsecs
	   Number of seconds since epoch (as returned by gettimeofday_s)

DESCRIPTION

       Takes an argument of seconds since the epoch as returned by gettimeofday_s. Returns a string of the form

       "Wed Jun 30 21:49:08 1993"

       The string will always be exactly 24 characters. If the time would be unreasonable far in the past (before what can be represented with a
       32 bit offset in seconds from the epoch) the returned string will be "a long, long time ago...". If the time would be unreasonable far in
       the future the returned string will be "far far in the future..."  (both these strings are also 24 characters wide).

       Note that the epoch (zero) corresponds to

       "Thu Jan 1 00:00:00 1970"

       The earliest full date given by ctime, corresponding to epochsecs -2147483648 is "Fri Dec 13 20:45:52 1901". The latest full date given by
       ctime, corresponding to epochsecs 2147483647 is "Tue Jan 19 03:14:07 2038".

       The abbreviations for the days of the week are 'Sun', 'Mon', 'Tue', 'Wed', 'Thu', 'Fri', and 'Sat'. The abbreviations for the months are
       'Jan', 'Feb', 'Mar', 'Apr', 'May', 'Jun', 'Jul', 'Aug', 'Sep', 'Oct', 'Nov', and 'Dec'.

       Note that the real C library ctime function puts a newline ('
') character at the end of the string that this function does not. Also note
       that since the kernel has no concept of timezones, the returned time is always in GMT.

SystemTap Tapset Reference					     May 2013							  FUNCTION:(3stap)