It looks like you're using an Ad Blocker.

Thank you.

Some features of ATS will be disabled while you continue to use an ad-blocker.

# Calling all Maths geniuses - help is requested !

page: 1
0
share:

posted on Oct, 28 2009 @ 04:18 AM
Hi all,

I'm working on a personal maths project and have reached a point where a little outside help in the maths department would be extremely welcome ... and I'm more than certain that we have ATS members who are well versed in mathematics and may be able to provide such assistance and insight

If nothing else, perhaps my question will serve to brush off some of those cobwebs that tend to accumulate over the years on all of our brain cells !

Ok, what I'm after is some form of mathematical "short cut" to arrive at a required solution given a bit of input to start with. Basically, I use the staring input and perform some simple calculations and eventually end up with the answer I'm looking for. The problem is that there may be times when it becomes necessary to have to repeat those simple calculations over and over, maybe for 100's, 1000's or even millions of times before reaching the solution ... and so I need that "short cut" to effectively bypass as many of those repeated intermediary calculations and thereby save a heck of a lot of processing time.

Basically, I start of with 2 input values say, 129 and 3154.
I then create a quadratic equation using these values which will look like this:

Now I find the roots of this quadratic which in this example are 32.78 and 96.22

If the roots are BOTH integer values only, then these roots are the solution I was looking for ... and end of story.

But if either or both are NOT integer values, e.g. (23.76 and 57.9) ... or (237.2 and 673.58) ... or (76 and 142.62) then we modify the two starting numbers by adding 24 to the smaller of the two, and subtracting 1 from the larger of the two as shown here:

129 + 24 = 153 and
3154 - 1 = 3153

Now we repeat the process using these two new numbers of 153 and 3153 by creating a quadratic equation

and trying to find two INTEGER roots.

Again, if we find them ... then success and we stop ... otherwise repeat by adding 24 and subtracting 1 from the two numbers just used and creating yet again, a new pair of numbers to try.
This process of adding 24 and subtracting 1 continues as many times as necessary (a few times, 100's, 1000's, etc of times) until we find those two integer roots.

At this point I have to mention that the two original starting numbers will ALWAYS eventually result in two integer roots, because these two starting numbers have been specifically selected based on the advance knowledge that integer roots DO exist when these numbers (or their 'modified' numbers) are placed into quadratic form.

Here is an example of the entire process of finding the two integer roots starting with two original numbers of 9 and 3159. It takes only 10 iterations to arrive at the quadratic that produces integer roots.
Note that we're starting at the bottom of the table and working our way up to the top.
I should also mention at this point that if the roots happen to be complex, then they're ignored and the iterations continue ... we're ONLY looking for those TWO INTEGER roots !

Here is a graphical view of the 2 roots:

So as you can see in this example, it was trivial to find the two integer roots after just 10 iterations. But not all cases are this easy and could involve 1000's and millions of iterations before those two integer roots eventually pop up ... and this leads back to my original request for assistance ... to find some "short cut" that will help to eliminate as many of those repeated intermediary iterations as possible and "jump" from the original starting two numbers to the 'modified" two numbers that will produce the integer roots.

So in summary, and using the above example, I basically need a method or a short cut to go from starting numbers 9 and 3159, to final numbers 225 and 3150 in the most efficient and effective way possible.

If anyone's interested in trying this out for themselves with other pairs of starting numbers, use the following pairs which will definitely eventually produce integer roots.

7 and 602
10 and 265
23 and 1866
10 and 13215

Ok, that's all there is to it ... so anyone have any brilliant suggestions or ideas ? I'd be incredibly grateful for such help !

[edit on 28/10/09 by tauristercus]

posted on Oct, 28 2009 @ 04:51 AM
Hmmm....quadratic formula + computer program? Seems simple enough. You are starting with coefficients and so the search is integer roots. Iterate through coefficients.

Edit:
Methinks I didn't understand your request fully so early in the AM. You want an algorthm that doesn't take O(N) but less time. Hmmm.

