meuk

> Xilinx FPGAs offer a wide range of configuration methods with excellent documentation.

You can always tell an experienced engineer if he says something like "Doing <X> was not hard, it's described here.", and points to a 300+ page manual.

I want to buy such a board, but I'm not sure which one to pick. Any recommendations?

You probably already know that the Fourier transform can be seen as a polynomial evaluation: The nth coefficient f_n of the Fourier transform of a series (x)_k can be obtained by seeing the series (x)_k as the coefficients of a polynomial, and f_n is the value of this polynomial at ω_n, the nth root of unity.

If done in a naive way this takes on the order of m^2 time if your series is m samples long. By cleverly re-using results, the evaluation can be done in the order of m log(m) time.

The re-use of intermediate results can be done by observing that P(x) = P_even(x^2) + x P_odd(x^2), and using this recursively. The FFT of a sequence can now be computed by dividing the sequence into even and odd coefficients, taking the FFT of those subsequences, and re-combining them into the FFT of the whole sequence. The combination of the FFT's to the FFT of the whole sequence can be done in O(n) time, and total time is then O(n log(n)). The recursion is similar to that done in mergesort. One important difference is that it is essential that the length of the sequence is a power of two.

If P(x) = a + bx + cx^2 + dx^3 + ex^4 + fx^5, then P_odd(x) = b + dx + fx^2 and P_even(x) = a + cx + ex^2

This is the basis of the algorithm. The bit reversals are only needed when you do everything in place. And honestly, I don't understand that either.

I am amazed that so many people honestly expected a cookbook for meals in the movie 'the matrix'...

Hey, maybe it's an idea if everyone who plans to do the exercises in a specific language posts a link to a github repo? Then we could compare the solutions :)

I honestly don't know how people can produce something decent while working fulltime.

I am usually home at about six. I then cook, do dishes and hurry to get to sports training, am back at 22:00, hit the shower and go straight to bed.

I also have a buttload of stuff I want to learn, and so many projects I want to do that I never get to really work on anything.

You are mistaken, this is not a myth. Synchronous digital chips have a clock with a fixed frequency, and their working is fixed. So if it works, a chip perform exactly the same, regardless of age. If something's slower, it's software or pheripherals. Probably software (and that's why some people are so upset: hardware is getting faster, observed performance keeps degrading. I have to wait 10 minutes for my computer before I can start working, every day).

The only way to properly learn git.

This. If we'd have a smartphone with a proper USB connection (one that doesn't stop working after a few years), and the possibility to connect it to a keyboard, screen, and mouse, I'd do pretty much everything on my phone. Instead, I can't even browser normally: I get a dumbed down version of most sites.

Well, I can solve most CS problems easily but have a hard time functioning as a developer.

Most CS questions are a bunch of concepts that you rarely use in practice. Most development work is implementing your ideas in a way that works with other peoples code and the framework thats used.

My experience with writing assembler is the same. The run-try-correct sequence encourages trying things until it seems to work.

The best code I wrote was in assembly language. I'd divide the code into blocks with comments. Each comment would document the expected state at that point, what the block would do, and the state after that block.

I wrote pages and pages in my noteblock, and while not everything was bug-free most of it was, and I have never experienced such a nice development process. Nowadays I have to consult five coworkers to ask how to call their undocumented methods and initialize the classes.

I have recently encountered the book 'Toward Zero-defect Programming', where exactly this approach is recommended. Key points are (from the top of my head):

  1. You should know the programming language you're using inside-out.
  2. Don't *try* your code, but *reason* about it, and comment/document this reasoning.
  3. Do group reviews of the code and try to find holes in the reasoning, and problems with the code.

I'm not convinced. Excel is used predominantly used to evaluate formula's that are based on values in other cells. While I'm not a fan of Excel, vim simply does not have this capability and really can't replace Excel for most reasonable use-cases.

I currently work in an environment where I don't have access to a password manager, yet I am expected to have unique passwords for each service, and rotate passwords every month, and am not allowed to store passwords somewhere. Of course, this method requires you to remember more passwords than practically possible.

