My mind just balks at the idea of having so much source that a 2020s computer could take hours to index it. ctags is nothing special (both in terms of optimization but also the level of detail it gets to: just global function identifiers) and looks like it runs at about 400MB/s on a single core of an i5-1235U. But still it looks ctags could process about 100TB in 4 hours across 16 threads on a workstation class CPU...
Readit Newsjepler commented on Indexing Code at Scale with Glean engineering.fb.com/2024/1... · Posted by u/GavCo
According to http://comopt.ifi.uni-heidelberg.de/software/TSPLIB95/STSP.h... the optimal solution for eil51 is 426 (the linked page has a tour of 428.87) and the optimal solution for st70 is 675 (the linked page has a tour of 677.11).
jepler commented on A complex bug with a ⸢simple⸣ fix blog.plover.com/prog/bug/... · Posted by u/PaulHoule
I wonder whether you still have a bug. It depends how "scanning" is implemented.
23:55 start scanning
23:59:59 message added
00:00:01 perform timestamp check
You also mentioned a directory being created 5 minutes early: what if some system has a clock skewed the opposite way, and puts a message in a directory 5 minutes late instead?
id prefer it if you would write this in haskell so i can understand what is going on there better. i am saying of the first 1,000 digits after the ones place, each digit of the sequence appears an even number of times, every consecutive subsequence of two appears an even number of times, and every consecutive subsequence of three happens exactly once. please, if you could do some more intelligable work and show your result as standard deviations away from the the exact de bruijn counts i would really appreciate it. etcetcera.
(i dont know where you got the 10 symbols from. im talking about over the entire 1,000 length decimal sequence. etcetera.)
I don't know Haskell, so I can imagine if you didn't know Python it'd be "greek to you" (unintelligible). I'll try explaining in prose what I did. [note: I also edited the grandparent comment because when I simplified the session I showed, the assignment of "s" ended up out of order]
I use the Python decimal package to calculate 17^(1/7) to 4000 decimal places. I show the first 12 characters of the ASCII representation ("1.4989198720"), then take the first 1000 characters after the decimal place. I show the first and last 10 characters of this string ("4989198720...6163659068") so that you can verify it against the string you are testing.
Then I use a list comprehension to check each 3-digit string (e.g., 001, 002, 003, ..., 999) to find out whether it is a substring of the concatenation of `s` with itself, and list the ones that don't appear. I manually abbreviated the list, but I'm saying that in my string, 000, 002, 004, 005, 009, [and some other numbers], 993, 994, 995, 998, and 999 did not appear. (The concatenation `s+s` is checked so that the subsequences that occur at the wraparound---here,684 and 849---are found)
Because some of these length-3 sequences are missing, to my understanding this does not constitute a de Bruijn sequence of order 3 on a size-10 alphabet. However, I'm also not entirely sure whether this is what you were claiming.
assuming you mean the decimal expansion and a length-3 de bruijn sequence on 10 symbols, I am not seeing it. There seem to be many sub-sequences which do not appear. (assuming that python's Decimal library at a precision of 4000 digits is actually giving the first 1000 digits correctly; though I have no reason to doubt this I don't know for sure the maximum ULP error of exponent)
Python 3.11.2 (main, Sep 14 2024, 03:00:30) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from decimal import Decimal, getcontext
>>> getcontext().prec = 4000
>>> d = 17 ** (1 / Decimal(7))
>>> sd = str(d)
>>> sd[:12]
'1.4989198720'
>>> s = sd[2:][:1000]
>>> s[:10], s[-10:]
('4989198720', '6163659068')
>>> [i for i in range(1000) if "%03d" % i not in s+s]
[0, 2, 4, 5, 9, [...], 993, 994, 995, 998, 999]
>>> len(_)
361jepler commented on All Python Downloads from Python.org Return 403 Forbidden python.org/ftp/python/3.1... · Posted by u/vxxzy
No downtime noted yet at https://status.python.org/ but confirmed from here
and it's back now. No incidents reported on status.python.org.
there was some discussion on at least two github issues: https://github.com/python/cpython/issues/127307 and https://github.com/python/pythondotorg/issues/2663
jepler commented on All Python Downloads from Python.org Return 403 Forbidden python.org/ftp/python/3.1... · Posted by u/vxxzy
No downtime noted yet at https://status.python.org/ but confirmed from here
jepler commented on Researchers crack RSA and AES data encryption thebrighterside.news/post... · Posted by u/msszczep2
Too tired to find the actual debunking of these claims but no, d-wave is not effective for cryptanalysis of RSA or AES as deployed.
The papers claim some interesting but not game-changing results on factorization of tiny primes and attacking toy, reduced round cryptosystems that resemble AES in a particular way.
I think ANIL might not be a great name. Let me know if you need clarification ;)
Anil is a given first name, maybe just not in your culture.
You're right! I am not a Rust programmer and mis-read the "i32" as "float32".
The text does imply the correct float solution has a similar structure to the int32 case, with "So, you will have to resort to writing machine code manually if you want to efficiently check overflows of float numbers."
You don't need machine code these days to find overflow in IEEE floating point arithmetic.
If any intermediate sum overflows, you get an infinity. Further arithmetic can never return you to the realm of finite numbers (though you can also get into the world of "not a number" NaNs by calculating -inf + inf for instance), so you can use a standard function like (C99 <math.h>) isfinite() to check if any intermediate step of summing FP numbers overflowed the representation.