Rendered at 09:21:14 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
hyperhello 16 hours ago [-]
For those who don’t have math extensions in the browser, if that is 2^0.6039, then why don’t math extensions just detect math syntax and style it directly?
tikhonj 15 hours ago [-]
I mean, in this case, it's 2^{0.6039n}, and the n is pretty important. I can see why trying to automatically detect cases like this would run into a bunch of wrong behaviors (either styling text that was not meant to be math notation, or parsing the implied math notation incorrectly).
hyperhello 15 hours ago [-]
Okay, I had the problem going the other way. I assumed the n was a symbol on the previous number, like an f suffix in C. But even still, 2^(0.6039n) could have been rendered in a nice way stripping out the parenthesis, leaving the core text mathematically correct.
altairprime 14 hours ago [-]
Email the mods to have the title edited, hn@ycombinator.com; it’s a worthwhile change here.
“in 2^[0.6039n+o(n)] time” could be a better edit than the paper’s provided title, though I selected [] rather than {} for human use. I defer to experts in the field on whether it matters to declare O(n) or not.
traes 13 hours ago [-]
Changing {} to [] seems like a very strange suggestion to me. {} is used here because it's the way you group things in LaTeX. If you were going to change it for human use, why not just use parenthesis? What's wrong with {} in the first place?
altairprime 13 hours ago [-]
Sure, that’s fine too. Whatever makes more sense than the current title is an improvement, and I can’t judge what’s best for this audience.
shiandow 13 hours ago [-]
You'll want small o, not big O. Otherwise there's no point in mentioning the constant factor 0.6039.
And yes the o(n) is relevant. Though I guess implied to some extent.
altairprime 13 hours ago [-]
Oops, fixed!
teddyh 13 hours ago [-]
You mean 2⁰·⁶³⁹ⁿ
18 hours ago [-]
abetusk 12 hours ago [-]
Could someone summarize what the main idea is for this method?
GracefullyShot 16 hours ago [-]
could this be a problem for the security of Falcon (aka FN-DSA) post quantum signature scheme?
mswphd 16 hours ago [-]
not really. The hardness of SVP is relevant, but this is a paper giving improved provable bounds for SVP algorithms. heuristically (which people use to choose parameter sizes etc) people assume SVP is much easier to solve, closer to 2^{.29n + o(n)}.
So it's tangentially related, but does not itself imply an improvement on the (heuristically assumed) SOTA for these problems.
pretzellogician 17 hours ago [-]
Wow, just yesterday I was thinking this exact problem would be a good candidate for AI. Seems it is!
slwvx 16 hours ago [-]
I was very happy to see an "AI use disclosure" right on the title page under the abstract.
It's not clear if this is solely a possible theoretical result or if it has any practical value. I.e. is it only useful on lattices that are so large as to not be of use, or could it be used for cryptanalysis? If one is using AI to generate a theory paper such as this, why not use the AI to also generate code that uses it, put it on GitHub, and show the results, say against fplll and the tool in the paper below?
“in 2^[0.6039n+o(n)] time” could be a better edit than the paper’s provided title, though I selected [] rather than {} for human use. I defer to experts in the field on whether it matters to declare O(n) or not.
And yes the o(n) is relevant. Though I guess implied to some extent.
So it's tangentially related, but does not itself imply an improvement on the (heuristically assumed) SOTA for these problems.
It's not clear if this is solely a possible theoretical result or if it has any practical value. I.e. is it only useful on lattices that are so large as to not be of use, or could it be used for cryptanalysis? If one is using AI to generate a theory paper such as this, why not use the AI to also generate code that uses it, put it on GitHub, and show the results, say against fplll and the tool in the paper below?
https://ir.cwi.nl/pub/35237/35237.pdf