Btw, anyone has a list of subset tasks on this Project Euler more related to pure CS/Algorithms rather than Math? Preferably mentioned the level of experience. So far, as I can see, it is aimed for very beginners, right?
Project Euler Returns
41–50 of 104 posts
Re: Project Euler Returns
#42Who returns, Project Euler? Neither the news page, nor the "about" page, nor the front page of "Project Euler" care to explain what this website is all about. Of course, I can guess that it has to do with mathematical problems of some sort. It is sad if you have to turn to Wikipedia to find out the basic details about a website. A sentence or two of introduction would have made everything better :-)
Agreed, I had never heard of it and the about page was no help at all.
On the off chance that other comments here haven't made it clear what it's about, or that you haven't already looked it up, they apparently have a Wikipedia article about them:
http://en.wikipedia.org/wiki/Project_Euler
""" Project Euler (named after Leonhard Euler) is a website dedicated to a series of computational problems intended to be solved with computer programs.... Problems are of varying difficulty but each is solvable in less than a minute using an efficient algorithm on a modestly powered computer. A forum specific to each question may be viewed after the user has correctly answered the given question. """
There are also several Github repos out there that have both the problems and hashes of the answers. (Some have the actual answers, as well, or used to in the git history, but presumably anyone interested in solving the problems is more interested in the process than the score.)
Re: Project Euler Returns
#43Earlier quoted context omitted.
Anyone interested in creating an open source version? It could have more features - such as running the code online, and more topics - such as non-math challenges.
It's not open source, but https://www.hackerrank.com/ sounds exactly like what you're describing, in case you've been looking for something like that.
There's a number of sites that are not open source that use coding tasks like this and tie them with leaderboards and tie-ins to recruiters. As well as hacckerrank, there is codeeval, and there are some others whose names escape me at the moment.
But that doesn't really address a question about putting together an open-source one.
There's also at least one similar-to-Euler one -- rosalind.info (like Euler, but bioinformatics focus) -- which might be closer to responsive, since even though its not open source, their FAQ says they intend to open-source it...
Re: Project Euler Returns
#44I should preface this by saying that I love Project Euler--I spent a ton of time there while learning to program. I also am impressed by anyone who volunteers to create something for the community, and invests effort in maintaining it. However, not storing emails, and thereby giving up account recovery with the explanation that it's about security is a shit sandwich. My email is . @gmail.com, a pattern I share with m…
It's one thing to decide not to store emails (sure, why not?) but account recovery shouldn't even require one to store email addresses. Check the the email provided by user via the recovery form against a hash of the email saved during registration, if it matches send the reset link. This way when data is breached, figuring out what the original email should be hard (if not impossibly hard, depending on how they hash…
Of course you're right, and I can't believe I didn't realize that. I think my point still stands that it's a bit silly to worry about storing emails, but you're right that you can even avoid that risk by encrypting them if desired.
(And "hash" is a bit misleading: http://codahale.com/how-to-safely-store-a-password/).
Re: Project Euler Returns
#45I should preface this by saying that I love Project Euler--I spent a ton of time there while learning to program. I also am impressed by anyone who volunteers to create something for the community, and invests effort in maintaining it. However, not storing emails, and thereby giving up account recovery with the explanation that it's about security is a shit sandwich. My email is . @gmail.com, a pattern I share with m…
The combination of email address + password (even hashed in some way) isn't quite as public anymore. Not having any personally identifying information doesn't protect your Project Euler account, it protects your other assets.
This is a good point, and a reason to do the right thing with regard to emails--which is to store a safe version of them (bcrypt).
Because while an email and a password is not public information, a username and a password isn't public information either. If you don't trust yourself to store the former, you shouldn't trust yourself to store the later much either.
Re: Project Euler Returns
#46Earlier quoted context omitted.
It's one thing to decide not to store emails (sure, why not?) but account recovery shouldn't even require one to store email addresses. Check the the email provided by user via the recovery form against a hash of the email saved during registration, if it matches send the reset link. This way when data is breached, figuring out what the original email should be hard (if not impossibly hard, depending on how they hash…
You should not simply use a hash, but at least a salted hash, or even harder stuff like bcrypt. In other words, treat emails like passwords. Apart from that, I don't see any issues with that approach. Not sure why project euler doesn't use that approach.
A salted hash would completely eliminate any ability to look up accounts by email address, since you would have to hasn't the email against the salt for every account in the database until you landed on the correct one.
Re: Project Euler Returns
#47Earlier quoted context omitted.
The combination of email address + password (even hashed in some way) isn't quite as public anymore. Not having any personally identifying information doesn't protect your Project Euler account, it protects your other assets.
This is a good point, and a reason to do the right thing with regard to emails--which is to store a safe version of them (bcrypt). Because while an email and a password is not public information, a username and a password isn't public information either. If you don't trust yourself to store the former, you shouldn't trust yourself to store the later much either.
Particularly, the same kind of threat to other accounts belonging to the same person exists with username/password combinations as with email/password combinations; after all, people reuse username/password combos as much as email/password combos.
So, the same general class of people who you endanger by not storing email/password securely are endangered if you stop storying email and just have username/password.
And a lot of that class will have emails that can be quickly guessed by appending one of "outlook.com", "gmail.com" or some other popular free-webmail provider to the username, because if they reuse usernames and passwords, its quite likely they do it on their mail site and that they have a webmail provider. So while what Euler has done clearly has a significant convenience impact, it has negligible security impact.
Re: Project Euler Returns
#48I have been curious for a while: What is in the opinion of the HN community a good score on Project Euler? For which scores do you tip your figurative hat?
It's really tough to say. Some people have awesome math degrees, some people only do it casually, some don't do it at all.
Keep doing the problems until you get stuck. Then learn, then solve a few more. Repeat as long as you're happy with your progress. I wouldn't put a number on it.
In fact, do some easy ones in a completely new language!
Re: Project Euler Returns
#49Earlier quoted context omitted.
It's one thing to decide not to store emails (sure, why not?) but account recovery shouldn't even require one to store email addresses. Check the the email provided by user via the recovery form against a hash of the email saved during registration, if it matches send the reset link. This way when data is breached, figuring out what the original email should be hard (if not impossibly hard, depending on how they hash…
You should not simply use a hash, but at least a salted hash, or even harder stuff like bcrypt. In other words, treat emails like passwords. Apart from that, I don't see any issues with that approach. Not sure why project euler doesn't use that approach.
Right, which is why I said
> figuring out what the original email should be hard (if not impossibly hard, depending on how they hash it)
I mean, passwords are way more sensitive than emails, especially given that many people re-use them. So, how you hash passwords is more critical than how you hash emails (which is rarely done, I guess).
On the other hand, there is no reason to not have the same level of protection for emails, if you are already following best practices for passwords anyway (PBKDF2, bcrypt, scrypt etc.).
Re: Project Euler Returns
#50Earlier quoted context omitted.
You should not simply use a hash, but at least a salted hash, or even harder stuff like bcrypt. In other words, treat emails like passwords. Apart from that, I don't see any issues with that approach. Not sure why project euler doesn't use that approach.
A salted hash would completely eliminate any ability to look up accounts by email address, since you would have to hasn't the email against the salt for every account in the database until you landed on the correct one.
A noob question I suppose, but couldn't the salt be generated deterministically from the email and still serve it's purpose?