If all accounts would have sane restrictions on the password it would become trivial to have something both secure and convenient. I have been looking for a system that allows me to: 1. Does not require me to remember an absurd amount of information. 2. Allows me to login to services, even from other devices. 3. Has a unique password for each service (so that it is not disastrous if one password leaks).

We could have one master password, use site and username (and maybe a counter, to make it easy to rotate passwords) as salt, and use a hashing or password derivation algorithm to derive a unique password for each service. This would only require you to pick and remember a strong master password.

> "The major algorithmic / coding / intellectual challenges that I faced were of 3 types:

  - dealing with technical debt of other systems
  - strictly following a policy or a standard
  - fighting with the in-house dev environment

> There were very few interesting problems that actually required to find an effective solution / optimize / enforce security."

That's how I feel as well at my current job, but it seems to hold for almost all IT jobs I've encountered.

> Let me say it plainly: We know how to produce small portions of software using small development teams—up to 10 or so—but we don’t know how to make software any larger except by accident or by rough trial and error.—Because the software we’re trying to build is too massive—it is simply too difficult to plan it all out, and we have no idea how to coordinate the number of people it takes. Every piece of software built requires tremendous attention to detail and endless fiddling to get right.

I was faced with the same problem when I wrote my first program in assembler. I solved this by making blocks. At the begin and end of each block, I put the requirements and guarantees on the value in each register in a comment.

I work as a IT consultant and maybe my vision is skewed, but I never encountered that very basic level of specification before. At the companies where I have worked, requirements are usually specified verbally, in a loose way. Additionally, OOP concepts are (ab)used, so you there is a lot more state to keep track of.

I imagine that if you think about the structure of the project and specify interfaces of units very precisely (both in terms of what in- and output is allowed, what data types, etc.), this would work a lot better.

In terms of structured working for myself, my background in math and low-level programming has helped me a lot. In terms of working in a team, it has made me aware of how little concrete information is written down, and how much information is in peoples heads only.

The article doesn't really distinguish between offering help, and pushing your help. I work in a large team, and I often work on some obscure feature, and it's not always clear who has experience with it. If someone notifies me "hey, I have experience with that part of the codebase, I'm here if you need help", that's what I call offering help, and that is very useful. It's still up to me to decide if I need help or not.

Interesting. Is the improvement in performance mostly due to improvement in size, number, and speed, did finetuning the cache parameters (number of caches, cache size, cache line size) help, or are there more fundamental architectural improvements? Do you have links to more information?

Yup. Applying Russian multiplication to matrices is surprisingly effective for evaluating recursive relations (it can evaluate the nth Fibonacci number in O(log n)) Karatsuba is also a nice 'proof-of-concept' algorithm (it shows that it is possible to do better than O(n^2) at multiplication in the simplest way possible) that's also very practical - and it has a nice anecdote behind it :)

Euclid's GCD algorithm, and Russian peasant multiplication.

You're right from a technical perspective. What I meant that as an abstraction, it serves a double purpose (it represents both a node and an edge in the DAG, and it depends on the command that you use which interpretation is right).

If you checkout a commit, the commit represents the state of the repository. If you revert a commit, the commit represents a set of changes.

I don't think that's true. At least, not if you revert something - it reverts only the changes introduced in that commit. (That there is confusion - or even discussion possible - is exactly my point: the abstraction is leaky at worst, and confusing at best).

Edit: You're right, but my point was that the revert command treats a commit like a set of changes, not like the state of of a repo (since you can't revert the state of a repo, but you can revert changes).

