[PEPr] Comment on Math::Math_AP
| From: | Etienne Kneuss | Date: | Thu, 12 Jan 2006 20:38:56 +0000 |
| Subject: | [PEPr] Comment on Math::Math_AP | ||
| References: | 1 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-40952@lists.php.net to get a copy of this message | ||
Etienne Kneuss (http://pear.php.net/user/colder) has commented on the proposal for Math::Math_AP.
Comment:
(I thought it would be better to make it a comment instead of a simple
reply)
Hello,
After a quick look into the code, I would like to make some
suggestions/remarks :
1) Where is my_pi() defined?? (used line 137)
2) There could be some improvements in the algorithms, like:
- You should save the result of "bcpow($num, 2)" and using only
multiplications instead of "bcpow($num,2 * $i + 1,$sc)"
- The exp algorithm is highly divergent for negative input, you'll need
some tricks( e^-x = 1/e^x and e4.8 = (((e^0.6)^2)^2) for example).
- don't use "($i/2 != floor($i/2))" but ($i & 1) -> much faster
- you should warn the user about invalid input: acos(), asin(), ln()...
- the atan() taylor's developpement only works with input in the interval
[-1;1], you'll need some tricks (trigonometric transformations) to allow a
wider range.
- some algorithms **need** at lot of loops to become relevant, I don't see
the point using $scale as a brake condition, you should break the loop on a
relative error basis.
3) I don't really like the way you get the Pi value, especially if its the
only reason to have zlib in dependencies. There is also a way to calculate
this value.
4) Applying P.C.S would make the code much more readable.
5) I can imagine unexpected results, because of the intermediary
simplifications using $scale+<arbitrary number>. There's probably a better
way to do it.
Kind regards
Proposal information:
http://pear.php.net/pepr/pepr-proposal-show.php?id=340
--
Sent by PEPr, the automatic proposal system at http://pear.php.net