"It was so simple! Just add 3-gamma to the M-structure!" slaps forehead
457 karma · joined April 2, 2013
... or so I hope.
There's a reason smart people are good at solving problems, and it's not because they always defer to what other people 'know' to be true!
You're correct that at some point you get undesirable transients, or you just melt your cell. I do that by accident more often than I'd like, by shining infrared lasers at a photo diodes while forgetting that I've left a microscope objective in front. Expensive mistakes.
Now re: the article, if you ask me the really interesting thing here isn't being able to focus light to really small areas per se, but that they've broken the diffraction limit. This means you can form an image of an object that is smaller than a half-wavelength of light. For e.g. red light, that means you can take a picture, an optical picture, of something like, say, a mosfet on a chip. Or a virus. That's quite something.
I'll note however that I could foresee (read: speculate) a scenario where having such a tiny focus, like the solar cell scenario, could invoke a quantum mechanical effect in some special material whereby the light coupling becomes much greater, thus increasing efficiency or something. But that's just science fiction as far as I know.
PS: Sorry if this is patronizing. I know nothing about my audience ;-)
Anyhow, the relatively new Nuitka project seems to be aiming to tackle the python-to-c++ compiler problem, and seems to have a lot of promise. Really good compatibility, apparently decent speedups, and cross platform support. Works into Python3 too. I have a lot of hope!
For example, if I had anything that used numpy (which is most of my code) or Qt, or a lib that uses opengl, it would either fail outright saying "can't find blarg" or it would spin forever. Now I understand that the process of transpiling something huge like numpy and then compiling it will be fairly demanding, but I've literally left this stuff running in a tmux session for a day or two and it showed now sign of ever finishing.
I'm not asking you to debug my stuff or anything, but have you had a different experience? Is there a trick to getting Nuitka to build code that leverages the python ecosystem? I would really like to figure this out, because the alternatives are really quite terrible, IMO. If Nuitka can be made to work with build times less that a week, I think he's really on to something.
They also let you improve readability (as the article states), while being full compatible with the ordinary tuple api. In other words, I can make a named tuple where I think it will improve my own code, and then pass it into someone else's code that is expecting a tuple and it will work. If you had used a dict or somesuch in this scenario, you would have to do something to marshall the state back into a tuple before you could pass the data into some library that expects tuples, e.g. numpy or something.
Anyhow, my snarky comment was more related to the fact that this is yet another streaming media service (Netflix, Hulu, HBO, Amazon, Pandora, half of youtube, ...) that isn't available in Canada. Maybe Google will surprise me and offer it to us eventually /s
And they still wonder why people pirate things...
I have a cabinet full of other types of newer, moderately powerful laser modules which vary from pin diodes to modules the size of a AA battery, to things the size of cigars. Some of them are pretty darned powerful. Any laser modules that are water cooled would DEFINITELY not be something you would want to hold up to your face, but I also don't think that's the kind of power required for cutting hair. I'm not saying that any laser running on a AAA battery at a useful power could last a useful amount of time, if you could figure out some secret sauce method for very quickly coupling a high intensity pulse (hairs have a very small area, after all) onto some hairs at a wavelength that they like to soak up then it seems.... possible. In theory the laser wavelength and power could even be tuned dynamically to match the hairs, that is if they had somehow figured out a way to fit a Mach-Zender modulator, an electro-optical modulator and a frequency comb into a razor handle--ha!
Anyhow, I might be wrong in all this, but my point is mostly that it wouldn't take a water cooled laser to burn some hair. Come visit me in Vancouver and we can test it out (on your beard).
As far as I understand space comms--which isn't that far--the 'pilot beam' technique used by satellite links is more or less a way to get a phase lock on the signal beam, which will accurately determine the exact target location, at which point the space transmitter can use a beam-forming antenna to to jack up the power to that locale specifically, giving better SNR/bandwidth/whatever. The key bit here is that (a) the method requires that the target--i.e. your bedroom window--transmits the pilot beam up, and (b) only 'solves' the atmospheric interference issue by pointing a powerful beam accurately.
Don't get me wrong, it could probably be done with enough money, and if anybody could do it would would be the US intelligence machine. Same goes for a drone, to a lesser extent. With anything flying in the atmosphere you'll have to do deal with local vibrations on the same order as the measurement deltas you care about, but there are ways to do that too. It's interesting, thinking about it now, that a lot of what we're developing could actually be directly applied to such an endeavor, even though we're not related to such industries at all. Fun.
(I get your point though. "Just sayin'", as the phrase goes)
Depending on the level of "off the shelf" you're looking to deal with, a MIDI controller can be as simple as a USB controlled MIDI chip hooked up to some switches, or as complicated as a manually implemented digital synthesizer that talks to a USB bridge (don't try to implement a USB controller as your first, or tenth project).
Regarding kit/components, the key is trying to strike a balance between knowing what you want before you buy anything, and not waiting too long to start experimenting with real components. You can save yourself a lot of time by simulating the basic circuits in your project using a software like LTSpice[0] or TINATI[1]. They're both free and easy to use. However, simulations are never good enough, and often you don't have a model to simulate some important piece of your circuit, so the picture isn't complete. A good approach is to sketch out the circuits you want, do a quick sim or two to see if the basics like your power supply or oscillator or digital logic are going to basically do what you think, then order all the components you need from digikey. Shipping under $200 costs $8 from digikey, so it pays not to make too many orders. The bonus is that they are extremely timely with their orders (in US and Canada anyhow). Sometimes unbelievably so.
A note when ordering things from Digikey: First, make sure all the parts a in stock (check "in stock" in the search params). Back ordered parts take a long time, and for almost any part you can imagine there is a comparable replacement in stock. Second, when you want low volume stuff you'll be wanting the "cut tape", "bulk", "tube", or "tray" packaging options. "Tape and reel" or "Digi-reel" are for big rolls of one component and this the minimum order is 1000+ units. Almost everything is available in one of the low-volume options.
Regarding kits, take a look at sparkfun[2] for a wide range of boards, kits, etc. They have some good stuff and are targetted at hobbyists. A lot of their products come with not only a datasheet, but also a simplified "hookup diagram" that tells you how to wire everything up for a typical application. You can get some kits of basic components like resistors and caps, but they tend to get pricey and I always found that I would use one or two of the components up and never touch the rest, i.e. use all of the 10k resistors and the 1uF caps and nothing else. If there's a kit specifically for the project you want go for it though.
[0] http://www.linear.com/designtools/software/#LTspice
Each of those tasks can pretty well be accomplished by building standalone circuits, none of which are particularly complicated. In the process of building and debugging each one, you'll find you need to figure out how some of the more basic building blocks of electronics work, for example, capacitors, LEDs, opamps, transistors. There are a huge amount of resources out there to learn from. For anything related to arduinos or microcontrollers, just google it. I don't mean to sound condescending, it really is something that can be googled very easily with relatively high quality results (unlike some other areas of electronics, such as analog amplifier design). For some more theoretical stuff, I suggest you check out MIT OpenCourseware as well as video lectures from Standford on youtube. I blundered my way through a physics degree and an electrical engineering degree using those sites. For a more gentle introduction to some electronics concepts and applications, maybe check out this: http://electronics.wisc-online.com/Category.aspx?ID=3
Now the bad news. You can do a lot of futzing around with arduinos and leds, and that's great, but you'll soon find out that it's interaction with sensors and actuators that makes electronics interesting. To do that you will find that you need to build/use external 'hard' circuits, and to do that you will eventually need an oscilloscope. You really can't get too far in the field without one, even if it's just a hacked sound card and audio cable. I say 'bad news' because a new benchtop scope is pretty expensive. A breadboard, some wires and a soldering iron don't hurt either ;-) For components and data sheets, digikey.com and octopart.com are your friends. For breakout boards and other hobbyist accessories, sparkfun.org and adafruit.com are your friends. There's also a arduino plugin for sublimetext, in case you're like me and can't stand using that atrocious java UI.
The evolutionary path was influenced via selection. Those who made and used tools were more likely to survive/mate successfully, and those who made and used tools also tended to use them as eating utensils, which mechanically leads to an overbite. So eating with a fork doesn't directly lead to being selected for survival, but it's likely if you eat with utensils you also use other tools for things like hunting, defence, etc. and that does lead to increased survival.
For example, despite training on GPUs being very computationally intensive, I find one of the most onerous tasks to be the custom data prep/transformation/augmentation pipeline. Because these types of things are usually pretty application specific, there often isn't a ready-made toolkit that does all the heavy lifting for you (unlike the GPU training, which has Torch, Caffe, pylearn, cuda-convnet, lasagne, cxxnet...), so you end up having to roll it yourself. Often you have to run this code often, and with large data that isn't trivial. Usually you won't invest--at least, I don't--in doing custom CUDA code for this type of thing, if it's even possible, so having lots of fast CPU cores is a win. I usually write multi-threaded routines for my processing steps and run them on 8-32 cores for huge gains. So my point is that "one or two cores per GPU" is a bit of a narrow recommendation.
The same applies if you want to do 'real time' data augmentation (this is hinted at later in the article) and/or if you want to deploy with CPU only. Sure you need the GPU to do the training in a reasonable amount of time, but once you've fit your model, it might not be worth it to deploy to GPU-enabled computers if all you're doing is forward passes.
PS: This is also a place where running on EC2 can be a win. Maybe it's more economical to build a workstation, but once you're in the cloud you can spin up a few 32 core boxes to run your preprocessing really quickly, shut them down and spin up some GPU instances for training, then shut those down and spin up some mid-tier boxes to run the models through a bunch of data without breaking the bank. All in 'one place'.
As soon as you're dealing with EC2, you have to take on the mental overhead of making sure that all your configuration persists between restarts (especially if you're using spot instances!), running start up tasks, mounting EBS and paying for volumes, etc. and in my experience this all really adds up. That said, I still do use EC2 for some things. If I wave five similar models I want to run in parallel, it's as simple as spinning up five identical instances. Also, once I start training new models I can continue to use my workstation without any slowdowns.
Of course, it's all about the energy. I'm not a biologist, so I won't speak to the details of how resilient DNA is to specific types of exposure or why, but I am a physicist and I can tell you that if you blast DNA with high energy radiation, like gamma rays, it's gonna have a bad time. That said, if we want to talk about robustness in terms of what it's likely to be exposed to, then it's pretty darn robust. We are exposed to a wide band of EM radiation on a constant basis, and can even withstand exposures on the higher end without becoming 'corrupted'.
I'd also note that standard, non-specially designed electronics aren't very resilient to radiation either. Not to mention, if you could reliably read/write data using DNA, I'd expect that redundancy would become... easy. Security on the other hand...
*based on the context of this thread, I should mention that while he is a technical person, he runs Windows and does not attempt to run linux or anything else natively.
Right now I run a company where we do science. To do our science, we have to write a ton of code. Web stuff, server deployments, numerical analysis, machine learning, hardware description, USB drivers, data visualization, you name it. Over the years I've gotten pretty good at picking the right level of abstraction for the job, and it's served me very well. The key is to have foresight about your situation, and foresight only gets better with experience. When I see one of the less experienced engineers at work doing something dubious, it's usually very easy to steer them away from danger. That's the experience bit; somebody has to know better, and has to act on it.
But knowing better isn't enough. If you want your academic lab to use better coding practices, you knowing better and flatly telling them to change their ways will never work. You have to convince them that they want to do it. If you can't come up with an argument for the use of your other language, or design paradigm, or SCM software that is both factually solid and contextually relevant enough, then 9 times out of 10 you are probably not hitting on the right solution. That doesn't meant that your lab director who is refusing to change is correct in his refusal, but I'll bet you if you pitched upon a solution that was right for the situation, and put some thought into your explanation, you would get a much better reception. The same principle applies when you're pitching a new methodology out in non-academic land, it's just that more often than not both parties' expectations are already closer to being in alignment.
Why does it work? Because most people in these types of environments, such as academic coding circles, are really quite smart. If something is sensible and sufficiently low friction, they will probably go for it. So, no, bad scientific code doesn't beat 'best practices'. But a good solution beats a bad solution every.fucking.time. If you can't show people that it's a good solution, it's probably not the right thing to do. Even if your idea is the better one, if you haven't convinced the people who are going to have to deal with it of this fact, they won't understand it, they will misuse it, mess it up, screw up their research and they will blame the software engineer. And they'd be at least partially correct in doing so, because you only painted half the house.
I'd end by saying 'It's really not rocket science', but... it really might be. ;-)