POSTMORTEM

"4096 bit ~ 96 hours is what he said.

IDK why, but when he took the challenge, he posted that it'd take 36 hours"

As @cbsa wrote, and nitwhiz wrote "but the statement was that op's i3 did it in 11 hours. So there must be a result already, which can be verified?"

I added time because I was in the middle of a port involving ArbFloat so I could get arbitrary precision. I had a crude desmos graph doing projections on what I'd already factored in order to get an idea of how long it'd take to do larger
bit lengths

@p100sch speculated on the walked back time, and overstating the rig capabilities. Instead I spent a lot of time trying to get it 'just-so'.
Worse, because I had to resort to "Decimal" in python (and am currently experimenting with the same in Julia), both of which are immutable types, the GC was taking > 25% of the cpu time.

Performancewise, the numbers I cited in the actual thread, as of this time:
largest product factored was 32bit, 1855526741 * 2163967087, took 1116.111s in python.
Julia build used a slightly different method, & managed to factor a 27 bit number, 103147223 * 88789957 in 20.9s,
but this wasn't typical.

What surprised me was the variability. One bit length could take 100s or a couple thousand seconds even, and a product that was 1-2 bits longer could return a result in under a minute, sometimes in seconds.

This started cropping up, ironically, right after I posted the thread, whats a man to do?

So I started trying a bunch of things, some of which worked. Shameless as I am, I accepted the challenge. Things weren't perfect but it was going well enough. At that point I hadn't slept in 30~ hours so when I thought I had it I let it run and went to bed. 5 AM comes, I check the program. Still calculating, and way overshot. Fuuuuuuccc...
So here we are now and it's say to safe the worlds not gonna burn if I explain it seeing as it doesn't work, or at least only some of the time.

Others people, much smarter than me, mentioned it may be a means of finding more secure pairs, and maybe so, I'm not familiar enough to know.

For everyone that followed, commented, those who contributed, even the doubters who kept a sanity check on this without whom this would have been an even bigger embarassement, and the people with their pins and tactical dots, thanks.

So here it is.
A few assumptions first.
Assuming p = the product,
a = some prime,
b = another prime,
and r = a/b (where a is smaller than b)
w = 1/sqrt(p)
(also experimented with w = 1/sqrt(p)*2 but I kept overshooting my a very small margin)

x = a/p
y = b/p

1. for every two numbers, there is a ratio (r) that you can search for among the decimals, starting at 1.0, counting down. You can use this to find the original factors e.x. p*r=n, p/n=m (assuming the product has only two factors), instead of having to do a sieve.

2. You don't need the first number you find to be the precise value of a factor (we're doing floating point math), a large subset of decimal values for the value of a or b will naturally 'fall' into the value of a (or b) + some fractional number, which is lost. Some of you will object, "But if thats wrong, your result will be wrong!" but hear me out.

3. You round for the first factor 'found', and from there, you take the result and do p/a to get b. If 'a' is actually a factor of p, then mod(b, 1) == 0, and then naturally, a*b SHOULD equal p.
If not, you throw out both numbers, rinse and repeat.

Now I knew this this could be faster. Realized the finer the representation, the less important the fractional digits further right in the number were, it was just a matter of how much precision I could AFFORD to lose and still get an accurate result for r*p=a.

Fast forward, lot of experimentation, was hitting a lot of worst case time complexities, where the most significant digits had a bunch of zeroes in front of them so starting at 1.0 was a no go in many situations. Started looking and realized
I didn't NEED the ratio of a/b, I just needed the ratio of a to p.

Intuitively it made sense, but starting at 1.0 was blowing up the calculation time, and this made it so much worse.

I realized if I could start at r=1/sqrt(p) instead, and that because of certain properties, the fractional result of this, r, would ALWAYS be 1. close to one of the factors fractional value of n/p, and 2. it looked like it was guaranteed that r=1/sqrt(p) would ALWAYS be less than at least one of the primes, putting a bound on worst case.

The final result in executable pseudo code (python lol) looks something like the above variables plus

while w >= 0.0:
if (p / round(w*p)) % 1 == 0:
x = round(w*p)
y = p / round(w*p)
if x*y == p:
print("factors found!")
print(x)
print(y)
break
w = w + i

Still working but if anyone sees obvious problems I'd LOVE to hear about it.

