Iburinoc
Iburinoc on Hacker News
Addition/subtraction are also much simpler/cheaper than they would be in an entirely logarithmic model. If floats were just 2^x with some 64 bit fixed point x, it's not clear to me how to do addition efficiently.
The "200 basis point spread" comes from the difference between the very low or non-existent interest paid on the cash in brokerage accounts and the rates the brokerage can earn by lending that money out basically risk-free. If you keep 10% of your assets in cash, a 200 bp interest spread becomes effectively a 20 bp management fee on your assets.
The problem being solved essentially is: you have two binary strings, and you want to offset one of them so that they match up the best. For each offset, you're taking a dot product of one sequence with the offset version of the other. This is the same as computing the convolution of the two sequences together (
https://en.wikipedia.org/wiki/Convolution). Computing this naively would be O(n^2) (doing linear work for each possible offset).
One property of the Fourier transform is that convolution in the time domain corresponds to element-wise multiplication in the frequency domain (https://en.wikipedia.org/wiki/Convolution_theorem), so you can compute the convolution efficiently by taking the FFT of both series, doing element-wise multiplication, and then taking the inverse FFT of the result.
In general, xz beats zstd in compression ratio, as xz is very committed to providing the strongest compression, at the expense of speed, while zstd provides a range of compression ratio vs speed tradeoffs [0]. At the lower levels, zstd isn't approaching xz's compression level, but it's doing it much much faster. Additionally, zstd generally massively outperforms xz in decompression speed
$ time xz linux-4.14-rc6.tar
real 4m26.009s
user 4m24.828s
sys 0m0.724s
$ wc -c linux-4.14-rc6.tar.xz
103705148 linux-4.14-rc6.tar.xz
$ time zstd --ultra -20 linux-4.14-rc6.tar
linux-4.14-rc6.tar : 12.81% (824350720 => 105564246 bytes, linux-4.14-rc6.tar.zst)
real 4m34.129s
user 4m33.484s
sys 0m0.432s
$ time cat linux-4.14-rc6.tar.xz | xz -d > out1
real 0m9.677s
user 0m6.608s
sys 0m0.704s
$ time cat linux-4.14-rc6.tar.zst | zstd -d > out2
real 0m1.702s
user 0m1.220s
sys 0m0.520s
[0]:
https://github.com/facebook/zstd/blob/dev/doc/images/DCspeed...
Well sure, but from an asymptotic approach both unsorted and sorted are "linear", so asymptotics don't necessarily provide enough information to answer GP's question.
The article mentions the applicable exception:
> Everyone who is born in Canada is eligible for Canadian citizenship, with one exception: those who are born to employees of foreign governments.
I'm not sure where you are but I find it quite uncommon for university students.
I'm not sure about the US but in Canada it's certainly not true that everyone has data plans (in fact as far as I can tell unless you have a company sponsored phone, data plans are in the minority), and SMS remains a cheap communication method that is more or less guaranteed to work.
Perhaps I misunderstand you but since it's HTTPS, in theory there are no MITM attacks.
This looks cool really cool! I like the site, however it can be hard to read the text with the flashy background. Perhaps have the flashy background scroll up with the first "panel"?
On the crypto side of things, are there any plans to create native clients? While I don't doubt that you guys are trustworthy, it would be nice if I didn't have to trust that the javascript I was being served didn't change between visits.
All in all it looks good, albeit with some trust issues...
While that is true, part of the contents that is hashed is the time of commit. Therefore if you (somehow...) managed to get that hash, you could just reset and commit again. Or amend.
In any case, I believe he was joking. The odds of a sha1 collision are very very low.
Ok, thanks for the reply. Do you guys have any plans to try client-side encryption at some point in the future and/or do file encryption as well? I have to agree with kenrikm to some degree, if the encryption and decryption is all done server side then we are really just trusting you not to cheat (Not saying you're untrustworthy, but it does seem to be a service built on security, which is a field in which I'd rather trust as few people as possible).
Looks interesting, although more information on the encryption schemes used, how the key is stored/represented/generated would be nice given that the idea is to trust the service with my private data.
I know how you feel, a few months ago I was working on a game with a friend just for fun (I was coding, he was doing everything art, music, etc). At one point I realized I was putting off working on it because I wasn't enjoying it, so I just told him that I didn't want to make it anymore and moved on to projects I found more interesting (like cryptography :D). If your projects feel like chores, I would recommend learning about a field you don't know much about and starting from scratch there :)
I think
> Your passwords are as most as strong as the protection of the place where you store them.
would be more appropriate
He's not saying dice or other activities like that are rigged, he's saying the odds in casinos are manufactured such that the house wins most of the time.
I'f you can get a vpn into Canada it's even better, CBC has every event on demand as well as highlights, etcetera for free. As a Canadian, it's wonderful and reduced my productivity by 90% the past few days.