You can actually make it work and still maintain pseudonymity. A primary key could register a backup key by generating a site-specific keypair, encrypting the site private key using the backup base public key, and then using the encrypted site private key as the key handle. The primary key would need to know the backup key's base public key, but not it's base private key, and each site would still get a unique public key and key handle.
I use the TSC for high precision timing, and turning TSC ticks into nanoseconds requires interpreting model specific registers, so my timing code would need AMD specific patches to work properly on those processors. Not necessarily a deal-breaker, but it would definitely be an annoyance for me if I did decide to switch. Probably not super relevant to scientific computing or ML though.
In the event a primary care/urgent care doc disagrees with a hospitalist on the need for admission, why is sending them to the ED the right move? I was under the impression the ED is mostly for triage, and it seems like patients in this situation have already been triaged. It also seems like the sort of disagreement about the need for admission between urgent care and hospitalist is also going to happen sometimes between ED docs and hospitalists. How do those disputes get resolved?
From a legal standpoint, the relevant language is "no benefits shall be paid to an individual under this chapter for... the period of unemployment... after the individual has left work (1) voluntarily..."[1]. I hope we can agree the employee did not leave voluntarily. There is no statutory language I could find that makes the fact that the employee intended to leave at some point after the date of actual separation relevant to the eligibility for benefits.
Ethically, the thing I have the biggest problem with is the employer characterizing the circumstances of the separation as anything other than a firing on November 1st. Effectively they are trying to say they fired the person on November 1st, then they rehired that person on January 1st, at which point they immediately resigned. I just don't think that's an accurate description of the circumstances.
Unemployment benefits are likely to be substantially less than wages. In Massachusetts, unemployment benefits are about 50% of wages, with a cap of $795 per week (which works out to an annualized rate of $41,340/year). So the employee is probably in worse financial shape than they expected to be.
IMO, the issue here isn't wrongful termination, it's providing false information to the state. Firing someone because they intend to resign in the future is probably legal, but it doesn't change the fact that they were fired. It sounds like the employer reported that they resigned, which simply isn't true.
I doubt it. HFT is a shrinking industry. Solarflare implements their high end NICs using FPGAs, so they have deep expertise in FPGA implementations of network stuff, as well as integrating those implementations with the host OS (ie, writing drivers). My guess is they're interested in offerings related to what's commonly called "software defined networking": running multiple virtual networks over a single physical network, dynamic route optimization, load balancing, etc. This is a key building block of cloud computing, which is a fast growing industry. Implementing it in FPGA firmware instead of actual software makes a lot of sense, so I suspect Xilinx is planning to improve it's offerings in this area.
One thing to keep in mind is that although there are a lot of elementary and high schools that do a bad job teaching math in the US, there's also a lot that do a good job. Kids that struggle in math in high school and/or come from high schools with poor programs mostly don't even try doing it in college. One other observation I've made is that people who do poorly in what I would think of as engineering math (calc 1-3, linear algebra, differential equations, probability and statistics, CS theory classes) often have more trouble doing the algebra error free than doing the "complicated" parts of problems. It's possible spending more time on algebra is actually beneficial to doing well in college level math.
It's not insurance fraud (or fraud of any kind). Fraud is theft by deception. Your car fire example is fraud because to get the payout you have to lie to the insurance company about why the car caught on fire. Car insurance contracts quite explicitly exclude coverage for intentional damage, so if you tell them you set it on fire on purpose, they won't pay you.
In this instance, the "insurance" is actually a credit default swap (CDS). CDS contracts do not exclude "coverage" in cases where the "insured" provokes the company into default. There's no need for deception to make the scheme work, meaning it's not fraud.
The CDS contracts are put together by an industry association called ISDA, with a lot of input from very sophisticated market participants and their very expensive lawyers. It was most likely a conscious decision to make the contract work that way. Anybody who got burned by this directly either knew it was possible or should have known it.
How much data do you sync? I'm syncing 60 GB with NextCloud and it annoys me frequently: every time I log in it spends 5 minutes scanning my data, pegging at least one core of CPU and using up a lot of my I/O capacity. And of course at a pretty annoying time, since I almost always want to be actually using my machine during the first 5 minutes after logging in. And I'd really like to be syncing more data. Anyway, wondering if syncthing does better in this respect.
The first thing I would say is don't let your age stop you.
The next thing obviously is that you'll need to learn how to write software. I'd recommend you work through a few beginner tutorials and then pick a project and just start working on it. I don't have a huge sample size, but people I know who've started learning to write software because they wanted a problem solved and thought it could be done with software have generally succeeded in learning, while those who just have a vague desire to learn generally don't.
If you can't find a project that interests you, I'd look into boot camps or just going back to a traditional college for a degree in CS. Those paths will have the additional advantage of putting you at the start of a pretty clear pathway towards getting a job.
As far as finding a job, I suspect you can leverage your lab/bio background. Domain expertise is very useful in software development. Looking for jobs with companies that can use your background can help you compete with others who might have stronger software backgrounds.
One example from my line of work that could conceivably translate to web-land would be parsing numbers. I wrote a version of double.Parse() with less features for an order of magnitude speedup. The program was doing data analysis on a bunch of CSV files, and just parsing the files was way slower than EBS I/O.
How common are scenarios where there are multiple ships within visual distance? From reading the account of the collision, it seems like everybody relied primarily on one radar to make navigation decisions, and that radar was either broken, or its operators didn't know how to use it. It's hard for me to understand how they didn't realize they weren't getting useful data from that radar and switch their primary navigation driver to the other radars, lookouts, the commercial position broadcasting system, or the infrared camera, all of which seemingly worked. Unless of course actually navigating around other ships is pretty uncommon.
What you describe only works for cash basis taxpayers. Public companies are all accrual basis taxpayers. Under accrual accounting increasing your inventory affects the financial statements as follows:
* Balance sheet: decreases cash/cash equivalents entry and increases the inventory balance sheet entry (in equal amounts), resulting in no change to net assets or equity
* Income statement: no effect
* Cash flow statement: will show up as a change to inventory, reducing operating cash flow and total cash flow
Company executives are often smart, and often know their business better than anyone else, but they're also biased. What comes out of a CEO's mouth is very likely to have more to do with what he or she wants _you_ to think than with what _they_ actually think. So taking CEO's grand theories with a grain of salt is in general a good idea for investors.
As to why margins matter... Bezos' quote talks about how valuations are multiples of cash flows. This is true, but multiples aren't constants. Basic investment theory suggests that the multiple should be an increasing function of the company's growth rate, its ratio of sales to assets, and its margins. So if you want to maximize your company's value you ought to be concerned with all of those things. Which isn't to say that trading lower margins for higher growth is a bad decision in Amazon's case, but it's not like it's an irrelevant number.
Trackers don't care if they're wrong some of the time. The prediction problems they're using the data to build models for are pretty noisy anyway. If using inexact identifiers improves their model, they'll get used.
Many technically dynamic IPs change only rarely... I think my home Comcast IP has changed once in the last 2.5 year. So the correlation between a Comcast IP and a perfect household identifier is going to be pretty good. If you have a dataset that's got search history timestamped and labeled with IP, it's probably pretty easy to figure out the physical address that goes with the IP from map searches. Cross-reference an address to name database and now you've got a dataset with each household's (labeled by name and address, with some error) search history.
Manuals are not really for reading cover to cover. You generally want to use the table of contents, the index, or searching of some variety (google, ctrl-f, whatever) to narrow in on exactly what you want to know. A few scenarios I find them useful:
(1) If you're getting conflicting advice from blogs and stack overflow: this is often the case when software is changing fast. Manuals are often explicitly versioned to match the software, so if the manual covers the topic you care about, going to the latest manual is a great way of figuring out which advice is current.
(2) Skimming the index: a quick way of discovering topics you can then explore in more detail either in the manual itself or through follow up googling.
(3) A manual you know and love. Over time you get a feel for which manuals you interact with are good. If a manual is good and you've gotten comfortable reading it, it's often faster to find the answer you're looking for by searching the manual directly rather than wading through a google search.
The fair value of SVXY at 4:15 using the usual formulas was around $4, but it was trading around $70 at that time. However a lot of that price movement was due to essentially flash-crash type movement in the last minute of trading in the VIX futures. This introduced two problems for potential arbitrageurs. For XIV, the problem was that it was possible that CFE would bust trades at the extreme price levels, leading to a revised closing price and corresponding payout on the ETN. For SVXY, the problem was that it was possible that the extreme conditions had caused the fund managers to deviate from their target position, and thus hadn't actually lost as much money as they were supposed to based on their stated objectives. CFE never busted trades, but SVXY did end up deviating significantly from their target position, in the form of not taking off as much risk as they should have at 4:15. They ended up working the remaining order slowly through the overnight session and the following morning until about 10 am the next day. They got better prices on the make up hedge than the 4:15 price, which is why it opened the next day around $11 (which was a fair price) instead of $4. They made an extra $7/share by deviating from their objective. It could easily have been much bigger, and speculation about how much they hedged and at what prices is, in my opinion, why the price movement wasn't immediate.
I'm not an expert in this stuff, but my understanding is that the scope of discovery allowed in each individual arbitration is likely to be substantially less than that which would be allowed in a class action lawsuit. A class action would be able to demonstrate coordinated wrongdoing by presenting evidence from a representative subset of low-level employees, along with testimony from high level employees and huge troves of emails and internal documents. That type of evidence would be sufficient to generalize from what happened to the small subset of employees to what happened to all the class members. An individual arbitration however is likely going to be limited to gathering testimony of the specific low-level employees involved in the specific case under consideration. Without that evidence of centrally coordinated wrongdoing, the proof in one case is not likely to be useful in other individual arbitrations. And because of that, there's not nearly as much economy of scale in doing large numbers of individual cases as there is in class actions.
People with sleep problems are often advised to quit caffeine. Many women who are or who expect to become pregnant also quit over concerns it may harm the fetus.
It's not cost effective. In this case, it's looking like each arbitration proceeding will cost the employee that files it $400 in arbitration fees, and they will win at most ~$1000. Assuming $200/hour for lawyers (ha! if only), if they spend more than 3 hours dealing with it, they lose. The only reason they're going this route is because it will cost Chipotle even more: $1100 in filing fees, plus the hourly rate of the arbitrator (likely ~$1000/hour), plus their own legal fees. So it's a useful harassing tactic on the part of the class action lawyers.
A very good point. Most of my GC whispering is done in .NET, which also has value types, but I was guessing that escape analysis in Java would solve most of the problems in this regard. Is that not actually the case?
I was with you until you mentioned branch prediction... isn't branch prediction a hardware feature? How do you trick the HW branch predictor into predicting the unlikely case?
One important thing to know is that allocating memory in C or C++ has high and/or unpredictable latency relative to the target latency of HFT code. So for critical paths, you end up needing to do the same kind of pre-allocation tricks in C/C++ that you would need to do in Java. There is some benefit to being able to write more natural code in the non-critical paths, but that has to be weighed against the overall development advantages that lead people to choose Java over C/C++ in other industries.