Last week I was erasing a 2Gb USB thumb while copying some really important shit to my backup disk. I look at the terminal and see it's taking a lot of time to did zeroes on dev/sdb.
Then I realized that dev/sdb is the backups drive and I just erased the firsts sectors of my only fucking backup.
It's ok, I said, let's see what can TestDisk do for me. And it only could find an empty sad partition that had useless shit on it. Whdd couldn't even find the drive. Cat and dd vomited 160Gb of nothing to a file that couldn't be read. I was lost, because I failed doing something I'm really good at. And I did it because I was to stupid to check fstab...
It's the very first time I couldn't recover data, so I'm thinking about delete "Data recovery" from my resume skills and put "Data cleaning. Really effective. I can send you 160Gb of pure horse shit to prove it" instead.

So I'm wrapping up for the day and right before I leave a coworker comes up to me with a problem. Our company uses barcodes to track some of our products through their development and we recently switched over to a new system for producing them. The barcodes for this particular product are supposed to have 8 digits, but the last 200 we printed have 9.

I immediately panic because I wrote the script that generates the bar codes and there had been a bug in the past where the script would add extra leading zeroes that weren't supposed to be there. I scramble and check the database, it would be a huge headache if our production database had been compromised with junk barcodes. Nope, all the new barcodes there have the right number of digits.

Next place to check is in the code that writes the barcodes to a text file for staff to print the physical labels from. Nope that's all fine too.

I ask the person who printed out the recent batch of labels to show me how the printing software reads from the text file. She seems confused by my question and shows me how she manually enters in the barcode range to the software. As she does this I watch her add an extra zero to the numbers. 🙃

Even worse there was an option to import all the codes from a text file literally RIGHT BELOW the manual option.

TLDR; Thought my script had screwed up our database, ended up being the fault of a coworker who didn't know how to import text files.

The more I work with performance, the less I like generated queries (incl. ORM-driven generators).

Like this other team came to me complaining that some query takes >3minutes to execute (an OLTP qry) and the HTTP timeout is 60 seconds, so.... there's a problem.

Sure, a simple explain analyze suggests that some UIDPK index is queried repeatedly for ~1M times (the qry plan was generated for 300k expected invocations), each Index Scan lasts for 0.15ms. So there you go.. Ofc I'd really like to see more decimal zeroes, rather than just 0.15, but still..

Rewriting the query with a CTE cut down the execution time to pathetic 0.04sec (40ms) w/o any loops in the plan.

I suggest that change to the team and I am responded a big fat NO - they cannot make any query changes since they don't have any control on their queries

....
*sigh*
....
*sigh*
but down to 0.04sec from 3+ minutes....
*sigh*

alright, let's try to VACUUM ANALYZE, although I doubt this will be of any help. IDK what I'll do if that doesn't change the execution plan :/ Prolly suggest finding a DBA (which they won't, as the client has no € for a DBA).

All this because developers, the very people sho should have COMPLETE control over the product's code, have no control over the SQLs.

This sucks!

my 4TB Seagate HDD is failing in a very strange way:

I noticed an issue where my PC would just outright hang for a minute or two occasionally when swapping to the 4TB HDD. When I look at logs, when it hangs, the 4TB HDD times out but then on a retry IMMEDIATELY reads whatever sector just fine. In fact, it reads fine constantly for a few days until the same sector has an issue. So, the timeout is a remap, then? No, as the spare sector and bad sector counts in the SMART info don't change. It doesn't even change how many read errors or anything it's had. Strange, but let's test it with Seatools to be sure.

Tests go as follows:

- Short: pass
- Short: pass
- Long: seatools immediately crashes. Reopening seatools, it pulled a serial of all zeroes... okay....?
- Long: seatools immediately crashes. Seatools gets the right serial on reopen.
- Long: pass
- Long: fail
- Long: pass
- Long: seatools immediately crashes. All zero serial again.

i have no idea what's happening

Write ones and zeroes.

