Re: Surrogate factoring approach, analysis
jstevh_at_msn.com
Date: 01/21/05
- Next message: David Eather: "Re: Surrogate factoring, update on research"
- Previous message: mmeron_at_cars3.uchicago.edu: "Re: What if the Nazis had kindness?"
- Maybe in reply to: Tom St Denis: "Re: Surrogate factoring approach, analysis"
- Next in thread: Bryan Olson: "Re: Surrogate factoring approach, analysis"
- Reply: Bryan Olson: "Re: Surrogate factoring approach, analysis"
- Reply: Lits O'Hate: "Re: Surrogate factoring approach, analysis"
- Reply: jstevh_at_msn.com: "Re: Surrogate factoring approach, analysis"
- Reply: mensanator_at_aol.compost: "Re: Surrogate factoring approach, analysis"
- Messages sorted by: [ date ] [ thread ]
Date: 20 Jan 2005 16:16:18 -0800
I figured, well, why not try.
I'm running the numbers this guy put up through my current program
which is at the Yahoo! group.
Tim Smith wrote:
> In article <1104591454.431335.128080@z14g2000cwz.googlegroups.com>,
> jstevh@msn.com wrote:
> > It turns out that the analysis behind my surrogate factoring
approach is
> > rather easy to walk though with a few basic equations.
> >
> > That should mean I can get people to take me seriously, but you are
> > Usenet, and the problem is held by the math community, so clear
evidence
> > may not work!
>
> All you have to do is show that it works. Here are some composite
numbers
> to test on. Each is the product of two primes whose length is up to
the
> number of bits specified.
>
> Do a couple of examples from the 8 bit or 16 bit section to
illustrate how
> the method actually works, then see if you can do some from the 128
bit
> section.
>
> ====== factors up to 8 bits ======
> 57599
( 239 241 )
I'm copying output from the program, so that's direct output, though I
am leaving out some of the extra information it gives.
> 43139
Skipping...trivially factors as the program has a prime list up to 200.
> 24523
Same as above.
> 34121
Same as above.
> 35953
Same as above.
> 19043
Same as above.
> 33043
Same as above.
> 20567
Same as above, as again, the program automatically will check for
primes up to 200, so these are trivial factorizations for it, not worth
putting up.
> 36089
Same as above.
> 37769
Same as above. Hopefully more interesting below.
>
> ====== factors up to 16 bits ======
> 1996465633
( 35141 56813 )
> 2348221831
Couldn't find factors.
> 3574886741
( 57679 61979 )
> 3172590413
Couldn't find factors.
> 2514657533
Couldn't find factors.
> 1388161393
( 36217 38329 )
> 2335689907
Couldn't find factors.
> 2493433781
( 41879 59539 )
> 1840902013
( 39451 46663 )
> 2095611269
Couldn't find factors.
>
> ====== factors up to 24 bits ======
> 135247262314741
Couldn't find factors.
> 239937525733091
Couldn't find factors.
> 119059652313451
Couldn't find factors.
> 177805283351779
Couldn't find factors.
> 140979690859369
Couldn't find factors.
> 137305167623353
( 11173213 12288781 )
Whew! It's taking a lot longer now as the program really isn't built
for large numbers, yet. It's a proof of concept prototype not built
for speed.
I was worried it might not factor any numbers of this size.
Most of the time is taken with factoring T, the surrogate, and it's
possible that it's not decomposing it fully, but it got at least one.
Each factorization is taken a few minutes now...
> 156432070838873
Couldn't find factors.
I suspect it didn't fully factor T, looking at the factorization it
gave.
For those of you who don't know, T is the surrogate factored to factor
the target, which I call M. Yes, originally in the paper T was to be
the target, but I found my original approach didn't work, and I didn't
feel like changing T in all the equations.
So the program factors T, the surrogate, and then uses that
factorization to get y, and then calculates x, which it checks to see
if it has a gcd with M, the target.
That's how all the factorizations I've given have been done...using my
theory.
> 84697211728937
Couldn't find factors.
> 151766760236149
Couldn't find factors.
> 137083650684517
Couldn't find factors.
<deleted>
The code is at
http://groups.yahoo.com/group/sufactor/
in purple.jar, which does include the source.
Ok, it's took a long while with the numbers above, so I'm stopping
here.
Each attempt was a single pass with j calculated by taking floor(M/2),
getting its residue with respect to 6, and subtracting that. Then T =
M^2 - j^2.
And I used A = 8(92647), and I don't know if that made a difference as
I'm just trying things now.
It is a prototype program, though it is strangely slower than I'd hoped
with these numbers.
And I know, now more of you will make fun of me for such a pathetic
result, but I already said it doesn't factor everything.
If it did, I wouldn't be talking about it publicly.
The question is, what are the limits? Why does it factor some numbers
and not others? It looks from this little experiment like it's getting
worse as the numbers get bigger which is a bad sign, but what are the
mathematical reasons why?
Remember, this is from my theory, a theory you won't find in textbooks,
and if you had Newton write an algorithm based on congruence of squares
soon after he discovered it, would he write the Number Field Sieve?
Think about it before more you yucks decide to make fun of me.
James Harris
- Next message: David Eather: "Re: Surrogate factoring, update on research"
- Previous message: mmeron_at_cars3.uchicago.edu: "Re: What if the Nazis had kindness?"
- Maybe in reply to: Tom St Denis: "Re: Surrogate factoring approach, analysis"
- Next in thread: Bryan Olson: "Re: Surrogate factoring approach, analysis"
- Reply: Bryan Olson: "Re: Surrogate factoring approach, analysis"
- Reply: Lits O'Hate: "Re: Surrogate factoring approach, analysis"
- Reply: jstevh_at_msn.com: "Re: Surrogate factoring approach, analysis"
- Reply: mensanator_at_aol.compost: "Re: Surrogate factoring approach, analysis"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|