[edit on 10/28/2009 by EnlightenUp]

posted on Oct, 28 2009 @ 05:23 AM
Ill give you a star just for frying my brain....well I thought I had one after reading that....

posted on Oct, 28 2009 @ 05:47 AM

Originally posted by EnlightenUp
Hmmm....quadratic formula + computer program? Seems simple enough. You are starting with coefficients and so the search is integer roots. Iterate through coefficients.

Edit:
Methinks I didn't understand your request fully so early in the AM. You want an algorthm that doesn't take O(N) but less time. Hmmm.

[edit on 10/28/2009 by EnlightenUp]

You're right that I DO want an algorithm or some kind of formula that would take the initial 2 values and somehow spit out the eventual roots ... somehow bypassing all the iterations that would be required if done manually or with computer code which could take a huge amount of time.

Basically something along the lines of this blackbox function

posted on Oct, 28 2009 @ 06:03 AM
I'm not sure I fully understand what you want. Do you mean you want some equation or formula that would allow you to enter your starting values (and perhaps -1 and 24 as well), that would immediately give you the ending values that are integers? If you do, then I'm not able to help you. I'm not sure there's a closed form for this process, and I'm not sure I'm up to finding it, even if there is one.

Are you looking for a programming algorithm to do that? Then you can likely put one together without too much difficulty. The "hard" part would be finding a function that solves the quadratic equation, but there are libraries that will do that for you. Since I don't know what language (if any) you would be using, I can't give a specific example, but I can give you a sort of "pseudo-code" idea of how to go about it.