I just got my third 128GB MicroSD card off Amazon, this time SanDisk. Yet again, trying to do anything not involving the OEM full-disk exFAT partition staying intact (which, fuck that, all that uses that is Windows and Linux, i'm looking for splitting this thicc bih up) shifts EVERYTHING, including MBR+PT/GPT down the disk by 16MB exactly inserting data from... the atmosphere? whatever's using it? ...do SD cards have that secure key/DRM store space thing still?

(EDIT: I do verify that they ARE genuinely the right size after purchasing before reformatting or repartitioning, by the way.)

First it was a Silicon Power card, then a Samsung card, now a SanDisk.

(Also, why all S?)

Luckily, this time it wasn't a pain in the ass to get it to read as anything but "Bad Card" or a 0-byte/empty/non-existent device in Windows/Linux (respectively) so I was able to see that it was indeed the same issue without taking 3 days to jump through device hoops to finally get it to do it again but in such a way that it shifts out and back in all zeroes.

Do something physical where I can see the result.
Paint that bookshelf that I would do one day. Organize the big pile of mess in the storage, plant something in the garden. Something where you are reminded when you see it: ohh I fixed that and feel proud.
Organize ones and zeroes are sometimes a bit abstract for the primitive brain to give that fulfillment feeling.

my APAP's SD card died and I had a generic 2GB one kicking around unused
>formats as FAT16
>inserts
UNAUTHORIZED CARD
>hmm
>zeroes drive
>forgets to reformat
>inserts
Formatting SD Card... done.
Space available: 1.8GB
Set as Primary Log Storage
>:megathink:
>checks format
>FAT16
>reinserts
UNAUTHORIZED CARD
>wipes MBR/PT
Formatting SD Card... done.
Space available: 1.8GB
Set as Primary Log Storage

and that's the story of how i managed to not need to spend $200 on a proprietary SD card for my APAP

Very early on I was putting together my first database-driven web app and decided to use record IDs with leading zeroes - you know, because that would look neater. It was a long, long time before I came to know that a number with a leading zero would be evaluated as octal, which in turn meant that any number with an 8 or a 9 in it was invalid, which then meant it would be a match for any other invalid number and retrieve a seemingly random record.

I need to tell you the story of my MOAB (Mother of all bugs).
I need to write some stuff in C (which i am fairly used to) and have a function that allocates memory for a Matrix on the heap. The matrix has a rows and columns property and an associated data array, so it looks like this
struct Matrix{
uint8_t rows;
uint8_t columns;
uint8_t data[];
}
I allocate rows*columns + 2 bytes of memory for it.
I also have a function to zero it out which does something like this
for(int i=0; i < rows*columns;i++){
data[i]=0;}

Let‘s come to the problem:
On my Mac the whole stuff works and passes all tests. We tried the code on a Linux machine and suddenly the code crashed in various places, sometimes a realloc got an invalid pointer, sometimes free got an invalid pointer and basically the code crashed at arbitrary points randomly.
I was confused af because did i really make THAT many errors?

I found out that all errors occured when testing my matrices so i looked more into it and observed it through the debugger.

Eventually i came to the function that zeroes out my matrix and it went unusually high and wondered if my matrix really was that big.
Then i saw it
The matrix wasn‘t initialised yet
It had arbitrary data that was previously in the heap.
It zeroed out a huge chunk of the heap space.
It literally wrote a zero to a shitload of addresses which invalidated many pointer.

You can imagine my facepalm

The bug: Some string values for an identifier property in the data objects are being sent from our frontend prefixed with a '0'. Sometimes. When it happens, it usually gets stripped away again by the time it's passed to our backend. But not always.

This 0 is never explicitly set anywhere. I even searched for a few variants of " = 0" in both the frontend and backend projects without receiving any results. You might already be suspecting where this is going.

So it turns out.

The data object which holds this value is being initialized in the aspnet (don't ask) backend and passed to the frontend, which then hydrates it. This value is always an integer number, albeit incidentally so which is why string is used as the actual type. When this object is initialized, it's hardcoded with an anonymous type where this property is set as int because I guess someone figured "it's always an int though". Being a typed language, primitive scalars can't be null objects which means the property's value becomes the concrete int 0.

Okay weird. I can think of better ways of doing this but let's just set it to string as I can't start overhauling things right now. Let's just go find where this value is somehow concatenated into the incoming parameter.

You see, this happens because at the point where the frontend sets this value, it may be an int or string depending on where it came from, and I guess someone figured that in order to cast it to string you just go prop += arg seeing as the prop is empty string and all. Because explicitly casting it or - as much as I get a rash whenever I see it - going prop = "" + arg would be too verbose and unoriginal.

Bonus round: How come the 0 only sometimes made it all the way to our backend? The thing is that this bug has been fixed before. The fix is that because this string is "always" an int, you can parse it to int before passing it to the backend in case it has leading zeroes. This path is only taken in certain views because someone forgot to copypaste their fix into all the places this is repeated.

Sometimes you find a bug and you are just somehow more grumpy after fixing it.

there wasn't a quick format option for mkfs.ntfs right

I wish I could play the guitar like Jimi Hendrix, sing like Meatloaf, write like Terry Pratchett and make ones and zeroes dance to my tune as Linus Torvalds.
But I need is a good woman's love.
So I have what I need so I'm happy.