zwegner

In the US there's something like that, though with a narrower set of devices/media covered. https://en.wikipedia.org/wiki/Audio_Home_Recording_Act

Awesome! I really like that tune. Hope to see it continue.

I've had in mind an idea to make an open-source album of completely algorithmically generated music using my Python sound synthesis library. Of course I started with the drum parts, got way too deep in trying to make realistic cymbal sounds (which is very hard), and got burnt out. Typical me... Should probably pick that back up!

Small security hole in this: since i0/i1/i2 are signed ints, i0 % 8 etc can be negative, and thus allow writing in the 7 bytes before r[], quite possibly leading to a stack smashing attack. So you probably don't want to run this in production :)

IdealSpot Inc, Austin, TX, ONSITE

IdealSpot is looking for a front-end engineer!

IdealSpot brings the power of machine learning to retail site selection. Basically, we work with the massive amount of location-based data sources out there to help businesses find the best place to open a new location.

We're a young startup (less than a year old), but now that we have seed funding, we're looking to scale up our business. We’re building out a large mapping tool to help our customers visualize and interact with our data, and we need a hotshot front-end dev to help. Since we're so early in our development, there's a lot of room to help us work out the architecture, and make a big impact in how our business works.

We would love to find a developer who has at least some experience with UI and UX design. We find that understanding the user experience and flow is very helpful to being able to code the interaction in a way that makes sense to the user. Pixel-level design skills are also very helpful. That said, we expect you to be able to do the following:

* Code in Javascript on one of the popular frameworks (AngularJS, ReactJS, Vue.js)

* Build interactive UIs utilizing real-time data from internal and external REST APIs

* Interact with the Google Maps API

* Build responsive templates in HTML5 and CSS3 (knowledge of Sass is a big plus)

* Work with a team within a shared Git repo - i.e., you should know how to merge your code and not screw everything up

Send us an email at work@idealspot.com if you're interested. Feel free to include any past work you can show us, such as a GitHub profile.

> Maybe Google could use this to make a Go bot.

There was in fact a group within Google that worked on this: http://www.cs.toronto.edu/~cmaddis/pubs/deepgo.pdf

IdealSpot Inc, Austin, TX, ONSITE, INTERNS possible

IdealSpot is looking for a backend engineer!

IdealSpot brings the power of machine learning to retail site selection. Basically, we work with the massive amount of location-based data sources out there to help businesses find the best place to open a new location.

We're a young startup (less than a year old), but now that we have seed funding, we're looking to scale up our business. We'd like to handle a huge number of data sources, with a huge number of models processing them, providing value to a huge number of businesses. Since we're so early in our development, there's a lot of room to help us work out the architecture, and make a big impact in how our business works.

Most importantly, we are looking for general software engineering skills. You should be able to dive into any problem and understand the interactions between all the different parts of it. You should be able to write clean, maintainable, modular code. That said, we are looking for somebody who can:

* Code in Python (preferably including NumPy/SciPy/Pandas/Scikit-learn)

* Work with "messy" data--scraping websites, working with CSV/JSON/REST APIs, automating cleanup tasks, etc.

* Interact with databases (we use Postgres/PostGIS/Mongo, and more are on the horizon)

* Do some basic sysadmin-type work, including working with Linux, EC2, Docker

If you don't know all of these, (or even if you do!), show us that you can learn quickly. Or even show us what we can use that's better!

Send us an email at work@idealspot.com if you're interested. Feel free to include any past work you can show us, such as a GitHub profile.

This looks really awesome. I hope it takes off! I'm pretty curious what it looks like though--as much as it shouldn't matter, syntax is very important.

There's a lot of overlap with how I want my language Mutagen[1] to work. Merkle trees of syntax, details persistence/communication handled transparently (or at least orthogonally to any other program logic). Where I think this is most important though (and this description of the project doesn't seem to mention) is optimization. Things like database de-/normalization, data locality, and really so much more--pretty much everything engineers do for performance rather than business logic--should be in the hands of the compiler. Mutagen has been on hiatus for a while, but I've been thinking about it a lot more lately, thinking where to go next. If anybody is interested in it, let me know--I'd love some contributors to work with, or even just people interested in optimization/compilers/functional programming to talk to.

[1]https://github.com/zwegner/mutagen

