rant!

tl;dr
fucked up shithead families with their entitlements
/tl;dr

What a line-up.

https://devrant.com/rants/4504247/...

One would have to be badass to just get out alive such families.

Is it a dev thing to strive for halfway decent acceptance or drive a no shit head policy?
Or just being able to find and accept people on their intent and thrive through (self) improvement?

I cut ties to four fifth of the family because of their meth head characters and the damage they impose on their direct, secondary and third party environment.

Hall of Fame of recent comments :

"If there were no information technology, every human had a job and there were no homeless people."
This brother of mine says to me while I helped him moving to a raging nazi shithole without water, electricity, roof, or sewers.
To the exact only one person of the family working in information technology.
Thanks.

Uhm. No. And there would still be machines and, well, the wheel?
Kthxbye!

!rant
Fewd! on devrant meetup Nijmegen Jan 4th '20
Referring to https://devrant.com/rants/2341210/...

Been scouting restaurants and cafés last sunday. Nine candidates, from collab spaces, bars to restaurants.

We have a city centre at hand.

Whereas three collab spaces been closed (Sunday) and won't open within our desired times. The 'coffee lovers' is a minimalistic bar at the city's public library, not explicitly offering space for meet ups. And the Honigs' house coffee bar does only serve business hours.

Three remain on my short list:
- Cafe Jos meesterschenkereij
Snacks, beer ( 80+++ brands) and whiskey, very cosy, 15min simple public transports.
- eetcafe goed volk
Vegan food, wine, classy, 15min simple public transports.
- Cafe Faber
Rustical, beer n standards, built for tall peoplere, total city centre.

All three can specially accommodate us that evening.

Anyways. The city is full of bars n stuff.
I'd like to side our choice with a survey (scientifically personal data friendly) :
https://terminplaner4.dfn.de/AMGaFX...

After learning a bit about alife I was able to write
another one. It took some false starts
to understand the problem, but afterward I was able to refactor the problem into a sort of alife that measured and carefully tweaked various variables in the simulator, as the algorithm
explored the paramater space. After a few hours of letting the thing run, it successfully returned a remainder of zero on 41.4% of semiprimes tested.

This is the bad boy right here:
tracks[14]
[15, 2731, 52, 144, 41.4]

As they say, "he ain't there yet, but he got the spirit."

A 'track' here is just a collection of critical values and a fitness score that was found given a few million runs. These variables are used as input to a factoring algorithm, attempting to factor
any number you give it. These parameters tune or configure the algorithm to try slightly different things. After some trial runs, the results are stored in the last entry in the list, and the whole process is repeated with slightly different numbers, ones that have been modified
and mutated so we can explore the space of possible parameters.

Naturally this is a bit of a hodgepodge, but the critical thing is that for each configuration of numbers representing a track (and its results), I chose the lowest fitness of three runs.
Meaning hypothetically theres room for improvement with a tweak of the core algorithm, or even modifications or mutations to the
track variables. I have no clue if this scales up to very large semiprime products, so that would be one of the next steps to test.

Fitness also doesn't account for return speed. Some of these may have a lower overall fitness, but might in fact have a lower basis
(the value of 'i' that needs to be found in order for the algorithm to return rem%a == 0) for correctly factoring a semiprime.

The key thing here is that because all the entries generated here are dependent on in an outer loop that specifies [i] must never be greater than a/4 (for whatever the lowest factor generated in this run is), we can potentially push down the value of i further with some modification.

