Humans vs. Microsoft Excel: The Quest For Smart Tools - <AUTHOR> http://futureofwork.glider.com/microsoft-excel-the-quest-for-smart-tools/ <comment><USER3> The author said it himself, these errors were caused by humans, not excel. I don't think making excel "smart" enough to prevent people from making dumb mistakes is a good idea. In fact I think that would transform excel into microsoft word, which is the only thing that could make life worse for your typical competent office worker.

Excel already has a lot of this crap. It already requires an act of god to prevent excel from changing your string of digits into a number or date. It already shows you little exclamation point icons when your formulas omit adjacent rows or are different from other formulas in the same row/column.

A tool will never make it possible for dumb people to solve hard problems easily. It's like trying to design a knife that makes it impossible to cut yourself. Nobody with any kind of a clue would want that knife.

A tool should be straightforward and intuitive, but it shouldn't aim to be smarter than it's user.

<comment><USER4> There is low hanging fruit in the problems to solve though. For example, finding and highlighting outliers in a column. It's a relatively simple feature but yields big benefits to users.

<comment><USER5> Except it isn't that simple. Your definition of an outlier may be completely different from some one else's (95th percentile, median/regression method, or simple max/min, some of these are already possible in excel). Then, how is the information displayed? Highlighting cells? Well if you have +10k rows of data, than that won't be too useful. Creating a summary in another column/sheet will add to the already cluttered 'results' spreadsheet, etc...

This is why I recommend using programming based tools for data analysis. Any non-programming tool has to find a balance between the number of features offered and the complexity/ease-of-use of the tool. With programming tools, you merely have to find the right package (or build your own) which essentially results in getting the exact set of features that you need to solve your problem.

<comment><USER6> I know people bag on VBA, but I'm a big advocate of effectively utilizing Excels tools along side using VBA to customize where necessary. This solves the problem in your first comment (users can define their own statistical limits and methods), while keeping the simplicity of excel and its tools for other users.

The problem is that not everyone is a programmer. A "programming" tool might be great for you, but when you show it to co-workers for them to work with, they'll inevitably ask "Can I get this in Excel?". Excel+VBA allows for customization when the "complexity/ease-of-use" balance is out of sync with your needs, but to everyone else it's still just Excel.

With this, those that can program have the option to solve the problem their way, while allowing those that don't program the means to solve the problem the way their used to.

<comment><USER5> I have used VBA here and there, and try not to bag on it too much. There are some cases where using it can make sense, but in general, it seems to be a compromise.

I get a little confused about the programmer/non-programmer dichotomy. If you are capable of implementing a complex model in excel, you are probably more than capable of learning a programming language. If you are just tallying up a few numbers to throw into a report or presentation, then yeah, no need to switch. As I mentioned in another post, it probably has to do with exposure and motivation.

<comment><USER7> Excel is a tool, and it's a really good tool for what it does, which is for applications that require: \- very fast iteration cycles \- a particular data model: grid of numbers which is very common in business world \- support for everything under the sun: persistence (just hit save :), dialog UI, math formula, stats models, string functions, date/time functions (better than even Java's Joda), internationalization, localization, utf 8, and plenty more

</comment></comment></comment></comment></comment></comment><comment><USER8> I work with an army of very smart people who need to build incredibly complex models to drive our business. Like most companies, we turn to Excel. It's the only widely used application with a low enough barrier to entry that "non- technical" people can build legitimately complex (if not always robust) models.

But the problems with Excel and general spreadsheet modeling limitations offer such a great opportunity for improvement that would impact just about every business out there. I wish I saw more people tackling this, or I had a great idea to do it myself. The problems I see are around barrier to entry, in that it must be usable in just a couple minutes, simple enough for non-programmers to learn, and equally or more efficient to get a basic model functioning. Otherwise I just don't see wide adoption despite possible maintenance, accuracy, and reliability benefits.

James Kwak has written some smart stuff about this ([http://baselinescenario.com/2013/04/18/more-bad- excel/](http://baselinescenario.com/2013/04/18/more-bad-excel/)), and I'm interested in what Data Nitro (datanitro.com) is doing.

<comment><USER9> I think Data Nitro is really cool, and as a data geek the idea of having a real language available inside the Excel environment gets me very excited.

Unfortunately, by increasing the power and capability of what a careless user can do, while expanding the learning curve and moving Python code to a different place than any cell-level functions or global VBA functions are stored... all of this just makes the potential for issues of human failure far greater.

<comment><USER10> Is there a reason you don't use one of the current data analysis languages like R, Stata, SAS, etc?

<comment><USER9> I use those languages frequently, when they are the right tool for the job. Well, R and Stata, at least — but also Processing and D3 and Google Maps...

Not sure how this is relevant to my concern, though.

</comment></comment></comment></comment><comment><USER11> disagree completely. MS Excel is a masterpiece in software engineering, definitely the best piece of software MS ever created. Large pieces of the economy run on Excel, finance, controlling, etc. are unthinkable without it.

the flexibility, ease of use, speed is astounding. applying colors to cells and then being able to sort by color still blows my mind - not the feature per se, but the fact that they included it and solved a common problem (how many times did a client mark something by color in a big spreadsheet...).

excel is mobile, works offline. replacing it with some webapp or too much logic just shows the complete misunderstanding of its appeal.

<comment><USER12> This. It's important to remember that from the perspective of millions of corporate users (not the hacker crowd), this is is THE tool. When you think about it, Microsoft really is Excel. That is their core. Why is it difficult for corporations to switch from Windows? Office. Why Office? Excel. If anyone attempted to create something that not only matched Excel (with all the messy file compatibility issues and macros), but surpassed it, they would be striking at the heart of Microsoft.

<comment><USER4> Agreed. Although you could replace 'Excel' with 'Word' and still be just as correct.

<comment><USER13> Word isn´t the problem... Converting from Word to something else is some pain for users. Converting from Excel (especially Excel Macros) to something else is in the Millions of $ for developers/re-engineering of those Macros...

</comment></comment></comment></comment><comment><USER9> This is a problem I've spent a lot of time pondering. The author makes several suggestions; one in particular (a GitHub for datasets) is an idea I felt strongly enough about that I founded a start-up called BuzzData to address this concern. Unfortunately, we did not find our critical mass and the product has since successfully pivoted into an entirely different product called LookBookHQ.

I do have another idea, which is to bring the concept of testing to the Excel world.

I think that the combination of:

\- a framework for building up test cases that can be run against the data as part of the saving process (think rSpec)

\- an English-like, indented grammar for defining user stories that can potentially generate code for tests (think Cucumber)

\- a strong push for a culture of testing in the Excel community that would have to include Microsoft

I dunno, honestly. Could be crazy. The culture might never accept testing.

But then again, one of the basic ways to sell something is to give people insurance against humiliating themselves. It's possible that this thinking would make a lot of sense to the twice shy, highly risk-averse board members of the major financial institutions and governments of the world.

<comment><USER14> Started following LookBookHQ. =D

Ever read "Specification By Example? That approach along with some of your suggestions could be used to prove your testable specification spreadsheet concept.

The market awaits for you.

</comment></comment><comment><USER15> The fundamental problem with big spreadsheets is that they're complex pieces of software, and they're being designed by people who haven't studied software engineering.

Building a complex program is hard. It's untenable if you don't approach it properly. This is true whether you're using Excel, Python, LISP, or anything else. Better tools can go a long way to help, but the ultimate answer is educating people on how to properly engineer systems.

On that last point - at DataNitro[1], we let people script Excel with Python, which is a better tool than VBA or than doing things by hand. The result is that for a given level of complexity, you see fewer errors and more robust spreadsheets; but when you give people more power, they naturally build more sophisticated spreadsheets. All else being equal, this might result in more, not fewer errors.

The great thing about introducing a new tool, though, is that there's also a chance to introduce new ways of working. Suddenly, people start building spreadsheets that work with version control and run unit tests. This helps tremendously with robustness and reliability.

[1] [https://www.datanitro.com](https://www.datanitro.com)

<comment><USER16> As a dynamically typed language, how does Python specifically yield fewer errors than VBA? Or even compared to C# or F#?

</comment></comment><comment><USER17> At a previous job, I tried to convince them (and succeeded in some cases) to build a domain-specific web app instead of sharing and e-mailing ever-changing Excel docs.

I used CakePHP, and it was really easy to whip up a complete CRUD web-app with domain-specific information and DB tables, allow people to collaborate through a web interface, and be happy users.

Some apps are tougher than others, I'll admit.

</comment><comment><USER18> I dare say that the problem is less about Excel being dumb than that if you're interested in the underlying logic Excel hides all that from you the minute you click off a cell. There's black box programming and then there's just silliness.

As for data-entry, ideally, that's not something that humans should be doing for anything but the most trivial concern. If you have huge columns of financial data or test results or what have you, then having someone type it into a computer is silliness of the highest order.

</comment><comment><USER19> I think it's impossible to replace Excel en masse, so lots of folks are starting to pick off bits of it to replace. And hopefully in doing so they'll invest in making those bits a lot smarter than they are in Excel.

Examples from the S12 YC batch alone:

. VBA isn't great, so DataNitro is letting you use Python.

. Grid is (mobiley) replacing the basic list-making use case of Excel.

. (Stretch example:) Financial modeling of big personal finance decisions is a nice use case of Excel, but too hard for most people, so SmartAsset bakes those kinds of models into an on-site calculator.

. Statwing is replacing pivot tables, which are clunky, devoid of statistics, do no error checking, etc.; in a few clicks Statwing will automatically choose, run, and interpret a statistical analysis, all the while looking for and alerting users to outliers or (some) other data issues. [I'm a cofounder. Also: [https://www.statwing.com/demo](https://www.statwing.com/demo)]

I'd expect that soon someone will come along soon and pick off the financial modeling use case in a way that's a bit more generalized than SmartAsset. Really tough UI challenge, but I think doable.

<comment><USER20> I suggest you change your statwing demo to something more positive.

</comment></comment><comment><USER21> Having worked in nyc financial world, I can say excel is here to stay - <USER2> least for foreseeable future. Heck, the only reason I have windows running in parallel in my MBA is excel. We use to have what we called "excel test" for all quants and analyst positions. We use to QA our excel sheets just like any other software application. I am surprised that many companies don't do that - it only makes sense.

<comment><USER11> why? excel runs perfectly fine in its OSX version. which differences have you encountered?

<comment><USER22> VBA, which was removed in Excel 2008 and returned in Excel 2011, is not fully compatible with Windows versions, where most users author code.

Backend data connectivity options are virtually non-existant. Excel 2011 has what appears to be a 10+ year old version of MS Query.

Some 3rd party financial plugins are Windows dependent, and I believe some of the Microsoft analysis additions are as well.

<comment><USER23> You nailed it. I would use less generous language than you did to describe VBA's deficiencies in Mac Excel 2011. Huge parts of what could be considered the stdlib are totally missing in the Mac version. The language doesn't even have native dictionaries.

<comment><USER22> I doubt MS wants Mac Office to be on feature parity, otherwise there is one less reason for businesses to keep buying Windows.

</comment></comment></comment></comment></comment><comment><USER24> You can turn Excel spreadsheets into web applications quite easily with Google Apps Script. We wrote a REST interface to a massive multi tab Excel file recently and it only took like an hour, as opposed to days of reverse engineering the calculations (the client did not know what the equations in the file were because the employee who created it left).

Basically I'm saying it will get much, much worse before it gets better.

</comment><comment><USER25> There are entire organisations and conferences about the dangers of spreadsheets[1] and there are now programming standards for develop spreadsheets[2].

Basically, the normal rules apply. If you want safe spreadsheets, you have to plan and verify.

The reason this doesn't happen is because firstly, spreadsheets are very accessible. Every working large system evolves from a working small system, as John Gall observed. Excel et al make that evolution relatively easy.

The second is that spreadsheets enable non-programmers to work with concrete concepts instead of the abstract ones that programming languages encourage. It's easy to visualise locations on a sheet when you are looking at the sheet.

Finally, spreadsheets support calculation by propagation. They are an excellent declarative environment. Most programming languages do not support this model of programming (though we're groping towards it with concepts of binding).

[1] [http://www.eusprig.org/](http://www.eusprig.org/)

[2] [http://www.fast- standard.org/document/FastStandard_01b.pdf](http://www.fast- standard.org/document/FastStandard_01b.pdf)

</comment><comment><USER26> If you are amused at what autocorrect does for writing, imagine the hilarity of economic decisions based on "smart" spreadsheets.

</comment><comment><USER27> Excel will always be used BECAUSE its so free-form.

[http://readwrite.com/2013/06/11/excel-is-an-art-form- these-b...](http://readwrite.com/2013/06/11/excel-is-an-art-form-these- beautiful-images-are-proof#awesm=~o8w9EUvUTJDPlC)

</comment><comment><USER28> Hmm... Excel-like front-end to Haskell?

<comment><USER25> For inspiration, consider SIAG:

[http://siag.nu/siag/](http://siag.nu/siag/)

</comment></comment><comment><USER27> Typed fields sound neat!

</comment><comment><USER29> We need to think beyond the limitations of tools no matter how pervasive their use. It reminded me of : [http://vimeo.com/66085662](http://vimeo.com/66085662) (you can skip to the demo)

</comment><comment><USER30> I got theory. There is a limit what you can do with WYSIWYG editors. Once you reach the limit, the software starts getting in your way, hiding your errors and making you work harder.

It applies for many software. From HTML to 3D modeling.</comment>


The entire Apollo 11 computer code is available on GitHub, and it's incredible - <AUTHOR> https://twitter.com/mrpiercey/status/1151148769389568000 <comment> chupa-chups (one of the) Previous discussion(s): [https://news.ycombinator.com/item?id=12048945](https://news.ycombinator.com/item?id=12048945)</comment>


I2C Programming in Go - <AUTHOR> http://www.gmcbay.com/2013/01/i2c-programming-in-go/ <comment><USER2> blog author here, feel free to direct any questions into this thread since I'm a Hacker News addict^H^H^H^H^H^Hregular.

Access to various bits of I2C hardware probably limit the usefulness of this specific post to a narrow audience, but I should be writing a lot more about various bits of code I've done to get pure Go talking to linux at a low level -- framebuffer writing via /dev/fb, input handling of mice, touchpads, touchscreens, keyboards, etc via reading /dev/input/*, etc.

(All part of a vague New Years resolution to blog more and get more public code out there, since I've been tinkering on this stuff a lot privately for the past 8 months or so).

<comment><USER3> Excellent post! I'll be adding a RasPi to my collection soon, and I've been wrestling with an I2C 20x4 LCD. I'll definitely be rereading your blog when it arrives.

Speaking of the LCD, do you have any suggestions for finding the address of an I2C device? Is there a way to query or scan it to see at which address it responds? I just got the Sainsmart LCD2004 as a gift. Google searches about the device result in forum posts, where people have got it to work with addresses from 0x20 to 0x27 to 0x40 -- one guy had to work it out with a multimeter. Do you know of a more elegant solution than brute-forcing it?

<comment><USER2> i2cdetect?

<http://www.lm-sensors.org/wiki/man/i2cdetect>

Both the web page and the program itself will inform you that running it could cause Armageddon, but assuming all you have plugged into your i2c bus is an LCD it really shouldn't cause any harm.

On Raspbian, you'll have to apt-get install i2c-tools to install this (and you'll have to modprobe in the i2c drivers as described in my blog post). On the Adafruit distro it comes pre-installed.

Running i2cdetect on my Pi which currently has one of those LED matrix devices I talked about in the blog results in this:

      pi@raspberrypi ~ $ sudo i2cdetect 1
      WARNING! This program can confuse your I2C bus, cause data loss and worse!
      I will probe file /dev/i2c-1.
      I will probe address range 0x03-0x77.
      Continue? [Y/n] y
           0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
      00:          -- -- -- -- -- -- -- -- -- -- -- -- --
      10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
      20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
      30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
      40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
      50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
      60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
      70: 70 -- -- -- -- -- -- --

(Telling me it detected a device at 0x70, which is correct for this device). I don't have the LCD you have so I'm not sure if it is properly detected by i2cdetect, but that's what I'd try first.

<comment><USER3> Wow, thank you so much!

This obviously hadn't come up in relation to Arduino searches.

<comment><USER2> Ah, yeah, not relevant to Arduino but if you have any Linux boxes with I2C support available (which you will when your RaspPi arrives), i2cdetect is great for this sort of thing.

</comment></comment></comment></comment></comment><comment><USER4> _I certainly considered using channels here as they would make handling the potential threading issues very easy, but ultimately channels were a bad fit for reads (though writes would have worked well)_

Could you elaborate on this? I'm just starting to play with Go and I think my first thought would be "channels". What doesn't fit here? Is just the requirement that all downstream callers would need to use channels too?

<comment><USER2> I'm okay with exposing channels as part of an API. The problem was that in my experience doing async reads (especially where the data size is variable, not fixed) where you may have multiple possible callers reading from what is basically the same resource doesn't mesh too well with channels.

Say you have 3 goroutines, any of which might be requesting data from any/all of 3 connected I2C devices all on the same I2C bus. They could signal a read over a channel and then have a return channel they look for the result on, but if there is a single channel per I2C bus, how do they know the result they see is the one they asked for? (As opposed to one being asked for by another goroutine also reading from that channel). You can do it with some sort of token/id system but it gets complicated because if you read the data off the read channel and it isn't yours you have to stuff it back on there for others to read and make sure your goroutine isn't deadlocking everyone else out.

This is, of course, possible to work around while still using channels in many different ways. One way is every time a client calls Read a new channel is created to return the results, but given that the data returned is of variable size and the underlying I2C layer requires you to pass in a pointer to the data buffer being used channels don't buy you much here. Plus you end up with a lot more garbage to collect in the form of new channels being created each time Read is called, which is no big deal on a "big" computer, but when doing Go programming for smaller devices I do try to minimize the amount of garbage that needs to be collected.

When I first got into Go I wanted to do everything with channels and goroutines because where they fit they are awesome, but I've found the "essence" of Go is simplicity, not specific features, and sometimes a plain old mutex is just simpler than a more complex channel system.

And you can, of course, pretty trivially add channels on top of the I2C API like I do in the accel_dump example, where your code knows exactly what the access patterns of any single device will be (whereas the base I2C code doesn't really know or care).

<comment><USER4> Thanks, that's helpful. I've toying with porting some code I wrote (in Java) to access an embedded GSM modem over the serial port to Go as a learning exercise, hence thinking about the "right" way to handle the underlying read/write semantics.

What you say is exactly the class of problems I've previously encountered when, for example, you're trying to send an SMS via AT commands and the modem does something asynchronously (eg. RING indicator, or a periodic signal quality report), and you lose track of who's supposed to get the trailing "OK". Very tedious. In Java I implemented the equivalent of a bidi channel with some timeout tricks for buffering up entire response lines, but it wasn't much fun.

</comment></comment></comment><comment><USER5> Thanks for starting the blog! As a fellow chumby enthusiast, I've been meaning to shoot you an email asking for more detail on your cross-compiled-go-for- chumby setup.

I had plans to drop some I2C eeprom chips on a pcengines ALIX x86 SBC (to gain a small amount of non-volatile storage without need to mount CF partitions read-write), but just haven't found the motivation to work through the software side. Problem solved!

<comment><USER2> Assuming you have an environment where you can build Go already (which basically means having a working local gcc -- it only needs to be able to produce code for the system you will build the code on, it doesn't have to be a cross-compiler for the target system), it is pretty much as simple as defining those variables I mention in the blog post:

      export GOOS=linux
      export GOARCH=arm
      export GOARM=5

Then build the Go compiler tools using the src/make.bash (.bat on Windows) script that comes with the Go source code. That should build the Go compiler for that platform and stick it within your GOROOT bin directory.

Then prior to building anything you're going to put on the chumby make sure those variables are defined so Go knows which compiler to use.

Dave Cheney's tools make this easy to set up for all the different targets but if you only have one non-local target, it is probably easier to just do it manually by setting the env vars and building the Go compiler again.

<comment><USER6> If you use homebrew on osx, you can `brew install go --cross-compile-all` to get all of them built. Or `brew install go --cross-compile-common` to get the common ones (arm is in the common group).</comment></comment></comment>


Google to stop giving Android license for upcoming phones in Turkey over fine - <AUTHOR> https://www.dailysabah.com/technology/2019/12/15/google-turkey-suspends-services-for-upcoming-phones-over-fine <comment><USER2> TL93M us US15M, which seems small for Google to get upset about. These measures will likely not bother anyone except consumers.

<comment> tim-- Maybe the Turkish government could put this money into a fund that companies based there can use to create open source software to de-Google Android in response.

At least no one will be able to say then that there is no competition issues.

More information : [https://ahvalnews.com/google/google-suspends-licences- turkey...](https://ahvalnews.com/google/google-suspends-licences-turkey-after- fined-violating-competition-law)

<comment><USER3> The real obstacle to degoogled mobile OS's is not software (AOSP exists, pmOS will become usable soon, etc. etc.) but access to online services of all sorts. Google Play is a focal point for distributing the official "app" for your online service of choice. But if a whole country goes Google-free this can definitely change.

<comment><USER4> In practice, without access to Google Play people just use third party app stores like F-Droid or just download the apk from the web like on a normal computer. It really doesn't seem like that much of a loss for Turkey.

</comment></comment></comment></comment><comment><USER5> The arguments of anti-competitive behaviour are probably correct. Unfortunately Turkey is not a good example because their justice system lacks credibility in general. One would hope that a more credible player like EU or at least Germany or France really stands up against Google.

<comment><USER6> That already happened[1], the resulting change to Googles licensing terms was explicitly limited to the EU.

[1] [https://en.wikipedia.org/wiki/European_Union_vs._Google#EU%2...](https://en.wikipedia.org/wiki/European_Union_vs._Google#EU%27s_investigation)

<comment><USER5> Yes, I know that there are legal proceedings. And Google has been fined and is appealing. However, the impact for the customer has been neglectable. You cannot do banking on your phone, you cannot buy a public transit ticket or a fishing permit without Google Play Store or some serious hacking. (Apple is an alternative, but not one respecting your freedom any better).

<comment><USER7> A lot of people across the world are trying to figure out how to de-Googlify their Android phones. Now all of Turkey is suddenly _forced_ to de-Googlify their phones. Let's hope that encourages reliable alternatives to Google Play services.

</comment></comment></comment></comment><comment><USER8> It looks like more and more countries are starting to have very good reasons to partner with Huawei. It's not the kind of freedom of choice I hoped for, but it's probably better than the current duopoly.

<comment><USER9> Problem is that the leadership at Google/Apple has to publicly agree with western values. If they really believe in them or not I don't know. To some degree there is an incentive to respect e.g. human rights.

The leadership at Huawei has to be very careful if they want to state agreement or acceptance of western values. That might even put them into prison. If they dare to act on western values in their own country they might be killed.

I personally prefer the company which at least has to act as if they value my humanity than the one which outright would strip it from me anytime as there is no incentive at all to consider it.</comment></comment>


A Note of Appreciation From the Rich - <AUTHOR> http://hubski.com/pub?id=5775

<comment><USER2> They forgot to mention that they really appreciate that taxes are always discussed in terms of "income".

The truly rich have no pesky income - that's for the servants. They just have property and expenses, which their accountants, lawyers and politicians keep safe.

Hints: tax-free foundations are great, intellectual property is tax-free.

(There's a reason putative class-betrayer Gore Vidal spoke of "our owners", referring to the U.S. aristocracy.)

<comment><AUTHOR> Income? What's income? Appreciation we understand, capital gains... sure. But income? Surely, you jest.</comment></comment>


FiveThirtyEight: Hurricane Ensemble Forecasting - <AUTHOR> http://fivethirtyeight.com/features/hurricane-hermine-doesnt-exist-yet-but-experts-are-starting-to-worry/ <comment><AUTHOR> The hurricane analysis and visualization the article refers to is from the National Center for Atmospheric Research (NCAR): [http://www.ral.ucar.edu/hurricanes/realtime/current/](http://www.ral.ucar.edu/hurricanes/realtime/current/)</comment>


Ultrasonic Power Transfer Investigated Using Data from uBeam Patent Filings - <AUTHOR> http://hackaday.com/2015/10/20/the-curious-case-of-ultrasonic-power-transfer/ <comment><USER2> [http://ubeam.com](http://ubeam.com):

 _" The most recent paper to investigate the safety of ultrasound was just published [...] Of note is that this study used energy levels to tissue that were orders of magnitude higher than levels that uBeam's system uses."_

The abstract at [http://www.sciencedirect.com/science/article/pii/S0041624X15...](http://www.sciencedirect.com/science/article/pii/S0041624X15001973):

 _" Demonstrated in vitro, 0.6 W of transcutaneous ultrasound power transfer to an implant.[...] with an average RF input to electrical charging efficiency of 20%"_

So, at best, 3W is "orders of magnitude higher than levels that uBeam's system uses". That may charge your remote, but not your phone.

<comment><USER3> iPhone 5 has a 5.45wh battery. If you can place a "speaker" in your room and add 0.3w * 8 h while you sleep that's ~44% charge every night. Which could be fairly useful. Up the power or assume people spend more than 8h a day in there bedroom and plenty of people would spend up to say 200$ to have one less thing to worry about.

<comment><AUTHOR> Sure, as long as it's right in the focus of the beam. If that means putting it in one particular spot, is there any benefit over inductive chargers? That method would be faster and more efficient.

<comment><USER4> Also, not to be the old guy...cables don't bug me THAT much. I'll take USB C and charge with 100W instead, thank you very much!

<comment><USER5> I'm with you. Investors/companies have to get into their heads that power transmission will never be as easy as data transmission. There's no power Wi- Fi, only some crude expensive approximations over mediocre distances with mediocre power levels. We could instead focus on improving _cables_ (and confined power in general) -- have them available everywhere, retractable, higher power. There's hardly any physical limit to confined power transmission; if you look at trends into the future you might expect device power consumption to actually rise a little, only furthering the divide. Cables are just so more elegant.

Part of the problem not discussed here is the 'Absorption conflict': for efficient power transmission you need materials that are able to absorb very well the given form of power; but at the same time you want nothing to interact in the path of the unconfined flux. This can only be dealt with up to a point, since our everyday objects' configuration and atomic composition are not so different from the composition of a receiver. This applies to all technologies: even for resonant EM power transfer you are relying on a specific conductor geometry; thankfully there's no strong conductor in our bodies, but you will have to deal with metal parts everywhere.

Wireless information gets around this kind of limitation because power ceases to important for the capacity of a channel [1] past a threshold (roughly when the signal PSD equals the noise PSD), while the determining factor is bandwidth. So you just use a few Ghz+ radiation and you have enormous bandwidth available; once that becomes insufficient we can move to Thz+ light; and so on without much environmental concerns (just medium concerns -- atmosphere gets opaque), since power levels will be kept constant or lower.

[1] [https://en.wikipedia.org/wiki/Channel_capacity#Example_appli...](https://en.wikipedia.org/wiki/Channel_capacity#Example_application)

<comment><USER3> I can think of a single highly popular counter example which used 100% wireless power over several miles.

[https://en.m.wikipedia.org/wiki/Crystal_radio](https://en.m.wikipedia.org/wiki/Crystal_radio)

RFID are often a short range example of the same idea.

So, it's less that wireless power is useless As it is modern devices needing lots of power.

<comment><USER5> Crystal radio is an interesting concept -- but note I didn't claim it was impossible, just highly inefficient and with mediocre power/range (I couldn't find sources, but apparently it's typically 40uW with a ~1m? antenna).

Remember that's for a (usually) 50kW station -- that's 1e-9 efficiency, or 0.0000001%. Realistically I'd expect you to be able scale this to 10k's receivers to up to about 0.001%. It's not realistic to increase this power significantly due to health/electronics concerns for persons living close to the source and massive consumption -- bringing the power near a single station to 4W would consume 5GW, about 1% of total US power consumption!

Interesting to imagine a system with sightly higher frequencies (20Mhz?) dedicated to power transmission. It'd essentially be a hugely wasteful system (and expensive with high powered antennas everywhere to mitigate invsq law) which however might be able to power ultra low power sensors and gadgets. Some clever phase distribution (pseudorandom modulation should do it) system would allow location with ~15m accuracy too (even working indoors, although building refraction and reflections might be a little troublesome).

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> "even some high-profile investors that include [Mark Cuban] have not seen the uBeam working."

I don't understand how people can raise money like this. Investors usually like to actually see evidence that you are actually doing something, right? Right?

<comment><USER7> I've seen a few requests come in where I really wondered if the subject investors had any technical knowledge at all.

Investor scams are unfortunately rather common.

As soon as secrecy, a breakthrough and a very large market coincide the gullible and their money are soon parted. I personally don't think this is a bad thing because it keeps me employed, at the same time you'd wish that this sort of thing would stop because it most likely hinders genuine breakthroughs from being given the attention they deserve. Some of those get recycled a few years or decades later so not all is lost but still, a few cold fusions and AI winters and the tech industry as a whole suffers.

As for the uBeam, ultrasound is a strange medium to choose for this particular job, ultrasound is fickle, has a ton of side effects, isn't particularly efficient and interferes with living creatures in all kinds of un-desirable ways. Going the electromagnetic route would seem to be the first thing to try (and some companies are doing this and have products, maybe not 'miracle class' but they'll do the job they're designed to).

The best bet for getting rid of the charger cord are a strong reduction in required power for the phones, better battery technology, maybe micro fuel cells or some other exotic conversion technology.

Populating the world with ultrasonic transmitters with about the same range as the charge cord they replace seems to fix one minor inconvenience by replacing it with a much larger one, not a company I'd bet on.

<comment><USER6> With the opening of seed investment to the general public, I unfortunately think you're going to see a huge increase in professional investor scams. I fully expect organized crime to get involved.

Of course anyone can go blow their money at a casino and with a much lower odds of return than investing on AngelList, so I'm not sure it's an overall bad thing. Still I am concerned about loss of signal in noise and about 'winters' as you say.

<comment><USER7> In plenty of places seed investments have been open to the general public just about forever and as far as I know there have not been any major differences between the number of scams purported there versus in countries where investors need to be accredited.

Crowdfunding is currently doing a great job educating people on the risks of putting money up for vapourware but since those are not investments per se there is still a gap in that education that will surely be filled once the stops are pulled. Organized crime is already involved in investments, look no further than the LPs of some of the funds that have high visibility. That's a far quicker way to get a return than to bilk a few million out of the pockets of the gullible public at large.

</comment></comment></comment></comment><comment><USER8> Why don't startbucks really buy usb charging ports or usb charging mats and put it on their shops , if that's so important ? why don't anybody big do it?

<comment><USER9> Because they don't want to encourage people to stay longer than they already are.

<comment><USER10> Actually, I think every Starbucks in the Bay Area has induction chargers built into several tables (along with a number of charging dongles to choose between for your particular phone connector): [http://www.digitaltrends.com/mobile/starbucks-pma- wireless-c...](http://www.digitaltrends.com/mobile/starbucks-pma-wireless- charging-launched/)

<comment><USER11> Their active area is so small that an ordinary USB-A power outlet would be more useful. You have to plug the rigid coil into your device, then place it exactly over the charging circle.

<comment><USER10> Induction is a very practical solution for when you don't have your USB charging cable with you. Plus, who's going to steal the coil to use at home? And it's a pretty magical experience when you use it.

<comment><USER11> That your phone can get position info from satellites is magical. That you can bring two halves of a transformer together and get power would not have surprised an electrician from a century ago.

</comment></comment></comment></comment></comment></comment><comment><USER12> When I first heard of uBeam and their goal I did some back of the envelope calculations. Setting aside the safety issues (which are not settled, start-up CEO claims to the contrary), the biggest problem is conversion efficiency. Using some optimistic assumptions about conversion efficiencies and beam steering accuracy, I don't see how they're going to achieve even a 10% net conversion efficiency at useful distances. So I've been very skeptical about the prospects of success, yet I am very interested to be proven wrong on some of my assumptions. But the longer this product launch gets stretched out the more skeptical I get that this will ever be a product that anyone would want to buy. This is starting to feel like Theranos- the time has come to put up some real evidence.

</comment><comment><USER13> If you have a room filled with speakers basically.. You are going to have phasing issues.

<comment><USER7> And you're going to have the sum and the difference frequencies to deal with as well if the transmitters aren't perfectly synchronized. And those differences may very well be within the audible range.

<comment><USER14> If nothing else, now you've created a new type of Active Denial System

</comment></comment></comment><comment><USER15> [http://predictionbook.com/predictions/125891](http://predictionbook.com/predictions/125891) (entered back in July)

</comment><comment><USER11> Those articles mention uBeam's patent filings, but don't actually cite them. You can look at their patent applications.[1]

The overall system is described in their patent application #20120300593. This shows the overall plan: focus big transmitting transducers tightly on small receiving transducers. This resulted in a patent, #9094111. But to get the patent, they had to narrow the main claim to include "a receiver communications device adapted and configured to send input to the sender, the input comprising a power requirement that causes the sender to change a dwell time of the sender on the receiver". That's not an essential component of such a system, so it's not a broad patent.

There's an application on beam-steering, #20140281655. That's a known technology, and the USPTO has sent back a non-final rejection based on prior art. But that tells us the plan - big phased array of ultrasonic transducers aimed at a tiny target. Direct line of sight is necessary between transmitting array and pickup array.

How could they generate 155dB of ultrasonic energy? They applied for a patent on their transmit transducer, application #20140265727. That has an image of the sending transducer. It's a piezoelectric device with a silicon membrane, with a vacuum behind it. (The vacuum in back is to avoid pumping half the energy back into the device itself.) A "thin film" piezoelectric element makes the membrane vibrate. Devices like that have been built before, and the USPTO accordingly just sent them a final rejection. There's no new feature there which allows generation of more audio power than existing devices. So assume their device has performance roughly comparable to existing devices.

Here's a product list from American Piezo, a commercial supplier of high-power air ultrasonic transducers.[2] Their highest power unit that transmits into air is 119dB. uBeam is claiming 155dB. That's 36dB more, or 4000 times as much power. That device needs 30V into 2K ohms to power it, or about half a watt. So uBeam's transmitter would need about 2 kilowatts, comparable to a small clothes dryer, spread over a large number of transmitting transducers. An array 64 square would do it. The American Piezo transducer is 16mm across, so the transmitting array needs to be about a square meter. That's a big transmitting array, with 4000 elements, each with its own drive electronics. All that energy, or as least as much as they can focus, gets aimed at a tiny target.

The parent article discusses the attenuation problem. This gets worse with frequency.[4] Measured values of attenuation in air at 1MHz at 20C are between 160-165dB/m. This is huge. 1m from the transmitter, all the power is gone, used to heat the air. uBeam wants to operate in the megahertz range, but no way will that work. At 50KhZ, where most air ultrasonic systems work, attenuation is only 2dB/m. Their demo system (with about 1 foot range) used off the shelf 40KHz transducers.

This thing might work in the 50-100KHz range, with a rather large and expensive transmitter array, when the target device was facing the transmitter. Safety remains an issue; if they actually built a 155dB system, they'd have a steerable ultrasonic welder.

They could potentially build a nice demo system. Build a meter square array of off the shelf transducers running in the 50-100KHz range and mount it in a large picture frame. Cover it with speaker grille cloth, maybe with a picture silk-screened on so it looks like a framed picture. Have it scan at low power until a cooperating device reports a signal. Then focus the beam and turn the power up to full.

It's not going to be totally silent, because some harmonics will get through and some objects in the target area will vibrate with the ultrasonics and resonate at a lower frequency. But it probably wouldn't be noticeable at a noisy trade show.

You probably don't want to be near the focus of this thing.

[1] [http://www.faqs.org/patents/assignee/ubeam- inc/](http://www.faqs.org/patents/assignee/ubeam-inc/) [2] [https://www.americanpiezo.com/standard-products/air- transduc...](https://www.americanpiezo.com/standard-products/air- transducers.html) [3] [https://en.wikipedia.org/wiki/Ultrasonic_welding](https://en.wikipedia.org/wiki/Ultrasonic_welding) [4] [http://www.ndt.net/article/ultragarsas/63-2008-no.1_03-jakev...](http://www.ndt.net/article/ultragarsas/63-2008-no.1_03-jakevicius.pdf)

<comment><USER16> So, bottom line is, if the charging part doesn't work out it can still be used as an expensive steerable space heater / killing device?

<comment><USER11> It might "work", for small values of "work". With a big emitter, at moderately short range, and a receiver on the back side of a laptop screen, it might work. Modest sized conference rooms with art on the walls, for example. Small classrooms. Maybe even a Starbucks.

Emitter panels on the ceiling could charge mobile devices placed face-down for charging. A car-based system could charge devices of people using phones while driving, if you had enough short-range emitters around the car.

The line of sight limitation, though, makes it only slightly more convenient than a power cord. The electromagnetic charger people have the same problem, but they're mostly thinking "put mobile devices on charging pad on bedside table", which works but isn't selling.

<comment><USER16> > The electromagnetic charger people have the same problem

they can just build those into tables and mark the area that charges instead of having to tile an entire room with those transducers.

Having a human slightly adjust his behavior (place laptop on one of the rectangles) in exchange for reliable charging should be far less frustrating than a supposedly automatic system with lots dead zones that the user can't see.

</comment></comment></comment></comment><comment><USER17> [http://www.eevblog.com/forum/projects/the-ubeam- faq/](http://www.eevblog.com/forum/projects/the-ubeam-faq/)

Here's an extremely in-depth analysis of this new snake oil.

</comment><comment><USER13> One other thing.. Look at all there demo videos, and pictures. The size of the amp they are using to produce this volume of sound is pretty insane.

So..

1\. This is going to add to your monthly electric bill considerably.

2\. I wonder what kind of EM those amps are putting out.

</comment><comment><USER18> If these people want to milk some billionaires for whom shelling a few million is easier than taking the time to understand a technology, I say more power to them. So long as they aren't receiving taxpayer support, nor draining the lifesaving of retires, then they can sell their dream for as long as dreamers have deep pockets. Is it really any worse than homoeopathy?

A fool and his money.

<comment><USER7> > Is it really any worse than homoeopathy?

That depends on whether or not the inventors are aware of the fact that their tech likely will never work.

In that case it is fraud. In the other case it is simply some group of people that are very much ready to believe their own story and successfully transmitting that enthusiasm to investors. I've seen a couple of cases like that and it always makes me sad that reality will shatter the dream ('wouldn't it be nice if?', yes, but that does not automatically mean that it is possible...).

More often than not charisma plays an important role in these exercises in wishful thinking.

If the purveyor of new, unproven tech is aware that it does not work there is yet another class of character, the ones that think they're only 'faking it until it will inevitably work'. Just one more little kink to work out and _then_ all the reasons to fake it will disappear.

The only ones I have no compassion with are the cold hearted fraudsters who dream up their schemes knowing full well they'll never deliver. Those are - fortunately - quite rare.

<comment><USER19> I am reminded of:

[https://www.youtube.com/watch?v=DkGMY63FF3Q](https://www.youtube.com/watch?v=DkGMY63FF3Q)</comment></comment></comment>


Do you know why you want what you want? - <AUTHOR> http://liadshababo.com/2010/09/do-you-know-why-you-want-what-you-want/ <comment><USER2> From the business side of things: remember to sell benefits, not features.

<comment><USER3> I recently finished reading "Switch: How to Change Things When Change is Hard". One of the key points is that emotional motivation is crucial to successfully effectuate lasting changes. Maybe it would be more appropriate to say "remember to sell emotional benefits, not features"?

</comment></comment><comment><USER4> This is just inane.

<comment><USER5> Care to elaborate?

<comment><USER4> Everything he says is either nonsensical or completely obvious. It's almost as if he's implying that if you feel like something is true then it won't be. >we want them for the feelings we think they'll give us. >You don't want $5 million - you want what you think $5 million will give you - security, power, sense of achievement. How many people don't realise that a pile of fifty thousand paper notes isn't much good by itself?

> you don't want the things you think you want for the reasons you think you > want them. And that is just insulting. Yes we have hidden drives and > motivators but to suggest that nobody except him knows anything they want is > silly.</comment></comment></comment>


Ask HN: Why Are Conditionals Important? - <AUTHOR> Quantum Computer Engineer here: Studied Computer Engineering in school (undergrad), now I'm working on quantum computers for an unnamed company. I thought I understood computers (having worked -albeit shallowly- on literally every level from silicon manufacturing to web-development) until I started working on quantum computers...
I'd like to get some varied perspectives (theoretical or otherwise) on why conditionals (i.e. the ability to write 'if -something- do -this- else do -that-') are important to classical computer architectures/languages. Clearly they're important - something to do with the fact that without them your machine isn't actually Turing-complete. Clearly there's something about them that differentiates them from other operations - see the limits imposed by branch operations in pipelining. Perhaps I just haven't found the correct description of why they are important yet - or perhaps I am just stupid (very likely) and am incapable of understanding.
Input welcome, references appreciated. <comment><USER3> Conditionals allow a program to _react_ to the data it is presented with. This can be data from the outside world, or data from some other module internal to a program composed out of modules (i.e. subroutines, for example). Without conditionals - or their moral equivalent - programs would not be able to react to their inputs or to changes in their internal state.

\--

There are Turing-complete languages without conditionals, though - <USER2> without data, as such! An example is the lambda calculus. If you want to learn more about this, read up on "Church encoding" and "Scott encoding".

The basic idea is to use functions and the visitor pattern to encode a kind of conditional behaviour that varies with the input supplied to it.

      True = (lambda (t f) (t))
      False = (lambda (t f) (f))
      If = (lambda (b tr fa) (b tr fa))

      (lambda (x)
        (If x
            (lambda () (display "It was true!"))
            (lambda () (display "It was false!"))))

Desk check the reductions of applying that function to True and to False. The "t" and "f" arguments _to the boolean values_ act as a kind of "menu" (the visitor pattern), from which the datum selects in order to communicate what variant of data it is. The pattern extends readily to natural numbers, lists, and so on, giving a straightforward encoding of not only conditionals, but also (one-layer-deep) pattern matching.

<comment><AUTHOR> this is interesting - thanks for your response.

I'm having a hard time understanding the program you supplied though, the subsequent description did not really help (probs more my fault than your own). I certainly understand the visitor pattern (and have had a sneaky suspicion it is important) but the lambda calculus, not so much.

What type of syntax is the program you supplied in - is it more of a pseudocode or an actual formal language?

thanks for the search keywords - definitely helped - if you have a favorite textbook/arxiv reference/author on this stuff, those would be greatly appreciated as well.

<comment><USER4> The syntax is concise definition of named values where the values are all anonymous functions.

True = (lambda (t f) (t))

\-- Let True be the function that takes two parameters t and f and returns the first, t. \--

False = (lambda (t f) (f))

\-- Let False be the function that takes two parameters t and f and returns the second, f. \--

If = (lambda (b tr fa) (b tr fa))

\-- Let If be the function that takes three parameters, and applies the first parameter b to the second and third parameters. \--

Notice that if the parameter b is the True value above, 'b tr fa' will return 'tr'. If 'b' is False, 'b tr fa' will return 'fa'

      (lambda (x)
        (If x
            (lambda () (display "It was true!"))
            (lambda () (display "It was false!"))))

So it follows that this will pass either "It was true!" or "It was false!" to 'display', waving aside all the stuff you have to define that makes 'display' and STRINGS work as you'd expect.

This is where it becomes clear that you need a lazy system for this to make sense. In an eager system all three of the parameters to 'If' are evaluated and then their values are substituted into the body of 'If'. In a lazy system the expressions for the values are substituted for the parameters in the body, so only the parameter 'b' and one of the other parameters will be evaluated. __

When I play around with functional languages I would just write

      True t f = t
      False t f = f
      If b tr fa = b tr fa
      ShowIt x = If x (display "It was true!") (display "It was false!")

You could also write this in (I think this is) Scheme:

      (define True (t f) (t))
      (define False(t f) (f))
      (define If (b tr fa) (b tr fa))
      (define ShowIt (x) (If (x (display "It was true!") (display "It was false!"))))

Except that Scheme isn't usually lazy.

<comment><USER3> Yes, this is right except that the language as written is eager Scheme. You don't need a lazy system. The second and third arguments to If are nullary procedures. Their effects are delayed until invoked by whichever of True or False is supplied. Scheme's notation for invoking a nullary procedure -- `(t)`, vs `t` which just refers to the procedure -- doesn't help matters here :-)

</comment></comment></comment></comment><comment><USER5> There are styles of programming with no conditionals, especially in purely functional languages.

A common technique inside compilers is to separate out which code gets run, and which result gets used. If everything is side-effect-free, then there's no harm in running the code whose result won't get used. In highly parallel systems, you can just run both versions and select at the end. So you can rewrite:

      if foo < 2:
        a = foo
      else
        a = 2

to:

      a = phi(foo<2, 2, foo)

(the phi operator is taken from SSA notation. See [https://llvm.org/docs/LangRef.html#phi- instruction](https://llvm.org/docs/LangRef.html#phi-instruction) if you're unfamiliar)

<comment><USER6> I don't need to understand that code to tell you there is a control flow mechanism somewhere using a condition.

</comment></comment><comment><USER7> Some operations are basic enough that theoretically you can build any other operation out of them. "NAND" is commonly used as an example but in practice "nand" doesn't really map to how people think. Conditionals are another one. They are a bit more complicated in a sense (three inputs rather than two) but they map better to how people think so people actually use them in practice.

So Turing completeness is basically two things. 1: the ability to compose an arbitrary number of conditional statements. 2: the ability to keep computing recursively, until some output is true.

</comment><comment><USER8> Without conditionals, every program either terminates after a pre-specified amount of computation or never terminates. That leaves you extremely limited in what you can accomplish (less powerful than a DFA).

A DFA or maybe a 2DFA (which are equally powerful) is basically what you get when _all_ you have is conditionals.

Without that, what you have is a box that can read finite input and compute a value. Equivalent to a finite lookup table.

<comment><USER5> It's not as much of a limitation as people think. One pattern is for the program to update a state every (fixed-length) iteration. You can build any arbitrary computation on top of that.

<comment><USER9> Can you provide an example? I have a hard time believing any arbitrary computation can be build without conditionals.

<comment><USER10> I suspect they are thinking about things like cellular automata.

If you squint just right, you may think there are no conditionals. Just straight-line data flow to compute cell values based on a fixed neighborhood of the preceding state. A big fluid dynamics simulation has a similar characteristic.

However, this squinty interpretation can just as simply show you that the whole thing is just a DFA, as mentioned a few posts up! The finite mutable register just encodes the name of each state in the state machine, and each simulation cycle is just computing the next state transition within that large but finite state space.

<comment><USER9> But cellular automata have conditionals. That is the entire point of having a state in each cell and then doing something based on that state.

<comment><USER10> I suspect the confusion in this thread really boils down to a lack of agreement about what "conditional" means. I think some commenters above think it means conditionally branched instruction streams. They don't consider arithmetic or logical operators, lookup tables, and demuxers to be conditionals.

The earlier description of a cycle of functional updates to state sounds like the classic basis for latched digital circuit design. But, assuming the commenters were interested in software examples, I brought up analogous programs for cellular automata and grid simulations.

Also, since the state transition is purely functional with a finite input and output, it could theoretically be implemented with any functionally equivalent method, including flat lookup tables. No branching or conditional execution is required, even though it might be convenient.

<comment><USER9> Yeah true but I wouldn't call storing every possible result of a system in for instance a lookup table a computation. That is just precomputing all the results and then running a lookup.

If I have a lookup table of all the values of the sine and then use that lookup table to get the result of sine for specific value I haven't computed sine, I just looked it up.

<comment><USER10> I'm not sure if we're actually debating anything at this point...

A cellular automaton or other grid simulation has modularity which means that the state space for one cell is relatively small. So, you might admit that the whole thing is doing computation without caring how the cell transition function is implemented?

But, lookup tables are at one extreme, and there are plenty of other design techniques for arbitrary functional computation that avoid conditional branching. At the digital design level, you can think of a continuum of logic gates where ROMs, mux/demux, or even ALU operations all have elements that can be seen as lookup-table or computation. The difference is in the observer's mental model, more so than in actual gate structures.

At the software level, many instructions can be used for demultiplexing. So, you can compute two different potential values, e.g. in separate registers, and select between results without branching. You could use a conditional- store instruction, or some kind of swizzle/pack instruction, but without any of that you could compute a binary test result, extend it to a whole register width, and use bitwise logical operations to combine both registers while effectively selecting one or the other. The essence of whether it is computation or conditional selection is in the eye of the beholder.

This is a common way to transform some code paths for vectorization, e.g. to generate one common SIMD instruction stream that has the effect of performing different optional computations in each lane, while actually running the same instructions on all lanes.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> Conditionals actually destroy information. The way they are written does not even matter; Consider the evaluation of this functional pseudocode:

       min(a,b) := if(a < b, a, b)

Obviously, the evaluation of this function looses information about either a or b. This is of course by intention. But this is incompatible to a closed (quantum) system where information must be preserved.

Interestingly (but I think there is no deeper connection), vectorization uses masks to avoid branching. Programmatically, one implements then both branches at the same time, and on a per-data level different operations are performed. A simple pseudo-numpy example would be

       B[where(A < B)] = A
       which should actually read component by component, for
       instance, having A and B being matrices,

          B_{ij} = A_{ij}  if A_{ij} < B_{ij}
                   B_{ij}  else  ("no-op")

One can write long programs following this paradigm which frequently excel at performance at GPUs and modern day CPUs (which are actually vector machines).

<comment><AUTHOR> thanks for tying it back into quantum - also for the clarification that the way you write them doesn't matter - whether that be in terms of if/else, switch statements or actual CPU-level branch instructions.

</comment></comment><comment><USER12> Are you not approaching it a bit too much from a high level perspective?

From assembly(x86), most conditionals and loops break down to cmp/test and jmp,jx,jnx type instructions.

Computers need to make decisions based on comparisons of data or program state. You can abstract decision making however you want (e.g.: switch statements in place of if/else or usage of goto's) but the computer needs to test or compare and decide on what instruction to execute based on the result.

Let me invent a new condtional 'alot':

for i in range(0,100): alot i: exit(1)

instead of testing for boolean true/false. My conditional "alot" tests the result of the evaluation against the value range of the type,if the result is over half of the value range it executes the conditional statement (exit())

Of course I am being a bit silly but my point is my silly conditional much like if/else breaks down to comparing and jumping based on evaluation (i.e: instead of a jz/jnz it will break down to jge)

</comment><comment><USER13> To simplify, software (generally) does this:

        input >>> output

By definition the output _is conditional_ on the input, at least if the program works correctly. That's why conditional statements are important - they express the relationship between input and output.

Isn't this really basic stuff? Or am I missing something?

<comment><USER14> You can have output that's conditional on the input without having conditional statements.

How is the output of the following not conditional upon the input? Are there any conditional statements in it?

F(x, y) = x + y

<comment><USER13> > You can have output that's conditional on the input without having > conditional statements.

Yes, of course you can.

</comment></comment></comment><comment><USER15> In a trivial way, logical gates (AND, OR, etc) are conditionals. So, we need these gates to build any logical expressions. And many problems can be reduced to satisfiability, etc.

</comment><comment><USER16> Taking in input, and making decisions based on that input, are what computers are _for_. And conditionals are the simplest version of "making a decision".

</comment><comment><USER17> Most computer programs are, in practice, _difference amplifiers_. Conditionals are how they achieve that.

("Most" because you have programs like image classifiers that are trying to be _similarity amplifiers_. That turns out to be hard to do with the standard building blocks, which want to be difference amplifiers. Perhaps different building blocks would be more useful.)

<comment><AUTHOR> thought you were going to tie it back into transistors for a second there... difference amplifiers are, after all, one of the simplest circuits out there. Not so sure about similarity amplifiers

</comment></comment><comment><USER18> It is possible to approximate logical expressions without conditionals. This is an old problem in neural networks. See more here: [https://towardsdatascience.com/emulating-logical-gates- with-...](https://towardsdatascience.com/emulating-logical-gates-with-a- neural-network-75c229ec4cc9)

</comment><comment><USER19> I apologize, but I really am having a hard time understanding your question at all. Every non-trivial computation requires some kind of conditional.

The first computers were literally people, they computed. There wasn't really a lot of "conditional" work to what they did, they did _math_ (principally numerical work) like generating tables of data and compiling the results. They still needed some conditionals, like if a value was over a certain threshold, use a particular formula or change some parameter.

The early mechanical computers were largely tabulators of the same sort, but machines and not people. But as you want to express more complicated computations, you need the ability to branch. Conditionals are just a means for executing such a branch. Even the simplest of computational machines (in the theory sense) like regular expressions and deterministic finite automata include a branch or conditional element: Given input C while in state S go to state S'. A simple way to visualize this decision matrix is with a table:

      Input | S_0 | S_1
      </comment><comment></comment><comment>-----
        0   | S_0 | S_0
        1   | S_1 | S_1
      Accepting states = {S_0}

Is a simple machine that will recognize any binary string ending in '0'. In each state, a decision is made on what the next state should be based on the input. This isn't even a Turing complete system, DFAs can only recognize regular languages. This cannot be done without some sort of conditional branching capability. You may be able to encode this in a hardware description language such that the conditional is obscured or obfuscated, but it's still there.

Even trying to compute taxes or payroll depended on conditionals (income level determines which tax brackets you pay into, over a certain amount of income you've maxed out Social Security). And that was one of the earliest (commercial) uses for computational devices.

Now, the way we express conditionals may change from one language or system to another. In Erlang, you can remove a lot of `if` expressions using pattern matching, consider the simple computation of the Fibonacci numbers as an example:

      fib(0) -> 1;
      fib(1) -> 1;
      fib(N) -> fib(N-1) + fib(N-2).

A conditional is right there: If N = 0, return 1; if N = 1, return 1; else return fib(N-1)+fib(N-2). Haskell and other functional languages use similar constructs, and you can include other guards:

      fib(0) -> 1;
      fib(1) -> 1;
      fib(N) when N > 1, is_integer(N) -> fib(N-1) + fib(N-2).

This removes the potential for infinite recursion by adding an additional guard, now this function is only valid for non-negative, integral inputs. It has been transformed now to: If N = 0, return 1; if N = 1, return 1; if N > 1 and N is an integer, return fib(N-1)+fib(N-2); else signal an error.</comment>


Kaboom: Minesweeper you always lose when you guess except when you have to - <AUTHOR> https://pwmarcz.pl/kaboom/ <comment><AUTHOR> Blog post about how to go about implementing this: [https://pwmarcz.pl/blog/kaboom/](https://pwmarcz.pl/blog/kaboom/)</comment>


Google Started Investing in GTLDs Long Before Spending $25M - <AUTHOR> https://www.namehero.com/blog/google-started-investing-in-gtlds-long-before-spending-25m/

<comment><USER2> this article (and user) seems to be more spam than anything.</comment>


Apple Releases iOS 13.1.3 - <AUTHOR> https://www.macrumors.com/2019/10/15/ios-13-1-3-released/ <comment><USER2> They've been releasing a lot lately, that's for sure. Not for the best though.</comment>


CVE-2020-0688: Remote Code Execution on Microsoft Exchange Server - <AUTHOR> https://www.thezdi.com/blog/2020/2/24/cve-2020-0688-remote-code-execution-on-microsoft-exchange-server-through-fixed-cryptographic-keys <comment><USER2> The audience of people caring about Exchange will not overlap with this, but in other mail server news, it didn't get much attention here that opensmtpd had _another_ remote root hole announced yesterday, following the one from January.

So in some sense I'm glad it's not just them, Microsoft gets to have a turn too.

<comment><USER3> [https://ftp.openbsd.org/pub/OpenBSD/patches/6.6/common/021_s...](https://ftp.openbsd.org/pub/OpenBSD/patches/6.6/common/021_smtpd_envelope.patch.sig)

[https://ftp.openbsd.org/pub/OpenBSD/patches/6.6/common/019_s...](https://ftp.openbsd.org/pub/OpenBSD/patches/6.6/common/019_smtpd_exec.patch.sig)

</comment></comment><comment><USER4> > Due to the use of static keys, an authenticated attacker can trick the > server into deserializing maliciously crafted ViewState data.

Many years ago I was shocked that ASP.net will deserialize arbitrary (potentially unsafe) objects from the client and relies on signatures to ensure that parameters sent by the client were in fact round-tripped via HTTP POST from the same server.

How is __VIEWSTATE not a horrible idea???

<comment><USER5> I assume the idea behind __VIEWSTATE is that you don't have to save anything on the server side, which makes the whole architecture easier (no need for storage layer, sharing the secret between machines allows for load balancing), and you can support as many clients as possible, since you don't have to worry about the storage size.

__VIEWSTATE should be as secure as JSON Web Tokens, unless you manage to leak the secret (or as in this case, you use a shared one for all customers.)

I don't know why exactly did they choose to (de)serialize executable code, instead of using an XML or similar format, but similar choices were made (and later changed) with frameworks/libraries for other languages, so they are not the only one.

<comment><USER6> I could have some of the specifics wrong here, especially since it's been forever...

But the problem is there are some things that needed to be serialized for things like .NET remoting or firing stuff across appdomains. Things like Delegates.

Now, I -think- the intent, back in the day that ASP.NET was created, to use Code Access Security/Security Transparent Code (CAS/STC) to safely put a system like this together. But CAS/STC is pretty easy to do 'wrong' and a lot of people, rather than setting up the correct LinkDemands for individual items like Database, File IO, ETC on the specific endpoints, would just toss 'AllowPartiallyTrustedCallersAttribute' on the assembly and call it a day. This renders it CAS/STC almost worthless, to the point Microsoft half-killed this concept in Net 4.0 and in Core it's just about gone.

<comment><USER7> Handling user input is tricky, and so is (de) serialization (I seem to recall most big frameworks from ruby, via php and python through Java - all doing some form of unsafe marshaling from both xml and json).

For encrypted and signed data on the client, you get to add "crypto is hard" on top.

You get things like clear signed data - that makes it easier to de-couple verifying signatures from marshaling contained data - perhaps without checking the signature...

You get encrypted data that isn't using a proper authenticated encryption construct - and again open the door for manipulated data.

Even with proper encryption, you get key revocation wrong (left out), and there's maybe no expiry on chiper texts either - so you happily accept data encrypted and signed by a compromised or expired key.

And there's key management, like in this case, re-using a key that should be sigle client/single session.

Oh,and re-play attacks due to missing serial numbers/nonce on transactions/messages...

But yeah, sure. Like another comment mentions - in _theory_ encrypted data managed by the client is sound.. Unfortunately in practice theory isn't always right.

</comment></comment></comment></comment><comment><USER8> I think this is an amazing bug for "practical" attackers. Not quite an MS08-067 ... but also sort of better?

For lots of SMBs their OWA (plus maybe a VPN server and a web site hosted elsewhere) is their only online presence.

With this, you phish or stuff one set of user creds and now you have all their mail spools (plus all third party accounts linked to those emails) and are in a great place to pivot to domain admin.

Probably small accounting firms will be worst hit but also countless other small manufacturing and services firms.

<comment><USER9> The small accounting firm we use never sends sensitive information (e.g. tax forms, spreadsheets) in email.

<comment><USER10> I'm currently going through a process like this with a lawyer in a foreign country; they wanted me to provide banking details, proof of identity and address.

Most of the details I could supply by email but they were so worried that the emails could/would be modified that a lot of this had to be done via snail- mail, and phone-calls where I read out my banking details.

On the one hand very understandable, but on the other very frustrating.

</comment></comment></comment><comment><USER11> It wasn't clear whether this fixes existing installs with existing keys, or if its only fixed for new installations.</comment>


Ask HN: Does my idea have legs? - <AUTHOR> I am trying to validate interest in my idea. My landing page is here: https://hoggetaylor.github.io/tagged/ I hope that illustrates the idea well enough. Is this something that you would use in your app? Does it solve a real problem?<p>(If this is an inappropriate place to ask for this type of feedback, could somebody point me to a useful alternative?) <comment><USER2> It seems that those tags work only for people that have the corresponding app installed. So they are ok to share in app content but are useless for the rest of the world (which could drive install by curiosity.) I'm sure there are use cases but I don't have any to try it out. Be good at marketing and you might sell well.

</comment><comment><USER3> There isn't a use case for me. Rather than scan something, it is easier to just enter some error-ridden version in to Google and let it give me the correct result. There is no sense in scanning anything when it takes as much time or less to just Google the same word.

<comment><AUTHOR> Right this is a good point. I've had snapchat for years but have only ever actually scanned like one snapcode.

But Snapchat does use it for some pretty cool marketing campaigns. See: [https://cdn-images-1.medium.com/max/1600/1*kSlNrqD6D30K7gFcv...](https://cdn- images-1.medium.com/max/1600/1*kSlNrqD6D30K7gFcve-CTg.png)

</comment></comment><comment><USER4> Probably not, if you have to show a demo instead of describing it.

<comment><AUTHOR> I thought this is what the purpose of my landing page was for. But let me describe it.

My idea is for a tool that helps developers add branded scannable tags to their app. Think snapcodes, spotifycodes, etc. Snapcodes are a killer feature for snapchat. However, they are very non-trivial to implement. I want to make this easier for app developers and charge money for that service.

One concern I have is that my target audience, developers who want to add a snapcode like feature to their app, is probably relatively small.</comment></comment>


Earth's core far hotter than thought - <AUTHOR> http://www.bbc.co.uk/news/science-environment-22297915

<comment><USER2> This article is fascinating but as someone who doesn't know much about this discipline, I'm hoping for someone to clarify my confusion:

In the article, it states that our core has temperatures comprable to that of the sun. However, the sun is 93 million miles away while our core seems to only be approximately 4000 miles deep. Shouldn't the Earth be hotter than or are there just so many layers that the heat decreases at such a fast rate as it approaches the surface?

<comment><USER3> A lot of the radiation that the sun's core emits gets through its surface without interacting with it much.

You can infer that from <http://en.wikipedia.org/wiki/Sun>:

        Temperature:
        - Center (modeled): 1.57×10^7 K[1]
        - Photosphere (effective): 5,778 K[1]
        - Corona: ~5×10^6 K

=> The sun's surface is about its coolest part. Its core is about 3000 times as hot. That's where the solar heat comes from.

<comment><USER4> _A lot of the radiation that the sun's core emits gets through its surface without interacting with it much._

This is false. The sun is very opaque; photons from the core could take _millions of years_ to reach the surface.

<https://en.wikipedia.org/wiki/Radiation_zone>

<https://en.wikipedia.org/wiki/Solar_core#Energy_transfer>

This is the article you're looking for:

<https://en.wikipedia.org/wiki/Corona#Coronal_heating_problem>

<comment><USER5> > photons from the core could take millions of years to reach the surface.

And it would be most unlikely they'd be the same photons that started on the journey. Likely they'd be absorbed and different photons re-emitted many times.

</comment></comment></comment></comment><comment><USER6> Geologist here. Earth's thermal evolution is unsolved decades after we figured out the stars. The Sun's temperature adjusts to energy production and loss on a 10^6 yr timescale (scaling as the time for a photon to diffuse from the heart of the Sun to the cold surface): << the Sun's age. The Earth's temperature adjusts to internal energy production and surface losses on a billion year timescale: of order the Earth's age. Planets have long memories and history matters. The Sun is reasonably well-mixed. Surface spectroscopy probes the make-up of the whole star. Earth is less well-stirred. Seismic imaging of the deep earth maps the edges of vast pods of material, radioactivity unknown, composition unknown (but definitely distinct from the near-surface stuff), age unconstrained but plausibly as old as the planet [1]. Structure and composition matter [2]. It's a hard problem.

But it matters. When you look up at the night sky far from cities, for every star you see there's a habitable-zone Earth-radius planet that's closer [3]. We didn't know that six months ago. We think (for good, but circumstantial reasons) that complex life requires volcano-tectonic resurfacing - necessarily, a hot interior. Given that habitable-zone Earth-radius planets are not in short supply, the difference between fast and slow cooling for planets like Earth is the difference between a Galaxy where most every star system is habitable and one where almost all the planets are cinders.

The core-mantle boundary heat flux Q_CMB estimated in this paper constrains the mantle energy balance

d(E_mantle)/dt ~ Q_CMB - Q_surf + H_radioactive

Surface heat flux Q_surf is ~46 terawatts. Mantle radioactivity H_radioactive is not well constrained but about 10 terawatts [2]. The implication is that despite the high core heat flux, Earth's mantle is cooling fast - maybe 100 microkelvins per century. Volcanism will therefore shut down in much less time than the remaining main sequence lifetime of the Sun. Absent human intervention, the reddening of the Sun won't kill the biosphere, the Earth will.

As the mantle cools, the temperature contrast between the mantle and the core will no longer sustain core convection. Then Earth's magnetic field will power down. Without geo-dynamo shielding against galactic and solar radiation, bad things may happen: the rapid shutdown of Mars' dynamo is one hypothesis for the deterioration of Mars climate ~4 Gyr ago [4]. On the other hand, Earth's magnetic field strength decreased by a factor of 20 during the Laschamp Event ~41000 years ago [5], with no known effects on biology (or human culture).

Diamond-anvil experiments are tough; few grad students make it past quals without breaking a diamond or two. The diamond-anvil technique is hitting diminishing returns, so modest advances are (rightly) celebrated. The same is true for deep-earth seismology and mantle geochemistry. A good new method is mapping the antineutrino flux from Earth. Antineutrinos are produced by radioactive decay and move in a straight line from source to surface. Mapping the Earth with geoneutrino observatories in the deep sea would help determine the power source for plate tectonics [6].

\----

[1] Garnero & McNamara: [http://mcnamara.asu.edu/Publications/pdfs/Garnero_and_McNama...](http://mcnamara.asu.edu/Publications/pdfs/Garnero_and_McNamara_Science_2008.pdf)

[2] Korenaga, "Urey Ratio and The Structure and Evolution of Earth's Mantle", [http://people.earth.yale.edu/sites/default/files/korenaga08d...](http://people.earth.yale.edu/sites/default/files/korenaga08d.pdf) Korenaga is the best mid-career theorist actively working on this problem.

[3] New result, from several teams working independently to analyze the Kepler dataset: Caltech <http://arxiv.org/abs/1303.3013> (read this one first); Harvard team #1 <http://arxiv.org/abs/1302.1647>; Harvard team #2 <http://arxiv.org/abs/1301.0842>; Berkeley <http://arxiv.org/abs/1304.0460>. I'm assuming 0.1 stars per cubic parsec.

[4] Lillis et al: <http://seismo.berkeley.edu/~manga/lillisetal2008b.pdf>. Later work broadly supports his conclusion that the dynamo died fast and early in Mars history. SETI Institute talk: <https://www.youtube.com/watch?v=REiKzxWbzrQ> It is not known whether loss of the magnetic field had a big or small effect on the Great Drying of Mars. Measuring modern atmosphere/water loss rates from modern Mars is the goal of the MAVEN mission, which launches this Nov - <http://lasp.colorado.edu/home/maven/>

[5] Known from ice-core spikes in beryllium-10 (isotope produced by cosmic radiation hitting Earth's atmosphere) as well as magnetic paleo-intensity measurements in sediments.

[6] <http://www.phys.hawaii.edu/~sdye/hanohano.html>. A knuckle is that SSBN reactors also emit neutrinos and neutrinos cannot be shielded, so deep-sea geoneutrino detectors could be strategically destabilizing. In practice either angular resolution or massive size would be needed to make deep-sea neutrino detectors useful to militaries.

</comment><comment><USER7> So the previous estimate was 5000 C, and now it's 6000C +/- 500C, and that's "far hotter"? That doesn't seem like a huge adjustment to me.

<comment><USER8> Perhaps a ~17% change is not significant on the scale that we inhabit (20C today depending where you are), but 1000C is a lot of degrees.

<comment><USER9> Indeed. It seems this new estimate puts it into "surface of the sun" territory (5700-8800K).

<comment><USER10> I know nothing about this, but I wonder if core temp would have any impact on the habitability of a planet. We know there is the habitable zone around a star, I wonder if that body in that zone would also need a certain core temp to support life.

<comment><USER9> I don't know much about this, but my understanding is that a hot core is not itself something that life particularly needs. The effects of that hot core however (Spinning core to make a magnetosphere? Volcanic activity changing atmospheric chemistry?) are probably more important.

On the other hand, a hot core gives you deep sea thermal vents. Although I think the current prevailing theories don't have life originating near those on Earth, a hot core is certainly essential to life down there and, perhaps on another world, life could originate there.

</comment></comment></comment></comment></comment><comment><USER11> Was anyone else led by the title of this post to contemplate the difference in heat between thought and the Earth's core?

</comment><comment><USER12> It's a shame there's no good way to harness that.

<comment><USER13> Although it's admittedly difficult when the higher temperatures are hundreds or thousands of kilometers away, geothermal power plants do in fact harness that.

<comment><USER14> If I am not mistaken Iceland uses geothermal to a large extent and is very successful in doing so.

<comment><USER15> Northern California, as well:

<http://en.wikipedia.org/wiki/The_Geysers></comment></comment></comment></comment>


Tupperware: Efficient, reliable cluster management – Facebook Code - <AUTHOR> https://code.fb.com/data-center-engineering/tupperware/ <comment><USER2> A quick skim looks like it's something Facebook has put up to compete with K8s?</comment>


Uber's self-driving cars are already getting into scrapes in Pittsburgh - <AUTHOR> http://qz.com/798092/a-self-driving-uber-car-went-the-wrong-way-on-a-one-way-street-in-pittsburgh/ <comment><USER2> To be honest, I'm really impressed with what Uber has accomplished so far. As a Pittsburgh native, I can attest to the fact that urban planning seems to be total afterthought here. The number of five-way intersections, weird stoplight patterns, irregular turning lanes, and _stop signs on onramps_ (shudder) are enough to make driving here a challenge for the average human, let alone the average robot.

Driving the wrong way down a one way is, admittedly, bad, but the backup driver clearly should have been paying more attention - in fact, Uber may not have info about that incident because the driver may not have wanted to admit s/he messed up. As for the fender-bender, it seemed to be the fault of another driver.</comment>


Transparent Aluminum - <AUTHOR> http://blog.makezine.com/2012/01/17/transparent-aluminum/

<comment><USER2> The title is a little misleading.

This material is not _metallic_ transparent aluminum. It is a transparent aluminum _ceramic_.

A lot of ceramics are made (in part) of aluminum. I think that this is interesting because it's transparent.

<comment><USER3> It's phrased that way because of the Star Trek IV reference.

I think it comes up in the same scene where Scotty is flustered because the 1980's computer doesn't respond to voice commands...

<comment><USER4> "Use the mouse."

 _Scotty picks up mouse, speaks to it_

"Hello computer..."

From the comments, it seems not many people got the reference. That's a shame, as it means people are either not a fan of Star trek (blasphemy), or are not old enough to get the reference, which makes me feel antiquated.

</comment></comment></comment><comment><USER5> That other engineering news source "The Daily Mail" has a non-blacked out article on this.

[http://www.dailymail.co.uk/sciencetech/article-2088257/Star-...](http://www.dailymail.co.uk/sciencetech/article-2088257/Star- Trek-really-IS-good-guide-future--Scientists-able-produce-transparent- aluminium.html)

<comment><USER6> Non-blacked out wikipedia entry:

<http://en.m.wikipedia.org/wiki/Aluminium_oxynitride>

</comment></comment><comment><USER7> Key sentence: "successfully resists a huge, powerful .50 AP bullet that smashes easily through more than twice that thickness of conventional laminated glass armor"

So in reality this is a modest improvement (2x) over existing laminated glass armour for use where both thickness and resistance are critical (ie. probably for specialist military applications only)

<comment><USER8> How do their weights compare?

If the new stuff is the same weight by volume as conventional laminated glass, then you'd have a 50% weight savings.

If the new stuff is thinner, and lighter, then it'd be useful for applications where the current glass is too thick and/or heavy.

Also, in applications like secure windows for bank tellers and such, something thinner would probably be better aesthetically. When you're dealing with someone behind a thick sheet of glass, it puts a different tone on the interaction.

<comment><USER9> Alon is ~3.7g/cc which is about twice what ordinary glass weighs. Not sure how it compares to laminated glass. They probably use a denser glass than I'm used to for armored glass, but it's layered with other, presumably less-dense material.

</comment></comment></comment><comment><USER10> Blacked out. This SOPA thing could be really bad.

<comment><USER11> Those sites that are completely blacked out, like makezine and Wikipedia, are doing exactly what many accuse DRM of doing. Annoying their users while producing no real benefit. Google's and HN's methods are better.

ADDED: Most of them don't particularly matter to me, I rarely use Wikipedia, for example. The one that has annoyed me is the Internet Archive blackout - www.archive.org

</comment></comment><comment><USER12>
      McCoy: You know, if we give him the formula, we'll be altering the future.
      Scotty: Why? how do you know he didn't invent the thing!

</comment><comment><USER13> The Presidential limo is rumored to have its windows made out of this stuff.

<comment><USER14> I has also been used to build a tank for transporting humpback whales between the 20th and the 23rd centuries.

<comment><USER15> I heard it was designed with a manual interface as well. How quaint.

</comment></comment></comment><comment><USER16> So this is what the next macbook pro will be made of?

<comment><USER17> Only if a significant number of people show up at the Genius Bar with bullet- riddled macbooks.

<comment><USER18> Here's one to start you off.

[http://www.tomshardware.com/news/macbook-gun-shot-israel- sec...](http://www.tomshardware.com/news/macbook-gun-shot-israel- security,9269.html)

</comment></comment></comment><comment><USER19> remind me to try reading this tomorrow

</comment><comment><USER20> I was expecting some Star Trek reference in the comments. Seriously, nobody? Everyone blackened their geekdom to fight SOPA?

<comment><USER21> That was the first comment I was gonna write when I saw the title, but you beat me to it.</comment></comment>