aray

> Double descent with overparameterization is exhibited in "classical settings" too and mentioned in older books.

I’m curious for references or citations to this. When I was going over double descent I tried to find citations like this (just in a couple places like ML/stats textbooks).

Extraordinary claims require extraordinary evidence.

This evidence seems weak at best.

I want to be charitable, but hard to imagine this is anything other than an incredible stretching to make a topic to generate lots of clicks/views.

When do you think we will get an update to C11 or more recent version of C to MISRA? Do you all have any influence on "Safety Critical C" standards?

I'm curious if this is a (temporary, unsecure) way to use google if you're in a place that google is currently blocked.

Small chance, but in case anyone on HN is in a place google is blocked, would be an interesting test to run.

> Because threads are so sensitive to initial conditions, it ends up skewing an entire discussion.

I haven't thought about this before on HN, but it makes a lot of sense. I'm curious if you or others have written about this intuition and your experience with it -- I'd like to understand it more.

At the top of the article are two open source repo links:

Environment Generation: https://github.com/openai/multi-agent-emergence-environments

Worldgen: https://github.com/openai/mujoco-worldgen

Is this what you were looking for?

What other pigments show up in lymph nodes? Hair dyes?

Cool! I did this a while ago for some CPU-bound stuff, and ran into a bunch of performance bottlenecks.

Some things that helped me scale ptrace-interception up:

- SECCOMP_BPF filter (getting these right matters a lot)

- moving all of your intercept work to a single side (enter or exit)

- ensure affinity between the traced and tracing processes

- nuke vdso

- remove vdso from the aux vector (otherwise good libc's will find it again)

At the end of the day unfortunately the better solution would have been to write kernel support for what I wanted to do, but it's a fun exercise in learning about system calls.

Is this paper published yet? The `Article` link doesn't go anywhere, and Google Scholar doesn't know where to find a copy.

Also recommend this as a follow-on. I think it's an important point, and also well presented. The anecdotes make it memorable but it's concise where it matters.

After I read this last year it changed the way I interacted and observed things around me for a while. Poking/prodding more, and asking more "what/how" questions.

That article is about the FDA and a melanoma drug. I don't think it has anything to do with Cray or patents.

Possibly mis-copied link?

Congrats! Is there a short summary about how your approach is different from existing stacks (like tensorflow, or nnvm)?

It looks like nvidia GPUs treat denormals as zeros for single-precision floating point math: http://developer.download.nvidia.com/assets/cuda/files/NVIDI... (sections 4.1 and 4.2)

Syscall interception works for _every_ program, it's just a matter of doing it correctly.

VDSO is a small set of (3) calls which are not syscalls but direct calls (for speed/efficiency). Our goal is to remove this functionality to force libs to call through the (slower) syscall route instead.

I mention in another comment how EHDR censoring is needed for robust VDSO removal.

I've not run into a libc where censoring EHDR breaks time calls (i.e. it doesn't fallback to syscalls) but possibly golang has this.

In this case it's straightforward to setup a fake VDSO and then instead of EHDR censoring you just replace it with your fake VDSO address and you're golden!

This depends on the virtual machine or container!

Ironically, because the folks working on containers/VMs are _really_ good at what they do, time access calls in particular have been really optimized (they get called a lot). This makes it very hard to intercept time calls at this layer! e.g. KVM and LXC both essentially hand time calls straight to the host.

This means time intercepts at the VM/container layer need fundamental support (I mentioned affine time transformation in the linux kernel in another comment) which doesn't work for people who need to deploy on current hosted container.

Libfaketime is great, especially if you have a good idea what time calls your target process is using.

If they're inspecting EHDR and calling VDSO directly, though, or they've statically compiled in their libc, then it won't help though.

I've also had a lot of issues getting it into tightly sandboxed contexts (e.g. the flash runtime in chrome).

Nice Implementation! I built something similar a while ago to warp time in video games (for training reinforcement learning agents).

