onetwotree
Joined 11 years ago
Joined 11 years ago
1. When I consider stopping antidepressants, I'm not filled with anything like the dread I was when I thought about giving up the addictive pills.
2. I forget to take my antidepressants sometimes. I forget to refill the prescription sometimes.
3. I have never had any desire to take more than the prescribed dose of my antidepressants.
It's an important distinction, and unfortunately one that folks in the recovery community sometimes miss. In my experience the above characterization usually brings it home much better than some heavily medicalized description of addiction vs dependency.
Some C features are still not supported by dffi (but will be in future releases):
* C structures with bitfields
* functions with triadic argumentsPlease do - it's always a pleasure to help someone out of a bad situation that I've been in. And remember, fear is a prison without walls - you just have to make a decision to walk through that fear, and you're free.
I've been off the stuff for about 4 years, and I don't miss it at all. I'm actually a much better programmer without it - I don't get sucked into unimportant details, I have a more realistic sense of what I can and can't accomplish, and I'm more creative. More to the point, I have a life outside of a little bottle of pills now.
I got off of it after talking to some people who'd also gotten off - this helped alleviate my fears that I would have to give up my sweet programming career, and re-framed the problem as a matter of underused and atrophied motivation and willpower. It wasn't easy, but with a lot of love and support I managed to quit for good.
Hit me up if you want to talk - jonathan dot j dot mason, gmail.
I worked for a company a few years ago that made security software, with Ruby as a primary language, and this caused no end of frustration...
I spent a bit longer than 30 seconds looking at it though, and I think the 8 is actually significant - according to the RFC,
> "Set the two most significant bits (bits 6 and 7) of the clock_seq_hi_and_reserved to zero and one, respectively."
The right shift by `c / 4` seems to be taking care of this, at least if JavaScript's shift operator works the way I think it does.
The `1`s are to facilitate the goofy string creation trick.
The fact that there's some discussion around the meaning of the code on HN is a bad thing, of course!
Effect size is very important in this. To continue your grad student murder example, it's completely trivial to determine which plant a student was given, based on whether they are dead or not. It becomes trickier if you measured something a bit less cut-and-dry, such as the incidence of headaches, or variance in a few voxels of a noisy MRI.
Looking at it either from a machine learning or statistical point of view, using such a small sample is problematic.
This is the chronic issue with fMRI studies, since administering an fMRI is extremely expensive, and has led to some very difficult to reproduce results in the field.
Tomorrow I'll have 3 years clean and sober. I have a sick job (even by HN standards), wonderful relationships, more money than I know what to do with, a credit score that's slowly recovering, friends who actually give a fuck about me, and all that good stuff that I think a lot of us take for granted.
Recovery works, folks.
Working for a "digital innovation lab" where a big part of my job is sorting out things that developers can actually use to make cool products from Gartner report buzzword hell, I have a few thoughts about this.
Historically, AI has seen boom and bust cycles. AI, unlike other buzzword technologies, has a large cultural mythos about it - Asimov didn't write "I, EC2 Instance", after all. Thus, non-technical people have very strong and often unrealistic set of expectations around AI, so every time there are technological advances, people expect that general AI is right around the corner, and are disappointed when it doesn't materialize. Right now, we're experiencing a boom cycle as a result of the emergence of deep learning techniques. After every boom, funding dries up and investors loose interest, but the techniques that really work stick around and become part of a developers everyday toolkit.
Like all "black sorcery" technologies, AI has a ways to go in terms of building convenient tooling. Tensorflow is a huge improvement over writing low level CUDA code, but it's still too low level for folks without a strong background in mathematics and machine learning. That said, it's been improving in usability, documentation, and tooling, and just a couple of weeks I was part of a hackathon where we turned their pet recognition demo[1] into software to detect objects of interest to my company in satellite images.
At an even higher level are a number of startups (such as Clarifai[2]) that offer AI-as-a-service. In Clarifai's case, you can train your own image recognition models and apply them with a few lines in your favorite programming language (yeah, yeah, I'm shilling them a bit, but I really like their product ;-).
So at the end of the day, I think we'll all be building various kinds of AI into our products in the not-so-distant future, but you won't really need to go deep into tensorflow and similarly low level tools to do so.
[1] https://github.com/tensorflow/models/blob/master/object_dete...
There are also some (rather weak) reports that if you take the individual 18650 cells out of a tesla battery they last significantly longer than the NCA 18650s you can actually buy from Panasonic, which indicates that they might made to better manufacturing tolerances or something, but it's really all about Tesla's treating the batteries much better during use.
Li-Ion battery degradation is generally modeled as two (roughly additive) components, called calendar and cycle aging. Calendar aging is what you're talking about in your comment - it's basically determined by the temperature and state of charge. Both of these impact the rate of chemical processes that lead to loss of lithium and active material. This is what happens when the battery is sitting on the shelf.
Cycle aging, on the other hand, happens when you charge or discharge the battery and is driven mostly by the actual volume change in the anode and cathode when they get lithiated (it's quite significant, up to 15% or so in some materials). This introduces mechanical stress, which can break the protective film that forms between the electrodes and electrolyte and allow chemical degradation to proceed at a faster rate. The degree of mechanical stress is mostly determined by the depth of discharge, although rate of charge and discharge is also believed to be important. Cycle degradation is also impacted by the temperature at which the battery is cycled, in a similar way to calendar aging.
With high temperature variance (low temperatures will wreck your batteries too, and I can't recommend keeping them at 5C), calendar aging is the dominant mode. This is absolutely the case with cell phone batteries. However, electric vehicles, especially higher end ones like the Tesla, have an active cooling system that keeps the battery at a constant temperature, even when the car is "off". This is why many EVB warranties will be voided if you let them run out of charge for more than 14 days - at that point, the cooling system isn't working and your poor battery is at the mercy of the elements.
Under closely controlled temperatures, cycle aging is the most important factor, and it's dominated by depth of discharge. If you drain the battery as far as it will allow you every day, it's going to be hosed. If you only go down to about 80% of the allowed charge every other day, it'll last for quite a while. These numbers are roughly correlated, obviously, with the mileage on the car, but the relationship is not simple, and I'd caution against considering mileage to be a good determinant of battery degradation.
Some good sources if you want to learn more:
A fairly simple model of degradation (ignores charge/discharge rate): https://www.researchgate.net/publication/303890624_Modeling_...
A thesis on the subject, goes into great detail and has an excellent bibliography: http://webfiles.portal.chalmers.se/et/Lic/JensGroot.pdf