The entire exercise took 2.1735 billion iterations (3-4 hours, wasn't paying attention) to find this particular configuration of variables for the current algorithm, but as before, I suspect I can probably push the fitness value (percentage of semiprimes covered) higher, either with a few
additional parameters, or a modification of the algorithm itself (with a necessary rerun to find another track of equivalent or greater fitness).

I'm starting to bump up to the limit of my resources, I keep hitting the ceiling in my RAD-style write->test->repeat development loop.
I'm primarily using the limited number of identities I know, my gut intuition, combine with looking at the numbers themselves, to deduce relationships as I improve these and other algorithms, instead of relying strictly on memorizing identities like most mathematicians do.
I'm thinking if I want to keep that rapid write->eval loop I'm gonna have to upgrade, or go to a server environment to keep things snappy.

I did find that "jiggling" the parameters after each trial helped to explore the parameter
space better, so I wrote some methods to do just that. But what I wouldn't mind doing
is taking this a bit of a step further, and writing some code to optimize the variables
of the jiggle method itself, by automating the observation of real-time track fitness,
and discarding those changes that lead to the system tending to find tracks with lower fitness.

I'd also like to break up the entire regime into a training vs test set, but for now
the results are pretty promising.

I knew if I kept researching I'd likely find extensions like this. Of course tested on
billions of semiprimes, instead of simply millions, or tested on very large semiprimes, the
effect might disappear, though the more i've tested, and the larger the numbers I've given it,
the more the effect has become prevalent.

Hitko suggested in the earlier thread, based on a simplification, that the original algorithm
was a tautology, but something told me for a change that I got one correct. Without that initial challenge I might have chalked this up to another false start instead of pushing through and making further breakthroughs.

I'd also like to thank all those who followed along, helped, or cheered on the madness:
In no particular order ,demolishun, scor, root, iiii, karlisk, netikras, fast-nop, hazarth, chonky-quiche, Midnight-shcode, nanobot, c0d4, jilano, kescherrant, electrineer, nomad,
vintprox, sariel, lensflare, jeeper.

The original write up for the ideas behind the concept can be found at:
https://devrant.com/rants/7650612/...

If I left your name out, you better speak up, theres only so many invitations to the orgy.
Firecode already says we're past max capacity!

So I made a couple slight modifications to the formula in the previous post and got some pretty cool results.
The original post is here:
https://devrant.com/rants/5632235/...

The default transformation from p, to the new product (call it p2) leads to *very* large products (even for products of the first 100 primes).

Take for example
a = 6229, b = 10477, p = a*b = 65261233

While the new product the formula generates, has a factor tree that contains our factor (a), the product is huge.

How huge?
6489397687944607231601420206388875594346703505936926682969449167115933666916914363806993605...
and

So huge I put the whole number in a pastebin here:
https://pastebin.com/1bC5kqGH

Now, that number DOES contain our example factor 6229. I demonstrated that in the prior post.
But first, it's huge, 2972 digits long, and second, many of its factors are huge too.

Right from the get go I had hunch, and did (p2 mod p) and the result was surprisingly small, much closer to the original product. Then just to see what happens I subtracted this result from the original product.

The modification looks like this:

(p-(((abs(((((p)-(9**i)-9)+1))-((((9**i)-(p)-9)-2)))-p+1)-p)%p))
The result is '49856916'
Thats within the ballpark of our original product.

And then I factored it.
1, 2, 3, 4, 6, 12, 23, 29, 46, 58, 69, 87, 92, 116, 138, 174, 276, 348, 667, 1334, 2001, 2668, 4002, 6229, 8004, 12458, 18687, 24916, 37374, 74748, 143267, 180641, 286534, 361282, 429801, 541923, 573068, 722564, 859602, 1083846, 1719204, 2167692, 4154743, 8309486, 12464229, 16618972, 24928458, 49856916

Well damn. It's not a-smooth or b-smooth (where 'smoothness' is defined as 'all factors are beneath some number n')
but this is far more approachable than just factoring the original product.

It still requires a value of i equal to
i = floor(a/2)

But the results are actually factorable now if this works for other products.

I rewrote the script and tested on a couple million products and added decimal support, and I'm happy to report it works.
Script is posted here if you want to test it yourself:
https://pastebin.com/RNu1iiQ8

What I'll do next is probably add some basic factorization of trivial primes
(say the first 100), and then figure out the average number of factors in each derived product.

I'm also still working on getting to values of i < a/2, but only having sporadic success.

It also means *very* large numbers (either a subset of them or universally) with *lots* of factors may be reducible to unique products with just two non-trivial factors, but thats a big question mark for now.

@scor if you want to take a look.