Sponsored Content
Full Discussion: CEP in 2011 and Beyond....
Special Forums News, Links, Events and Announcements Complex Event Processing RSS News CEP in 2011 and Beyond.... Post 302479381 by Linux Bot on Friday 10th of December 2010 01:00:01 PM
Old 12-10-2010
CEP in 2011 and Beyond....

John Bates
12-10-2010 01:52 PM
As we approach the end of 2010 and we begin to see a tiny crack of light at the end of the financial crisis tunnel, there are many theories as to which technologies will lead us into the next phase of advancement in financial markets. Stubborn issues with latency, high frequency trading, real-time risk management, and market gaming/fraud continue to dog the industry and provide fertile ground in which new and existing technologies can innovate. In fact, technology consultancy Ovum said in its 2011 Trends to Watch report for financial markets (http://tinyurl.com/2vv42sh) noted thatComplex Event Processing is one technology to watch. 

CEP will be the lifeblood for financial services as regulation increases, markets further fragment, and algorithmic trading becomes engrained in all asset classes. A recent Progress Software survey across industries showed that only eight per cent of enterprises globally are able to report business information in real-time. Without instant visibility into business activity organisations cannot possibly determine what is or is not working and then set the right course of action.

In financial markets, in particular, a lack of visibility between exchanges, ECNs, dark pools, brokers, banks, buyside and trading firms is causing breakdowns in the system. When you see increasingly frequent events setting markets on their ear such as the May 6th flash crash, insider trading activity, fat fingered errors and rogue algorithms, it becomes crystal clear that something needs to be done. 

Progress, with its Apama products, is committed to financial markets along with other, newer markets such as aviation and telecommunications that are opening up to CEP. If you would like further information about the future of CEP and would like to speak to one of the two founders of Progress Apama- yours truly or my colleague Dr. Giles Nelson-then please contact us. 

 



Source...
 
EXP(3M) 																   EXP(3M)

NAME
exp, expm1, log, log10, log1p, pow - exponential, logarithm, power SYNOPSIS
#include <math.h> double exp(x) double x; double expm1(x) double x; double log(x) double x; double log10(x) double x; double log1p(x) double x; double pow(x,y) double x,y; DESCRIPTION
Exp returns the exponential function of x. Expm1 returns exp(x)-1 accurately even for tiny x. Log returns the natural logarithm of x. Log10 returns the logarithm of x to base 10. Log1p returns log(1+x) accurately even for tiny x. Pow(x,y) returns x**y. ERROR (due to Roundoff etc.) exp(x), log(x), expm1(x) and log1p(x) are accurate to within an ulp, and log10(x) to within about 2 ulps; an ulp is one Unit in the Last Place. The error in pow(x,y) is below about 2 ulps when its magnitude is moderate, but increases as pow(x,y) approaches the over/underflow thresholds until almost as many bits could be lost as are occupied by the floating-point format's exponent field; that is 8 bits for VAX D and 11 bits for IEEE 754 Double. No such drastic loss has been exposed by testing; the worst errors observed have been below 20 ulps for VAX D, 300 ulps for IEEE 754 Double. Moderate values of pow are accurate enough that pow(integer,integer) is exact until it is bigger than 2**56 on a VAX, 2**53 for IEEE 754. DIAGNOSTICS
Exp, expm1 and pow return the reserved operand on a VAX when the correct value would overflow, and they set errno to ERANGE. Pow(x,y) returns the reserved operand on a VAX and sets errno to EDOM when x < 0 and y is not an integer. On a VAX, errno is set to EDOM and the reserved operand is returned by log unless x > 0, by log1p unless x > -1. NOTES
The functions exp(x)-1 and log(1+x) are called expm1 and logp1 in BASIC on the Hewlett-Packard HP-71B and APPLE Macintosh, EXP1 and LN1 in Pascal, exp1 and log1 in C on APPLE Macintoshes, where they have been provided to make sure financial calculations of ((1+x)**n-1)/x, namely expm1(n*log1p(x))/x, will be accurate when x is tiny. They also provide accurate inverse hyperbolic functions. Pow(x,0) returns x**0 = 1 for all x including x = 0, Infinity (not found on a VAX), and NaN (the reserved operand on a VAX). Previous implementations of pow may have defined x**0 to be undefined in some or all of these cases. Here are reasons for returning x**0 = 1 always:(1) Any program that already tests whether x is zero (or infinite or NaN) before computing x**0 cannot care whether 0**0 = 1 or not. Any program that depends upon 0**0 to be invalid is dubious anyway since that expression's meaning and, if invalid, its consequences vary from one computer system to another.(2) Some Algebra texts (e.g. Sigler's) define x**0 = 1 for all x, including x = 0. This is compatible with the convention that accepts a[0] as the value of polynomial p(x) = a[0]*x**0 + a[1]*x**1 + a[2]*x**2 +...+ a[n]*x**n at x = 0 rather than reject a[0]*0**0 as invalid.(3) Analysts will accept 0**0 = 1 despite that x**y can approach anything or nothing as x and y approach 0 independently. The reason for setting 0**0 = 1 anyway is this: If x(z) and y(z) are any functions analytic (expandable in power series) in z around z = 0, and if there x(0) = y(0) = 0, then x(z)**y(z) -> 1 as z -> 0.(4) If 0**0 = 1, then infinity**0 = 1/0**0 = 1 too; and then NaN**0 = 1 too because x**0 = 1 for all finite and infinite x, i.e., indepen- dently of x. SEE ALSO
math(3M), infnan(3M) AUTHOR
Kwok-Choi Ng, W. Kahan 4th Berkeley Distribution May 27, 1986 EXP(3M)
All times are GMT -4. The time now is 10:44 PM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy