staticfloat

This is pretty easily fixed by doing white balance correction. One piece of the barcode is always kept white, and it is used for color calibration. assuming the color transformation is constant across the entire code (which is the case in your example) you can undo some pretty large color shifts.

Google uses it on their TPUs [0]. If you're interested in how it would effect the numerical stability of an algorithm you want to use, there is a Julia package that makes prototyping linear algebra over this datatype pretty straightforward [1].

[0] https://cloud.google.com/tpu/docs/system-architecture

[1] https://github.com/JuliaComputing/BFloat16s.jl

I believe it's called the "Vapor Chamber": https://www.vapor.io/chamber/

I’m not sure what you’re referring to when you say 100x cheaper. Googling “LEO satellite antenna” will result in plenty of hits that are well below $2000. As I said before, the $20 price point was for manufacturing of the antenna itself (micro strip antennas are very cheap, materials-wise) and so do not include any of the other auxiliary systems needed such as a radio transmitter, an amplifier, etc, although for LEO you dont need to shout very loud to be heard by the satellites.

In my antenna design course in graduate school, our Professor had insider information about the specifications the Starlink people were targeting for their mobile ground stations. He gave designing a similar antenna system as one of the final projects for the course. The exact numbers aren't important (nor are they really a tight secret; if you are well-versed in antenna design I imagine you could spend 10 minutes and come up with a list of specifications that are pretty close to what we were given in the course). We found that the mobile base station would be neither complex to construct, nor expensive (Conservatively <$100. We were focused on the antenna (with the right manufacturing deals we estimated ~$15-20 for total antenna fabrication costs) and we didn't investigate the radio or amplifier too thoroughly so we just budgeted $80 for those pieces and called it good).

The fundamental requirements were things like: at least X dB main lobe gain, electrically steerable to any point within a the cone 60 degrees off of azimuth, total physical size less than .5 m^2, operates at Y.YY GHz with resonant bandwidth of Z.ZZ GHz, etc... The design my team went with was an array of microstrip antennas with a network of phase shifters to electrically steer the signal via beamforming. It's actually quite amazing what you can do if you just get the right shape of metal to vibrate at the frequencies you pump into it. Antenna design is a wonderful confluence of mathematics, design and black magic.

1. No, asynchronous means something different than multiple clocks. Think of it like the difference between polling based programming and using coroutines; with multiple clock domains you have separate sections of your chip performing tasks at predefined instants in time (when your clock signal rises/when your polling loop swings around again) but with a truly asynchronous design, you simply start processing the next chunk of work when the previous chunk is finished (when the previous chunk of logic drives a signal high/when the previous coroutine finishes and control flow resumes in your coroutine).

2. It does deliver some benefits, but not all. Truly clockless design is desirable in some cases due to power concerns; for example the Novelda Xethru ultra-wideband radar SoCs are actually clockless, because power distribution networks can account for 20%+ of the power consumed in chips like this. (This is what I've heard, I don't have a citation for this. The paper I quote below similarly handwaves and throws around numbers from 26% all the way up to 40%, but they don't do any analysis of their own on this)

I've never used a clockless CPU design before, but the theoretical advantages are listed out quite nicely in this paper [0], which lists (among other things) the natural ability for the CPU to sit at idle (not executing `NOP` instructions, actually idle) when no work is available. It appears that the AMULET 3 processor (which is compared against an ARM 9 core) is competitive in power consumption, but doesn't quite stand up in performance. While still pretty impressive for a research project, this shows that we do still have quite a bit of work to do before these chips are ruling the world (if, indeed, we can scale up our tools to the point that designing these isn't just an exercise in frustration).

[0]: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.83....

All of the heavy Minecraft players I know (10+ people) play adventure mode exclusively. I don’t know anyone that plays creative mode for more than about 10 minutes before getting bored with it.

If you haven't yet, you should check out a build of 1.0. The start-up time is _greatly_ improved. Basic startup time is twice as fast as ipython for me now:

$ time ipython -c '1+1' Out[1]: 2

real 0m0.493s user 0m0.401s sys 0m0.063s

$ time julia -e '1+1'

real 0m0.222s user 0m0.115s sys 0m0.101s

Yes, python itself is still much faster. I compare against ipython just because that used to be my go-to interactive shell for technical computing.

The README for that package [0] states:

> Note that FFTW is licensed under GPLv2 or higher (see its license file), but the bindings to the library in this package, FFTW.jl, are licensed under MIT. This means that code using the FFTW library via the FFTW.jl bindings is subject to FFTW's licensing terms.

If you have an idea on how to make that clearer, we would be happy to review a PR to the FFTW.jl repository.

[0] https://github.com/JuliaMath/FFTW.jl

This is actually a pretty good argument for sparse data handling; push some intelligence out to the edges of your network (e.g. the spy satellites or what have you) that are collecting the data in the first place, and then only store "interesting" pixels. E.g. regions where there are movement; regions already determined to be of interest (densely populated areas, war zones, trading vessel corridors, etc....)

There is research going on right now to build native camera systems that emit data (at the hardware level) that is not dense but rather sparse; information is transmitted as "blocks of pixels that changed between frame two and three" rather than "here is the state of all pixels at frame two, and here is the state of all pixels at frame three". In essence, doing a small amount of delta compression within the hardware itself.

This seems like a really natural fit for an application such as this one; and could potentially cut the amount of data needed to be paid attention to down by orders of magnitude.

Many of these ideas are similar to what is used to compress video down in the first place; it would be interesting to see a combination of video compression technology and "region of interest" ML pruning, where the ML models are applied only to interesting regions, as identified by the compression codec. The codec already has done the analysis to figure out which portions of the video have changed, which portions of the video are simply shifted versions of information from the last frame, etc.... You could significantly speed up ML analysis by making use of that kind of information.

As the linked article states, all personally identifiable information is removed, but you still want to be able to say "Alice worked with Bob in folder 1, and that same Alice worked with Charlie in folder 2", so you assign unique identifiers to each user, such that you can't tie Alice to "Prof. Smith at University of Chicago", but you can tie folder 1 and folder 2 to the same Alice.

The numbers I've seen for a TPU v3 pod are ~100 PFLOPs, whereas this article claims over 3 EFLOPs, so that's at least 30 TPU v3 pods. Arguments about how useful FLOPs as a measure actually are aside, that's still quite a lot of computing power.

One difference is gravitational pull; martian gravity is ~2x lunar gravity, which makes the solar wind an even larger danger to any atmosphere you would generate. The distances from the moon's surface at which atmosphere could be stripped away would be proportionally shorter.

In either case, the technological breakthroughs we would need in order to actually generate a useful atmosphere are large enough that I would be very excited to just see the byproducts of such breakthroughs.

Just a minor nitpick that ResNet is the model you are referring to, ImageNet is the dataset that ResNet is trained on.

I too don't use the app, but I use https://mbasic.facebook.com, which allows messenger use without an app.

This reminds me of an old story I read in an anthology called "Stealing the Network: How to Own the Box"; it was a series of modern-day hacking short stories loosely tied together through an overarching theme, and each chapter was written by a different professional in the security field. Fun reads, and an interesting introduction to many of the tools and practices of security pros, if a little fanciful at times. :)

The particular chapter I was thinking of was named "The Worm Turns".

Amazingly, I can actually speak to this. I'm Ph.D. student in Shwetak Patel's lab, and yes, this looks to be extremely similar to the ElectriSense [1] work done by Sidhant Gupta (now at Microsoft Research).

The water analogue was Eric Larson's Ph.D. work, and was much more difficult from a DSP perspective due to two separate issues:

* When water is flowing without turbulence (laminar flow) it doesn't leave much of a signature on flow or pressure sensors

* Any kind of signature that does exist is often changed significantly depending on the network of pipes that stand between the single point sensor and the source of the water event.

For these two reasons it took a while for us to work out a high enough accuracy for the water stuff (in the end we used a water pressure sensor plugged in close to your water heater as a fairly central point that most people can access easily) and that was published as HydroSense [2]. We like our *Sense names. :P

HydroSense was indeed bought up by Belkin, and they are pushing it forward in a way that we just cannot do in academia, so that's a good thing. ElectriSense I don't remember exactly what the IP status of it is, but I do know at least one student was working on some interesting extensions of it that may be published in the next year.

[1] http://ubicomplab.cs.washington.edu/publications/electrisens... [2] http://ubicomplab.cs.washington.edu/publications/a-longitudi...

It depends on what you want to keep constant between hosts; for many (dare I say most?) projects, docker will provide a sufficiently identical environment that it "just works", because the filesystem as seen by the same image on two different computers will be exactly the same. This is sufficient for many, many projects, and is the primary source of "works for me" problems, in my experience.

However, if your application requires things like the CPU architecture set is the same, or the amount of memory available to the process is the same, etc... then no, docker will not give you this level of "sameness". I have had bugs that manifested on one docker host and not another because one host had certain x86 extensions available (AVX, or something similar) and the other didn't, and this caused a certain codepath to be followed. However this is probably extremely rare for non-performance-targeted code, as most projects will compile for a conservative subset of x86_64 instructions so that they can run everywhere.

Anecdotally, I find learning the "Docker way" has transformed my development paradigm in a much more fundamental way than Vagrant ever did, mostly because docker containers are almost instantaneous to start, which enables their use for a whole range of applications that I would never have even considered for something like Vagrant. Because I can launch a docker container in ~300ms, I can use containers like native applications. I do everything from building software to compiling latex documents using docker just so that I don't have to worry about installing toolchains or configuring things just right; I get an image that does what I want, and then I invoke the docker containers as if I were invoking the actual tools themselves.

Docker is just a tool, but it's a darned powerful one, and it's pretty fun to see how it continues to evolve right now. I highly suggest you check it out.

Top poster may also be interested in ICASSP, which bothers itself more with the algorithms of speech/audio processing than the applications of said processing.

Does it bother anyone else that the audio is so highly edited? They're literally stitching together sentences that she did not say. I'm used to videos cutting phrases together, but they're cutting individual words together in a way I've never see^B^B^B heard before.

Agreed, but since those two concerns are separate (algorithmic improvement vs. taking advantage of parallel hardware) I'm not sure I'd categorize this as "missing the mark" so much as that's a further improvement that could be made. For a blog post that looks to be an attempt to tout methods to easily exploit data parallelism, I think focusing on algorithmic improvement would be counter productive.

With the recursive nature of DNS, I imagine that could get a little hairy as the DDoS'ers would then be targeting whichever DNS servers they were using.