I am in need of an algorithm for a zeroes finder that can take a list with numbers, sometimes including fractions, and to return the lowest possible constant that can be used to remove the fractions from the list. I had a simple Repeat loop, incrementing a variable until the fPart of all list terms was 0, but in several cases this results in a constant way too high, resulting in enormous processing times, and sometimes missing zeroes (not sure if this is a related issue but i think it could be). Can anyone advise a better way?

In addition I sometimes find that when the program I am using multiplies in fractions, sometimes the accuracy decreases, thus that my zeroes finder seems to miss zeroes bc something like 1/3 and 1/5 may not multiply out to full accuracy. Is there a way to fix this without totally revamping the math system?

Can you give the context in which this algorithm would be used? And what kind of inputs could one expect? These may change the recommended solution.

Well, I can definitely see how this could be useful, one way I could think of would be to use gcd( to find the greatest common divisor, then, multiply all the list's elements by that number, then only try to divide that list by prime numbers, checking every time if the fPart( of all the list's terms still remains zero by either having a list of primes sufficiently long that you know for sure the divisor will never be that large, or using one of the many methods to find prime numbers. I don't know if this would actually be faster, but it would probably be if the numbers are very large...

This right here makes me think that you put minimal effort into this before you decided to throw it out and try something else. Correct code for such a Repeat loop cannot miss zeroes. I worry that if you just keep throwing out code because it didn't work the first time, you'll end up with no good intuition about debugging, and no finished projects.

This is to streamline and optimize my Polynomials All-In-One Zeroes Finding algorithm. Basically, to explain so that research isnt necessary, my program can take an input like: ***Z : (x + 1)(x^2 - 1)(x + 3/5)(x - 1/4), and first foil out the arguments, and then calculate the zeroes. The first answer would be to just take roots from the binomials here, but since the Z can occur anywhere, and the input won't always be binomials, the algorithm needed to be one that is more flexible.

I implemented the rational zeroes test (P/Q), hardcoded a failure for Q=0, and now need a way to make all coefficients integers, since the method requires integer coefficients.

So do you take the input in the form of a string and parse it yourself? In that case, you should already know the denominators of any fractions that appear and can keep track of them somehow.

On the first iteration, it gets put into a list. On every subsequent iteration, the list gets modified to whatever the result of the next operation is. I suppose I could watch for denominators, but then that increases processing time on the string.

Also, @Kerm: I'm assuming that the Repeat loop is the cause of missing zeroes, but I'm not entirely sure. Every other part of the algorithm is working fine and the only thing that seems to show error is that Repeat loop goes on too long. I know that the accuracy of the calculator decreases as you start multiplying out stuff, so it's just a guess. I have been debugging this part of the program for 2 weeks, to no avail, so I have decided to inquire as to other, perhaps better options. I'm still debugging the loop tho :p


Edit: Resolved. I wasn't dealing with cases where the result was like .00000000000001, due to the calc rounding. Adding a test for that fixed it. Also used the Euclidean algorithm with Zeda's help to pull out a multiple, other than a loop.