If you haven't noticed from my posts, I seem to have a pretty hard-set tendency towards posting problems which require some amount of programming to solve, but aren't actually programming problems in and of themselves, also requiring knowledge from other mathematical disciplines.

I'm still learning the Brilliant culture and goal, and from what I can see, this sort of flies in the face of pencil-and-paper test practice... but I'm certainly not receiving much negative feedback either, and the #ComputerScience top-level tag provides plenty of precedent.

What are people's thoughts on these types of problems? Are cross-discipline challenges too niche, or too difficult in general? Should I tone these down a bit to make them more accessible to non-programmers, and if that makes them easily brute-forced by a programmer with little to no mathematical reasoning, so be it? I'm curious as to what people think of these flavors of problems, and what they mean for Brilliant.

P.S. If you don't know what 'Project Euler' like problems are, go check them out!

No vote yet

1 vote

×

Problem Loading...

Note Loading...

Set Loading...

## Comments

Sort by:

TopNewestSo, if you want visual confirmation that other members enjoyed your problem, here is a snapshot of students from my high school (back in Singapore) who visited Stanford for 2 weeks. They are supposed to be going off for a BBQ, but are working on a Brilliant problem. If you stare at the screen, you could recognize that it's a problem with a lot of text and details. It is actually your problem Broken Bridges. They were discussing the best plan of attack for the problem, and trying to figure out what the equations should should like.

Image

Note: This was not staged. I was on my way to dinner, and their teacher was trying to chase them out.

Log in to reply

I, for one, think your problems and notes are awesome and fit right in with the culture.

Log in to reply

Seconded.

There is a lot of potential development for programmers (not just academic Computer Science Professors), who learn some theoretical mathematics (group theory, analysis, combinatorics, etc), and use the results to simplify their code and make it much more efficient.

Here's a story that you might appreciate.

In the finance world, speed is a highly valued commodity. The quicker your program can (accurately) run, the more valuable it is. This happened 50 years ago. Portfolio theory requires you to look at the performance of numerous (say 1000) stocks and determine their performance over a certain time period (say 1000). You need to study the covariance of pairs of investments, which results in a large covariance matrix \(M\) (\( 1000 \times 1000 \)). We then need to calculate \( M^ {1000} \) to see the effect over the time periods. However, multiplication of matrices is a nightmare (even to some of you), because of the huge amount of calculations that need to be done (about \( 10^{15} \) calculations are needed in this case). This causes a lot of computer programs to be extremely slow.

Then some day, someone came along and said: "The covariance matrix is real and symmetric ..."

Punchline explained: A real, symmetric matrix is diagonalizable (by an orthogonal matrix). A diagonal matrix is very easily multiplied. Using this process, you require much much fewer calculations (about \( 10^{10} \), and hence become much much much faster.

Log in to reply

Excellent story! Seems like I'll just keep plugging along as is for now, thanks for all the kind words everyone :)

Log in to reply

Me too,I love them.

Log in to reply

I'm miles outside the age range for which this site is intended but can't resist responding. Euler-like problems are very welcome. Also: (a) software serves those of us who have always been pretty bad a manipulating symbols, and (b) Euler serves as a demonstration that there are lots of problems that can't be solved with either witless brute force or mathematics alone.

Log in to reply

Project Euler is fully back up I believe " It is with the greatest of pleasure that the team can officially announce the return of Project Euler. The current website will go offline for a short period on Saturday 16 August 2014 at approximately 9am [BST] to restore full functionality.

The new site should look very familiar, but you can be assured that there has been a complete rewrite of the website engine. Along with such big changes it is quite possible that members will encounter teething issues as, hopefully only, minor bugs will be discovered. We would ask that anyone who spots any problems to report them to the forum: http://forum.projecteuler.net/viewtopic.php?f=5&t=3633.

Although full functionality will be restored: sign in/out, tracking which problems have been solved, access to the discussion threads, progression through levels, awards, and statistics, there is one significant change which we must make you aware of. After much discussion and consideration a decision has been made to no longer store email addresses. For a number of members this will not be a problem, as they had already used disposable email addresses to register, but for others this could have one major consequence: Account recovery will no longer be possible. With respect to this issue it is quite possible that some members will have genuinely forgotten passwords. There will be a link on the sign-in page which will outline the process for account recovery, but please be aware that initially this will only be available to members who have solved 200+ problems. The process will be handled manually so depending on the volume of requests the service will either be halted or we may move the threshold down from 200 problems.

The decision to no longer store any private/personal information in no way reflects a lack in confidence of the steps we have taken to make the new website secure, but if history teaches us one thing it is that for every "unsinkable" Titanic built there will always be icebergs. We hope you understand our reasons for this decision and accept that it was not made lightly. However, we would prefer to focus on the good news, which is the imminent return of Project Euler. We apologise for the long delay in restoring the website and we appreciate the patience shown by our members, but understandably the rewrite was no small undertaking.

You should also be aware that once you have successfully signed in you will be asked to change your password before you can do anything else.

Finally, we would like to thank you everyone for the positive and supportive comments made during the challenging time we faced whilst being offline. " - Project Euler news

Log in to reply

Similarly to how problems that use multiple ideas in different math fields are appreciated, I think that problems that use both math ideas and Computer Science are also appreciated.

Log in to reply

I don't really think brute-force is cool, maybe you can post problems with higher values for the cases that needs a computer to solve it

Log in to reply

This is where the dilemma usually happens. I can make a problem un-brute-forcible by increasing the parameters, but doing so often leads to marginalizing non-programming contributors, because the numbers get too big, or the number of operations needed for the 'smart' solution gets up to 100s or 1000s, which is absolute tedium without code. So I'm wondering which way, and how often, I should tip the "Solution is trivially brute-forcible by code" XOR "Solution is inaccessible to non-coders" scale.

Without spoiling the solution, Broken Bridges is an excellent example of the choice being tipped towards the "Solution is inaccessible to non-coders" side. For 5, 6, or even 7 houses, the solution is reasonably computable with pencil, paper, and a calculator, but it is also trivially brute-forcible for 7 houses. The brute force solution can

maybework for 8 houses with some small tricks, but for 9 or 10 houses, it's completely intractable for brute-force code, so the 'smart' solution is forced - but even the 'smart' solution is unwieldly and tedious for non-coders at 10 houses.Log in to reply