Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : Advanced Micro Devices - Moderated (AMD) -- Ignore unavailable to you. Want to Upgrade?

To: Ali Chen who wrote (74384)	3/13/2002 8:13:43 PM
From: pgerassi	Read Replies (1) \| Respond to of 275872

Dear Ali: First you better check what a first order approximation is. C1/(C2/X + C3) is not a first order approximation. C1/(C2/X + C3) can be expressed as an infinite polynomial which implies an infinite order of the form SUM(C(i)X^i) where i=0 to infinity. First order implies that C(i) is zero for any i>1. It can be represented by a first order polynomial divided by another (XC1)/(C2+XC3) but, that does not make the result a first order polynomial. You are confusing a function using X only with a first order approximation. A zero order approximation sets the estimate Y to a constant. A first order approximation uses a constant plus dy/dx times a constant times X thus, Y = C1 + C2(dy/dx)X = C1 + C2(Y2 - Y1)*X/(X2 - X1). After some mathematical operations and the constraints that Y2 = F(X2) and Y1 = F(X1), we get the equation Y = Y2 + (Y2 - Y1)(X - X2)/(X2 - X1). That is the equation I gave you back a few posts ago. Your equation does not fit this and thus, is not a first order approximation otherwise known as linear approximation. Given your definition a solution setting F(x) = e^X or COS(X) would be a first order approximation. And those are clearly not. And the SPEC benchmark does not do a correctness test. There are howls about something being unfair wrt the SUN compiler for SPARC getting a 10x score in a particular program. Yet the result was published by SPEC. ScienceMark checks that the results are within an error bound. If they are outside that bound, ScienceMark fails that program and the resulting marks. SPEC does not do that nor is any output checked to see if the program did what it was supposed to do. Now, SPEC might have tightened the rules or only allowed programs that verified that the output is correct or that a compressor generates results that produce nearly the same output as the input after being uncompressed. Would you trust a compiler that uses single precision floating point when the program calls for double precision? Or a program that yields a result of 100 when the correct result is -0.1234 when given known test data. Perhaps they will fix these problems and many other known shenanigans in SPEC2004. Pete