People definitely fetishize complexity. I often mention that I like an intellectual challenge at interviews, and the interviewers often mention 'oh, but this project is very complex' like they are saying something naughty. (Once, the interviewer followed up with "we're using algorithms). I suspect they are usually right, and the codebase is a pile of unnecessary design patterns (because those are what educated developers use, right?).

Where I currently work we're using Azure to do a shitload of computations. At the same time, many modules don't even bother to throw away intermediate calculations. They literally have a giant array of them, and save every result, for each step, even if it's not necessary.

But hey, the project is seen as a huge success, because it's so complex.

The biggest leaking abstraction of git IMO, are commits: they equate a set of changes with the state of the repo after said changes. So if there are multiple commits, reverting a commit is ambiguous. Does it revert the state of the repository to the state before the commit, or does it revert the changes in the commit?

There are a couple more flaws. The commandline is not very consistent, and the complete model is way too complicated IMHO. I can work with it now, but it took me a long time to grasp all of the concepts that I need - without feeling the need for distibuted version control. About that: It's kind of ironic that git is hailed for being distributed, but everyone just uses github, a centralized system.

This is exactly the reason why the Saudi-Arabian government will most likely get away with killing and probably torturing an innocent man. This is absolutely unheard of in any developed country.

Saudi-Arabia is filthy rich, and apparently, that makes murdering an American citizen on Turkish ground legal. I feel disgusted, and everyone who does any business whatsoever with the Saudi-Arabian government is a hypocrite.

Youtube without ads and easy download.

> I am proud of my projects, but it takes a lot more than a good looking product to create a financially sustainable startup.

I know, that's why I mentioned teaming up with one or more people!

> I guess I just need to be more aggressive in concentrate on more smaller companies.

I think that would be a good idea. I think building a complete product will be more valued in smaller companies (especially startups, where you can actually work with a 'greenfield' project).

I'm in Northern Europe and experience the opposite thing: I spent seven years of studying (I have two undergraduate and two graduate STEM degrees), but it doesn't really help me in the hunt for a job. I have never had an algorithmic question in a job interview.

I saw you commenting on one of my posts yesterday, and I checked out your projects. They look very good, and I can't really put my finger on the problem. Maybe you should put more emphasis on your projects on your resume? If I remember correctly you're in Canada and looking for a job in the US. It might just be the added overhead of finding a job in another country.

It's also a possibility to market your products more. If you have friends who would be good at this, they can help you. You have quite a fancy product, and I bet many people would love to start a journey to build something with you. Find someone with more experience in looking for investors and you might have something on your hands (and you wouldn't even need to do an interview).

I think the tech job market is a hard one because there are so many niches. That said, have you tried an interview training? It is hard for people to point out the problem via the internet. No offense, but maybe there is a simple thing you're doing wrong. I know I have a tendency to undersell myself, and I don't always share my excitement with others, which might come across as a lack of enthusiasm.

Last but not least: It can't hurt to study some academic subjects.

Anyway, I wish you the best of luck. Your projects look cool, and I don't understand why you're having a hard time finding a job.

It's not clear exactly what kind of solution you're looking for. I would recommend either

  1. Install Linux Mint with xfce. It is very easy to use, is fast, even on older hardware, and has most things that windows has.
  2. Replace your harddisk with an SSD. It makes a world of difference. If an SSD is too small/expensive, you can buy a smaller one and use a supplementary external harddisk for your media (which usually takes the most space).
  3. Back up your files and do a fresh install of your OS. This time, only install things you need, and prefer standalone programs over installed programs.
  4. Buy a new laptop. You can also buy a refurbished hi-end model, which is a bit of a gamble but usually works out well in my experience.

I think the problem is that current OSes are too complicated. What does a common user really want? I'd say text editing, making presentations, multimedia, and browsing. While these sound like simple things, text editing usually happens in a Word-like format, which - from what I've heard - is ridiculously complex. The same thing holds for browsing (simple browsers don't exist anymore, and many use the same back-end for rendering). For multimedia, USB is very important, which is a very complicated format to use correctly. Then, there are tens of codecs and formats for multimedia, each with their own idiosyncrasies and ambiguities in the specs (or deviations from the spec that are so common that they are expected nowadays).

The case is even worse when your OS is supposed to run on different hardware. I think this is the main reason that Apple, in general, has a much better UX: They only have to support a limited set of hardware.

Casey Murati has a great rant about this: https://www.youtube.com/watch?v=kZRE7HIO3vk

> Given that you have a degree, would you consider going to the US for a year or two of work?

I'd consider it, for the right job. I haven't looked for jobs in the US, and I would prefer a job in the Netherlands, but it's a possibility.

> I also saw you writing that European companies are very driven by specific technologies. I do not think this is true. Sometimes companies will write "5 years of React" but what they are actually looking for is an experienced frontend developer.

Possibly. From my perspective, it is hard to tell the difference, since I don't have a lot of professional experience.