Your timeit calls in the edit need the -s parameter before the first statements, so they aren't executed on each loop iteration. The overhead is in creating the class, not the instances.

  $ python3 -mtimeit -s 's="%s %s %s"' 's % (1, 3, 9)'
  1000000 loops, best of 3: 0.343 usec per loop
  $ python3 -mtimeit -s 'class Spam:pass' 'Spam()'
  10000000 loops, best of 3: 0.106 usec per loop

Correct me if I'm wrong (I'm no crypto expert), but doesn't client-side hashing take away the main point of hashing passwords in the first place? If a password database is compromised, the hashes don't even need to be cracked, they can just be sent straight to the server for authentication. The only thing it seems to help with for the client<->server case is password reuse between websites, and that's only if they don't use the same client-side hashing scheme.

Moxie seemed to hint at this problem by mentioning local bitcoin wallets--client-side hashing only makes sense if you're not sending the hash anywhere.

Yup. You can get a working program with the simple:

  const int main = 0xC3;

...which is just a return. Or you can get fancy and make it exit successfully by clearing eax first:

  const int main = 0xC3C031;

Interesting. Very similar to the way ints are represented in Python (since they have arbitrary length, negative numbers are represented with infinitely many 1's in the most significant bits).

Maybe it's just me, but the audio output sounds really cool.

I solved it in my head, using a bit of brute force, but mostly some informal reasoning. Basically (and a tad spoilingly):

Since we're dealing with whole chickens, there should an integral ratio between the two prices--that is, M expensive chickens should be the same price as N cheap ones. To go from, say, 10 to 16 chickens requires replacing X chickens with X+6 chickens sold later but costing the same in total. Same with 10 to 26 or 16 to 26. The GCD between these differences (6, 10, and 16) is 2, implying N<=M+2. We also know N/M>=2.6, meaning to trade from 10 chickens to 26 you need to get at least 2.6 cheap chickens for every expensive one you replace. So there's only one exchange rate that works: one expensive chicken costs as much as three cheap ones. Using this exchange rate, 8 of the 10 chickens would have to be traded to get 24 out of 26, leaving two chickens for each farmer that were sold for the same total, but at unknown prices. Three possibilities (0, 1, or 2 at the expensive rate) is a pretty easy brute force at that point.

I have a simple Python library[0] for direct audio synthesis, with oscillators, filters, various other effects, MIDI input, plus some basic building blocks for algorithmic music construction. It pretty much needs PyPy to provide samples fast enough for real-time audio, but even PyPy's too slow sometimes.

Not too much documentation right now, and there's barely any example usage. Think it's about time to remedy that! I have plans for an open-source album created with it, but it's just an idea at this point.

[0] https://github.com/zwegner/undulance

While that is an excellent talk, it seems worth pointing out that it's speculative fiction, these things aren't necessarily happening (though it is quite plausible).

Interesting, thanks. I see the problem, but this paper takes as a given that individuals can introduce transactions that tilt the system in their favor. I can't immediately see a solution to this, but I don't think it's necessarily impossible.

An additional problem I just thought of, however, is that there will be some number of stakeholders that leave the network, lose their keys, etc., and there is a chance that they are the only ones chosen to sign a given history extension. So there has to be some way to recover from this, while still being resistant to denial-of-service attacks.

I tend to shudder when people talk about bitcoin being "cheap". There's a massive amount of energy wasted to maintain the public ledger. It became much more clear to me how this impacts the cost of transacting bitcoins after reading this article: http://letstalkbitcoin.com/blog/post/how-many-bitcoins-does-...

...and particularly after seeing this graph: https://blockchain.info/charts/cost-per-transaction

I'm more excited about proof-of-stake, as there isn't this arms race to throw more and more computing power to generate bitcoins. I'm not sure why it hasn't seen more adoption, but I will admit that I don't pay a lot of attention to the cryptocurrency space...

Actually commutativity doesn't hold either, because of dealing with NaNs (at least on x86, on a quick search I can't find a reference for whether this behavior is part of IEEE 754 or just implementation defined). Operations with two NaNs will give the first operand. You can see this with a quick test program:

  #include <stdio.h>
  int main() {
      unsigned long long bits = 0x7FFC000000000000;
      double x = *(double *)&bits;
      bits += 1;
      double y = *(double *)&bits;
      double z = x + y, w = y + x;
      printf("%llx %llx\n", *(unsigned long long *)&z, *(unsigned long long *)&w);
  }