1 A = 129
2. B = 3153
3. Root1, Root2 = solve(x^2-AX+B) /* This would solve the quadratic and give the roots)
4. If ((Root1=int(Root1)) AND (Root2=int(Root2))) then STOP (You've got your solution).
5. If A>B then A=A-1; B=B+24; Goto 3
6. A=A+24; B=B-1 Goto 3

This should do it, more or less (I haven't actually tested it, so it might be buggy). Even if it does take a few million iterations, it shouldn't require all that much time on a normal computer.

I'm curious to know what this is about, and why you are so certain that this process will always yield an integer value eventually. I'm also wondering what happens when your values wind up changing places - when your "smaller" number gets 24 added to it so many times that it becomes larger than the "larger" number. Then they swap places, back and forth...

posted on Oct, 28 2009 @ 06:13 AM
As the above poster stated, I am not sure there is an algorithm for solving this without doing an actual simulation for the answers. In mathematics, many times you must do a simulation on a computer several times in order to come up with a theory based on the simulation results. Many times you can't even fit the simulation with a theory, and the best you can get is an expected number, which may be close to the simulations.

This would be very easy to do in a program, and a program would be the best starting place for this in my opinion. Once you have a good subset of data, then you can start to try and find a function. f(x), that describes this formula.

If you are looking for mathematics that deal with large iterations of numbers you will want to look into Riemann sums or integrals. Both deal with iterations such as what you are looking for. Its still a bit early for me to think about a possible solution; I am still waiting for the coffee to kick in. However I would definitely start with the program to solve this for lots of test numbers. Only then will you be able to see a relationship, if any, in the output.

posted on Oct, 28 2009 @ 06:20 AM

bypassing the iteration ???

i'd be curious to see the algorithm that would do that without iteration... (might take longer to find it than to run 100000000 times the algorithm using iteration...)

~~~~~~~~~~

xxx=3*x*37

posted on Oct, 28 2009 @ 06:21 AM
Does this have anything to do with solving the final piece to your "Prime Ray Theory", which by the way, was one of the best posts ever? I'm not a math genius although I do take great interest in it's applications. Good luck in your search. Just be sure that if you figure it out you don't steal my bank account...

posted on Oct, 28 2009 @ 06:25 AM

Originally posted by chiron613
I'm not sure I fully understand what you want. Do you mean you want some equation or formula that would allow you to enter your starting values (and perhaps -1 and 24 as well), that would immediately give you the ending values that are integers? If you do, then I'm not able to help you. I'm not sure there's a closed form for this process, and I'm not sure I'm up to finding it, even if there is one.

Yes, thats exactly what I'm hoping to find and why I'm asking for help here on ATS.
A computer program that has to process potentially millions of iterations starting with the initial 2 values is way to slow for my purposes and therefore I need some kind of function that will give me a direct short cut to the final roots ... or even if it only reduces the number of iterations by some factor, that would also be a huge help.

I'm curious to know what this is about, and why you are so certain that this process will always yield an integer value eventually. I'm also wondering what happens when your values wind up changing places - when your "smaller" number gets 24 added to it so many times that it becomes larger than the "larger" number. Then they swap places, back and forth...

I didn't think it would take too many posts before someone asked why I'm doing this

I've had a very long interest (obsession ?) with prime numbers, especially with recovering the initial 2 prime numbers that were multiplied together to give a product. e.g 7 x 11 = 77.
In other words, if you were only given the product 77 and were asked to determine the original 2 primes used to create this value, you'd basically have little choice except to use "brute force" techniques and hammer away at this 77 value with every prime number that was smaller than the square root of this value ... eventually finding that 7 is one prime factor and therefore 11 is the other prime factor.

It's taken me a number of years but I've successfully derived an alternative method of retrieving the prime factors of ANY product that is supplied. It's already been succesfully tested on small digit length products and succesfully extracts both primes in each case. The only remaining issue I have is the subject of this thread, and if it can be resolved, will make this an incredibly useful tool for extracting primes from ANY size product and will do this extremely quickly.

posted on Oct, 28 2009 @ 06:30 AM

Originally posted by Bass9
Does this have anything to do with solving the final piece to your "Prime Ray Theory", which by the way, was one of the best posts ever? I'm not a math genius although I do take great interest in it's applications. Good luck in your search. Just be sure that if you figure it out you don't steal my bank account...

In fact, yes it is very much related to the contents of that thread.
Since I posted that thread, I've actually derived what so far seems a radically alternative method of extracting the prime factors from a product of 2 primes.
At the moment I need help in speeding up this final stage or at least cutting down the time required by a significant amount.

posted on Oct, 28 2009 @ 06:32 AM
Given the state of the unknowns, I am not holding out hope for a shortcut in general.

Check (b^2 - 4*a*c) is positive and a perfect square. Call this Z.

Thus this must be true: b^2 / 4 >= c. Don't bother checking coefficients where it isn't.

Check b +/- sqrt(Z) is even (both terms even or odd). Not much shortcut here though.

[edit on 10/28/2009 by EnlightenUp]

posted on Oct, 28 2009 @ 06:41 AM

Originally posted by EnlightenUp
Given the state of the unknowns, I am not holding out hope for a shortcut in general.

Check (b^2 - 4*a*c) is positive and a perfect square. Call this Z.

Check b +/- sqrt(Z) is even (both terms even or odd). Not much shortcut here though.

Thanks for that ... it's the sort of feedback and help I'm looking for. Might even suggest other alternative ways of approaching and hopefully, solving, this last crucial step

posted on Oct, 28 2009 @ 06:41 AM
After a bit further thought, and some more coffee (I'm semi-conscious now), I've pretty much come up to the conclusion that there will be no short cut for this type of method. The fact that your method requires a "rounding" of numbers, takes it out of the realm of being put together as some sort of Theorem. Math doesn't like to just forget about or disregard some part of a number. Math likes to be exact, and likes to be able to get back to where it came from via inverse operations (there are however numerous non-inverse functions which are used in cryptography).

However, as a general rule of thumb, if the function requires rounding numbers up or down, you have stepped out of the realm of theory and stepped into the realm of simulation.

Again, this is not to sat it isn't possible, it is just to say that it will be very difficult in the method you have proposed.

posted on Oct, 28 2009 @ 06:45 AM

I made a small edit to my previous post with another possible check which would set a starting point.

posted on Oct, 28 2009 @ 06:51 AM

After a bit further thought, and some more coffee (I'm semi-conscious now)

I know that feeling all too well

The fact that your method requires a "rounding" of numbers ...

I'm not sure where I suggested that there's a need or requirement for rounding ... will have to re-read my 1st post.

The only operations being used are a simple addition of a 24 constant to the 1st value, a simple subtraction of a 1 constant from the 2nd value... and the evaluation of a quadratic. The roots of the quadratic will either be of the form 'complex root" that we can discard, or include one or two non-integer numbers that we can also discard, or both be integers which is what we need.

posted on Oct, 28 2009 @ 06:54 AM

Originally posted by EnlightenUp

I made a small edit to my previous post with another possible check which would set a starting point.

Again, thankyou for that and I'll give it some time tomorrow morning and see if there's any promising leads arising from that.

posted on Oct, 28 2009 @ 07:01 AM
here is something that might be helpful, the differnece between each values of x when ploted on a graph resembles n/x, n being your magic number.

hope it helps

note: i only went over this really quickly, but it appears to work.

ie

(1, 32.78 - 24.5)
(2, 24.5 - 20.9)
(3, 20.9 - 17.14)... etc

i don't know how it will work for the complex numbers, but meh might be useful.

best of luck.

PS. if this works credit me lol

EDIT: oh then u can plug n into this forumla and u should be good to go Ax^2 + (B + 24n)x + (c - n)

Edit2: wait, scratch that doesn't really work lol, however it does sorta resemble the the curve, maybe something to think about
[edit on 28-10-2009 by purplemonkey]

[edit on 28-10-2009 by purplemonkey]

[edit on 28-10-2009 by purplemonkey]

posted on Oct, 28 2009 @ 07:04 AM

I see where my mistake was now.

But if either or both are NOT integer values, e.g. (23.76 and 57.9) ... or (237.2 and 673.58) ... or (76 and 142.62) then we modify the two starting numbers by adding 24 to the smaller of the two, and subtracting 1 from the larger of the two as shown here:

I saw the 23.76 number, and the fact that you added 24 to the smaller of the two, and assumed you were rounding the 23.76 up to the next number, 24, and adding that as a seed value for the next iteration.

I reread it and I see what you meant. I will put some more thought into this and see what I can come up with as far as a proof.

This may be a good candidate for proof by contradiction or contrapositive.

posted on Oct, 28 2009 @ 07:09 AM

I'm curious to know what this is about, and why you are so certain that this process will always yield an integer value eventually. I'm also wondering what happens when your values wind up changing places - when your "smaller" number gets 24 added to it so many times that it becomes larger than the "larger" number. Then they swap places, back and forth...

I don't have a rigorous proof yet to conclusively state that "this process will always yield an integer value eventually" but I have run thousands of small scale tests using relatively small prime numbers to create the product ... and in each and every case, integer roots have ALWAYS been generated eventually.
Once the integer roots have been obtained, it's a ludicrously simple arithmetic operation to map both roots onto the original prime numbers that were used.

As for "the values eventually changing places", this in practice has never happened as the integer roots have in each case been reached long before the 1st value has any chance of growing larger than the 2nd value.

posted on Oct, 28 2009 @ 07:12 AM

I see where my mistake was now.

But if either or both are NOT integer values, e.g. (23.76 and 57.9) ... or (237.2 and 673.58) ... or (76 and 142.62) then we modify the two starting numbers by adding 24 to the smaller of the two, and subtracting 1 from the larger of the two as shown here:

I saw the 23.76 number, and the fact that you added 24 to the smaller of the two, and assumed you were rounding the 23.76 up to the next number, 24, and adding that as a seed value for the next iteration.

I reread it and I see what you meant. I will put some more thought into this and see what I can come up with as far as a proof.

This may be a good candidate for proof by contradiction or contrapositive.

Wonderful ... go for it

And sorry if in my eagerness I wasn't as clear as I would have liked to be regarding the addition and subtraction of those values during each iteration ... but you seem to have got the idea now

new topics

0