Re: Math_Fraction

Hi Koureb, --- Kouber Saparev <kouber@php.net> wrote: > Hi folks, > > I just finished with a simple package for manipulating fractions (n = x/y, > where x and y are integers). The draft is in the PEPr system: > http://pear.php.net/pepr/pepr-proposal-show.php?id=168 Nice. Funny that I was just reading last week about P. Erdos and his interests in number theory, fractions and the like ;-) Could you put a link to the .phps files so people do not need to donwload/install the package to check it out? I have just browsed quickly > I followed the interface of Math_Complex, i.e. I have two classes: Fraction > and FractionOp (static). The second one is used to define all the possible > arithmetic operations with fractions: addition, substracion, multiplication > and division. It also have 3 methods for comparing fractions: eq(), lt() and > gt(). Another option, instead of the 3 comparison methods, is to have one compare() or cmp() method that returns -1, 0, or 1 depending on whether the first fraction is less, equal or greater than the second. Just more usual for those who have use some of the known sci/numerical libs out there. > I'm wish to have some comments and oppinions on the following topics before > moving from "draft" to "proposal": > > - I'm using "friendly" behaviour when creating new fraction - I'm just > converting the numerator and the denominator to integer. That is a good thing IMHO. > - I added LCM (least common multiple) and GCD (greatest common divisor) to > the Math_FractionOp class in order to implement addition, substraction and > comparing methods. Maybe it would be useful to "upper" these two to a higher > "Math" level because they're not for fractions only, so their place is > somewhere else in the Math directory. Perhaps we could use for Math_Integer, which I would like to redo to support not just gmp and bcmath, but perhaps a PHP native implementation for arbitrary integers (something along the lines of java.math.BigInteger). BTW, the GMP lib does have the those methods. For some of the mangling I've done on Math_Integer code (still maintaining the released API) see the stuff on CVS, I've not had time to do a native PHP implementation for big integers, so I had not released it yet. > - I'm invoking the simplify() method after each arithmetic operation - for > example when adding 1/6 + 3/6, it returns 2/3 and not > 4/6. Maybe there could be a third parameter to each method for allowing the > user to tell whether or not to simplify and to have the "simplify" behaviour > by default? I think that it should be setup either using a method to switch the behaviour and/or as a parameter in the operation. Better yet, it can be another method accessible so the user has the option of invoking it on the result if she so desires. Also, usually this operation is also known as reduction of a fraction. > - Currently fraction with denominator 1 are returned as they are, for > example 10/1 instead of 10 (int). I think that's the right way. Yep, that looks OK. BTW, did you consider expansion of functions to unit fractions (aka Egyptian fractions)? > - Currently new fraction are created that way: new Fraction($numerator, > $denominator);, but maybe it might be useful to have some alternative ways, > for example: new Fraction("$numerator/$denominator"); new > Fraction($numerator) - and assuming denominator is 1 by default; etc... I think that instead of the second and third options, perhaps there could be one that accepts a float and converts it to a fraction (continuous or not). Although it might be better to have a factory method in Math_FractionOp that does that, and keep the Math_Fraction constructor simple. > - I'm thinking also of a generic Math_FractionOp method that will accept the > operand as a string: "+", "-", "*", "/", > "<", ">", "="...and maybe more > combinations, and thus allowing the code to be more readable: $n = > Math_FractionOp::op($n1, "+", $n2);, or so. However that's an advanced and > important topic not only for Math_Fraction. For eaxmple in Perl there's a > possibility to overwrite operators - something that adds another level of > unclearness, but something similar in PEAR might be useful. The problem is that other languages (e.g. Python) support operator overloading, in PHP (as in Java) you have to use methods to accomplish the operations. Operator overloading might appear as more "natural", but some think otherwise. If you were building a system like Mathematica, Octave, or R, then yes, being able to define your own types and overload the operations is a plus, as they try to be as close so symbolic systems as they can be. In a programming language, in particular in a loosely typed one, this can lead to problems when debugging, that is one of the reasons (according to Gossling) that in Java there is no operator overloading. After all, using "$a = $b + $c" does not indicate univocally what the operands are, but "$a = Math_FractionOp::add($b, $c)" does it unambiguously. Your general operation method might be interesting to explore, and you could implement right now with a switch and some calls to your current methods. I usually prefer binary operation mehods to just take the two operands, but it is a question of preferences/styles. > Any other comments, oppinions and advises would be also welcome. One option would also be to accept or convert to/from improper/mixed fractions, e.g. from 5/4 to 1 + 1/4 Might want to take a look at some URLs such as: http://mathworld.wolfram.com/ContinuedFraction.html http://mathworld.wolfram.com/EgyptianFraction.html http://www.merriampark.com/fractions.htm Cheers. ===== -- Jesus M. Castagnetto (jcastagnetto@yahoo.com) Research: http://metallo.scripps.edu/ Weblog: http://weblog.castagnetto.org/ PEAR stuff: http://pear.php.net/user/jmcastagnetto _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com