Of course, this probably doesn't matter for most applications.

That's not too different from a pretty old observation in the chess world: the presence/absence of an evaluation term is more important than the weighting given to it.

> So I agree with this claim - uniform distributions are fairly robust to errors. But I don't think that's particularly related to randomness - Monte Carlo is only needed to integrate the distribution.

Ah, that's an interesting distinction, thanks. I'll have to think about this some more. But given a situation where exact integration is intractable (like chess or Go), I'm not too sure what the difference really is, because it is those cases (on first thought) where the uniform distribution is useful--if you can see to the end, you don't need to care about bias, right? I mean, "randomness" in the strictest sense is not really necessary; all these programs I speak of used deterministic pseudorandom generators of course. It's really just about ensuring lack of bias given finite sampling. I'm happy to hear your take on it though--you definitely seem to have a lot more knowledge of math/statistics/etc. than I do.

(That does remind me of another fascinating tidbit from the Go world: programmers noticed that using a low-quality PRNG, like libc's LCG rand(), produced significantly weaker players than more evenly-distributed PRNGs, even though it would seem that playing lots of random games of indeterminate length (with the PRNG called at least once per move) would not correlate at all with the PRNG's distribution.)

The adversarial-or-not issue is also good food for thought. I'm not convinced that it explains much in this case, though, since I believe most of these observations were made by playing computer-computer games with each program using very similar algorithms, or with old hand-tuned programs against the newer Monte-Carlo based programs.

I believe the article you're referring to is: http://lesswrong.com/lw/vp/worse_than_random/

Choice quote: > As a general principle, on any problem for which you know that a particular unrandomized algorithm is unusually stupid - so that a randomized algorithm seems wiser - you should be able to use the same knowledge to produce a superior derandomized algorithm.

An interesting counterexample to this, an example which to me illustrates a very powerful aspect of randomness, is the monte-carlo revolution in computer Go (AI for the ancient Asian board game). For years, computer progress stagnated, as the techniques were mostly focused on encoding human knowledge into code. While most of this human knowledge is generally correct, it introduces significant bias in the way positions are evaluated. The way these rules-of-thumb interact is very hard to predict, and tree search algorithms are quite good at finding positions that are incorrectly evaluated. Because of this, the worst-case behavior of an evaluation function is much more important than it's best-case or average behavior.

Computers started making lots of progress when a new technique was used: rather than try to evaluate positions by a large set of heuristics, they were evaluated by playing random games. Go positions are quite hard to evaluate from simple rules of thumb, and this random game approach gives a much more balanced, long-term view of positions. And most importantly, there is much less bias.

Obviously, an entirely random game, with a uniform distribution over possible moves, is easy to improve upon. But computer go programmers noticed an interesting phenomenon: while certain types of knowledge incorporated into the random move distribution (to make it "more intelligent", as judged by a human) were helpful, others were not (even after taking into account the computational cost of adding the knowledge), and it wasn't always clear why. The same observation about heuristic evaluation noted above applied: having a balanced distribution of move choices, with a reasonable probabilistic lower bound of effectiveness, is more important than making an intelligent choice that is usually correct, but has unpredictable, extreme worst-case performance.

So we see that randomness does have an important property: it avoids the downside of "knowledge" that generally seems correct but can go horribly wrong in unexpected ways.

I don't know of a good writeup of this phenomenon. My understanding of it is mostly assembled from following informal discussions on the computer-go mailing list for several years. In a quick search through my gmail archives I can't find much on the subject, but here's an interesting post about related topics in the computer chess world (that incidentally doesn't talk about randomness, but illustrates well the benefits of avoiding bias): http://www.talkchess.com/forum/viewtopic.php?topic_view=thre...

SaaSaaS? ...which of course leads to the general form, S(aaS)^n.

Haha, I was about to PM you and then realized that there aren't PMs on HN :) I always like to talk about this stuff though, if you want you can email me at zwegner@gmail.com.

What you describe is somewhat similar to what I had in mind, but a more well-defined abstraction. I hadn't yet formulated it in terms of types, because for now it's just a hack in the bootstrap interpreter, and anyways a lot of Mutagen's type system is still in my head, waiting to be implemented once I have a better understanding of how/why other functional languages do this stuff.

Can you describe more about how this works, specifically how it's an improvement over __setitem__ and __setattr__?

