seejayjames

I have a prime factorization patch that seems to work fine up until prime number 239. I have no freaking clue why it generates a stack overflow at that point, all composite and prime numbers below that are totally fine. Prime numbers over 256 seem to crash Max even more thoroughly, which might make more sense, though I'm not using any objects with that limitation (zl, yes, but it's used to read the length of the prime factor list, nowhere ever near 256).

The subpatch with the factorization seems to be totally OK (though messy) and I can't figure out why it would overflow at this specific point. I figured (with enough numbers in the counter as possible prime factors) that any number would be OK to factor (with the counter range up to the square root of the main number).

Yes, I *do* have a javascript that factors any number just fine, but I wanted to try and figure it all out in Max. Maybe not the best idea as it's taken a long time, but it would be nice to understand what's causing the overflow if anyone has some ideas. Also wondering if others get the same overflow error at the same point (239).

There's a warning next to the overflow-causing number, so be careful. ;)

Yes, I *do* have a javascript that factors any number just fine, but I wanted to try and figure it all out in Max. Maybe not the best idea as it's taken a long time, but it would be nice to understand what's causing the overflow if anyone has some ideas. Also wondering if others get the same overflow error at the same point (239). 

There's a warning next to the overflow-causing number, so be careful.  ;)

anyone-dare-to-tackle-a-stack-overflow-problem

Patches with a lot of cosmetics and lots of crossing patch cords underneath are never a good start for debugging. The first thing I would do is isolate different parts of your patch into plain (and aligned) patches. This most likely leads to the source of the problem.

yeah mon, they created the patcher object for a reason. try and think of parts of your patch as separate functions and isolate accordingly.

yeah mon, they created the patcher object for a reason.  try and think of parts of your patch as separate functions and isolate accordingly.


Your points are very well taken, I wish I could get out of the "put everything into one patch" problem. Will work on it, as well as cleaning my apartment---which kind of looks like a bad Max patch at the moment, heh. Maybe there's a connection there.

Here's the same thing stripped down to as small as I can get it and still factorize. Now it overflows at 241 and above primes. I have NO CLUE, I think it should be totally OK for any value, realistically. Is it something about *overall* speed of execution that's stumping me? Why shouldn't this work for valules up to 90000 (square of maximum of counter)?!

Thanks, am very curious about this, probably just OCD...!

Here's the same thing stripped down to as small as I can get it and still factorize. Now it overflows at 241 and above primes. I have NO CLUE, I think it should be totally OK for any value, realistically. Is it something about *overall* speed of execution that's stumping me?  Why shouldn't this work for valules up to 90000 (square of maximum of counter)?!

Without studying how your patch works I think it can be tidied up a lot.

I guess you could use good old Trace on this patch and get an idea of what is actually going on.

> Here's the same thing stripped down to as small as I can get it and

> still factorize. Now it overflows at 241 and above primes. I have NO

> CLUE, I think it should be totally OK for any value, realistically.

> Is it something about *overall* speed of execution that's stumping

> me? Why shouldn't this work for valules up to 90000 (square of

> Thanks, am very curious about this, probably just OCD...!

There is feedback in your algorithm. If your break condition is reached

fast this seems fine. But the stack you need will grow exponentially,

its only a matter of time(size) to blow it up.

Usually deferlow somewhere in the feedback loop will help in those

cases. But be careful with your order of execution...

It will slow things down, the Java solution is crossplatform as well,

and last not least, memory is cheap, I came to the conclusion when doing

something similar, to just fill a buffer~ with all primes representable

Seejay James schrieb:
> Here's the same thing stripped down to as small as I can get it and
> still factorize. Now it overflows at 241 and above primes. I have NO
> CLUE, I think it should be totally OK for any value, realistically.
> Is it something about *overall* speed of execution that's stumping
> me?  Why shouldn't this work for valules up to 90000 (square of
> maximum of counter)?!
>
> Thanks, am very curious about this, probably just OCD...!

There is feedback in your algorithm. If your break condition is reached
fast this seems fine. But the stack you need will grow exponentially,
its only a matter of time(size) to blow it up.

Usually deferlow somewhere in the feedback loop will help in those
cases. But be careful with your order of execution...

It will slow things down, the Java solution is crossplatform as well,
and last not least, memory is cheap, I came to the conclusion when doing
something similar, to just fill a buffer~ with all primes representable
in 32bit int should be the way to go...

-- 
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


Seejay James schrieb:
> Here's the updated patch

-- 
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com

Anyone dare to tackle a stack overflow problem?