Some issues off the top of my head (that I ran into): VDSO censoring is a lot harder than just symbol overriding, it has to actually be removed from the aux vector (third thing on the process stack when the process launches after arguments and environment variables. The EHDR entry is what you need to remove.

Gist for censoring EHDR: https://gist.github.com/machinaut/a08b581c921775263cf0e20ccc...

Some libc's (notably glibc) are really good at finding/using EHDR even if you do that symbol overriding, so dumping EHDR is the most assured way of making sure it's gone.

ptrace overhead is HUGE -- because you're debugging a userspace program with another program every time call now results in 4 context switches (to/from your debugging program at every time call entry/exit), even pinning both to the same CPU this is not fast.

This is where my least favorite part of the linux kernel comes in handy: SECCOMP-BPF. Instead of firing _every_ syscall, you can write a syscall packet filter rules list that only matches certain time-based syscalls with certain arguments. This greatly improves the performance (but for me, still not fast enough to play video games live).

At the end of the day I ended up reviving a >10 year old patch someone sent to the linux kernel to add these parameters (time offset and time warp) to thread structs and do the warping in the kernel (much faster -- dont pay the context overhead, etc). Sadly even this didn't work because our end application needed to run on multiple clouds in docker, and we'd need to have access to the host kernel to do these operations.

I'd like to have an affine time warp as part of the cgroups, and then maybe extend it through runc so anyone can run time-warped docker containers, but maybe that's wishful thinking.

Overall I think this is great work, and super happy you posted it. I'd love to chat about it sometime.

(P.S. most ironic to me was my version of this was called 'timelord' :)

Good intuitions. FCC regulations restrict EIRP[0], which is essentially "what is the signal strength in the strongest direction". It's possible that increasing directionality of your antenna puts you over the EIRP limit (given how routers already try to get _really_ close to it to improve performance).

[0] https://en.wikipedia.org/wiki/Equivalent_isotropically_radia...

It looks like we're moving towards a solution (in a slow, jerky, shambling way) with replacing hardcoded boardfiles with device trees.

If RISC-V does this well out of the gate (like with IBM's old school Open Firmware) and has great shiny device tree support, I think we might end up like x86 -- where a single thumbdrive can boot almost any x86 machine under the sun.

Followed the original RepRap project as a college student. A bunch of us students tried to do a group build of the RepRap Huxleys. It was way too much work to try off the bat in order to get a working printer.

After a run-in with a RepRap Mondo (it's big but it has a lot of issues, the design ended up not being that popular) bits-for-bytes RapMan printers (purchased by the industrial engineering department) and MakerBots (some folks at a local TechShop had them), we eventually got an Ultimaker kit.

It was amazing. Fast prints, cheap (compared to some), good-quality software, the assembly was straightforward and fast, instructions were thorough (compared to many other printers we've worked with), and print quality was good with almost no tuning.

Now graduated, I own an Ultimaker and whole-heartedly recommend it. Not only is it a good printer by itself, it has quite a clever community of inventors around it, and 3D-printed parts and improvements to Ultimakers appear with shocking regularity. (As opposed to makerbot, which is more of a professional printer in that less folks tend to modify them).

Cura, the software used to control ultimaker, has come leaps and bounds farther than what it started as. It's now easily mistaken for professional paid software, and it's easy enough that even someone with no experience can hop on and start printing.

Also shout-out to octoprint, which uses a Raspberry Pi to control the printer (3-hours of printing an awesome part rock, but not having your laptop tied to the printer for that long).

https://www.ultimaker.com/

Also, the creators have been working on a short made-for-youtube cartoon show (~5 minute episodes) called "Bravest Warriors". If anyone here likes Adventure Time, check it out:

http://bravestwarriors.cartoonhangover.com/

(Also the character designer from Adventure Time is working on a new cartoon called Bee & PuppyCat, also in a similar awesome vein http://beeandpuppycat.cartoonhangover.com/)

I'd doubt this because the rate of de-complexation is usually pretty low (which is why it's useful as a mechanism for slowed drug delivery -- the cyclodextrin-complexed compounds move around much more easily than the usually-hydrophobic drug de-complexes from the cyclodextrin).

Edit: reading the application -- this doesn't appear to be cyclodextrins, but some configuration of small-chain length glucose polymers (mentioned 1-20 with an average of 10).

I used to worry about that as well, but then I found when I tried to make comments really meaningful and useful, I couldn't quite get them just right.

Now I view comments as a means of continuous practice, so even if there's no recognition by means of votes, I'm still improving my ability to contribute positively.

It can be setup on Ubuntu https://plus.sandbox.google.com/+FrancoisBeaufort/posts/2fHN...

Thanks! Great example. Does it look like the large camera is focusing a few inches back from the front of the ball and the Google Camera is sharpest at the center of the ball?

Edit: I was trying to look at the sharpness of features on the ball -- specifically the lettering on the left side.

They have large-aperture digital cameras that are similar already: http://store.sony.com/smartphone-attachable-lens-style-camer...

I'm interested why you'd want DSLR, though, because if it attaches to my phone i'd probably be happy to use the phone screen as the viewfinder and save the depth and weight that would otherwise go to a moving mirror assembly.

I'd love to see some test images with that (just get a side-by-side with the app and a larger aperture camera).

As I understand what you're proposing, I'm not sure it would actually be closer to what a large-aperture camera would capture. The light field from the farther depth field should be convolving with the light field from the near depth field.

Still, side-by-side would be the best way to view these :) I'll do it later this weekend if I get the chance.

Synthetic aperture-like algorithms are also common at SIGGRAPH if you go through the past two decades.

A quick search didn't unearth any, but there is open source software to do parallax depth inferencing, and you could just apply proportional gaussian blur kernels to each depth segment to get a very similar effect.

Could you speak to how familiar photojournalists are with the math and transformations that take place inside a digital camera?

For example, almost certainly your cameras have dead pixels, which are processed away during the demosaicing stage, but showing them would be a "straight off the camera image" that I doubt any photojournalist would desire.

Additionally many scene-wide process steps (like lens shading map estimation) can be changed in post-processing if the cameras automatic algorithms (3a, etc) "decided" wrong.

There have been multiple implementations of this class of algorithm (collectively "synthetic aperture") using different techniques.

Edit: below mentions the HTC "double camera" phones, and in fact it's also possible to create synthetic aperture photography with multiple cameras instead of moving a single camera to multiple positions. Then you have the added advantage of not needing to assume a static scene! But a single-camera algorithm is great for rolling out to the common devices most of us have in our pockets.

Marc Levoy's SynthCam used a circular wiping motion, and attempted to "paint" the 3d space occupied by your theoretical processed aperture.

This Google Camera only requires a single linear move, and processes the rest!