I'm interested in how various languages handle this, mainly so I can steal ideas for my project Mutagen, a purely functional Pythonic language. I recently added modification operators that behave rather like a nestable setitem/setattr. Basically:

  list_of_objects = list_of_objects <- [index].attr = 'abc'

I've been thinking about ways to make this extensible and flexible (e.g. returning a list of effects to apply to an object, or having some post-processing for any bookkeeping an object needs). The copatterns are pretty cool looking, but I'm not sure how I'd fit it into Mutagen's imperative-esque syntax.

Pretty sweet looking. After seeing the Envelope A/B widgets, I thought "wonder if this was made for the purpose of a UI for a software synthesis library?" And sure enough, it was :) Is the synthesis package open source (or going to be)? EDIT: nvm, found it: https://github.com/mitchmindtree/rust-dsp

Glad to see Rust getting more traction. I'm not a huge fan of the syntax, and I'm personally putting my chips in the purely-functional space--but it's the most promising as far as a practical C++ replacement with much better semantics, which is sorely needed.

I see what you're saying, but in my experience advertising rarely gets this right. The fashion industry is a good example. I have absolutely no desire to read those magazines, let alone pay money to do so. It's blatantly reinforcing insecurities in the readers--the whole concept of what's "in style" is only meant to make people more judgmental, and fear that that same judgment might be turned against them, with constant purchases as the only way out. Quite an ingenious idea for the fashion industry, but a very toxic, manipulative piece of psychology for everyone else IMO.

Of course the tiles aren't so bad. My objection to them is mostly on principle, out of fear that it's another step in Mozilla becoming excessively beholden to advertising interests.

While the comments here are almost universally negative, this actually isn't that bad of an idea. Not just because of the freedom aspect, though I'm generally fairly principled about that--I'm more concerned about security and tracking. I've been increasingly paranoid in the post-Snowden era about this kind of stuff, using NoScript, RequestPolicy, and other plugins. And guess what... it's a huge pain in the ass. So many sites are broken, and I have to whitelist sites/external frameworks/CDNs quite often just to read simple articles. And even after all this effort, I know that I could still be running malicious code. I probably shouldn't care so much, but it's an irritating possibility. The implementation here isn't necessarily the best solution, but the idea of limiting javascript to trivial functionality could make things for the paranoid/security-conscious a lot easier.

Pedantic aside: I guess you mean non-associative multiplication? That is, ax(bxc) versus (axb)xc. Since rounding happens at different times, they can give different results. Floating point multiplication is indeed non-commutative as well, but that has to do with NaN handling, not imprecision.

Cool game! A few notes:

I think your choice of license may be incompatible with the GitHub terms of service--there's an implied right to fork by using GitHub, but your license states no derivatives are allowed. IANAL, but something to look into: https://help.github.com/articles/open-source-licensing

As I mentioned in another comment, it's pretty slow under Firefox.

Lastly, the game is quite pretty, but I feel that since the gameplay involved is so precise, the imprecise visuals can be confusing. It's hard to tell exactly when a piece is going to set in place, when a group is eliminated, what would happen if you rotate and a piece is blocked by a stack already in place, etc. I went by pure geometry at first, but I definitely got bitten a few times where a piece moved after I thought it was in place, or a piece didn't get eliminated with the rest of a group since it hadn't fully landed in its column. The collision animations don't quite help there either.

Weird. I got to 80k in Firefox, and stopped because it was pretty slow and not getting faster--not really challenging at all.

I tried again in Chrome and its a lot faster, and does get faster throughout the game as well. More fun and challenging, but yeah--it does get too fast too quickly.

Cool, I hadn't heard of this. I couldn't find much info on a quick search, so here's Intel's reference: http://www.intel.com/content/dam/www/public/us/en/documents/...

MULX was introduced on Haswell as part of the BMI instructions. Basically it allows two explicit destinations (still an implied rdx source though).

ADCX/ADOX are pretty weird. They both operate basically the same as ADC, but only read/write the carry or overflow flag respectively. The idea is to allow two interleaved independent chains of adds, putting less pressure on the out-of-order logic on chip. This seems kinda weird though: the renaming logic would have to detect that the bit of the flags register that one chain of adds reads aren't written by the other chain, so those instructions wouldn't be hazards, and thus both chains can be executed in parallel. OTOH, IIRC there are other instructions that only write certain bits of the flags, so I guess the logic for this bit-level renaming of flags is already there.