yold__

Seconding that. Although Firebug was wonderful, cross-platform development was not (IE and FireFox). Example of "quirks mode" nonesense:

1. The "hidden" element at the root of the IE DOM tree, only accessible with "*" via CSS

2. inline-block was broken on IE6 (but fixable with hacks), and no transparent PNG support.

3. The outline CS property was implemented the same as background in IE

Best of all was the dog slow IE 6 JavaScript interpreter, which was like 50x slower than Firefox and IE 7+.

Dog bites man, partisan U.S. media stokes the latest controversy.

I think that you are being overbroad. I don't agree with the conclusions of the article, but the core question is why so many people have bought into election conspiracy theories, or the even more bizarre universe of QAnon. Curious to hear your thoughts.

What motivates all contrarians? Anti-vaxxers, flat earthers, Trumpers, Haskell programmers (kidding).

There was a very insightful article on HN a year or so ago, which explored "The Dangers of Being Right". Many people see personal value and being right interchangeably. At the unhappiest times of my career, where I've felt the most under-valued, I remember becoming fixated on being right, or more importantly, never being wrong.

My take on many of the conspiracy theorists is there is some underlying feeling of insecurity and diminished personal value. Being "right" in a situation where everyone else is wrong, affords them some personal value their lives otherwise lack.

In reference to the article, the hyper-masculinity element is the superficial element. What underlies it is diminished value (i.e. feeling emasculated), perhaps through economic insecurity.

Watch this and tell me if you'd like your company associated with that conduct.

https://www.wsj.com/video/video-moment-pro-trump-rioters-cla...

The people charged with felonious conduct during the summer riots may or may not have been fired. The absence of coverage in whatever preferred news bubble(s) you have doesn't mean it didn't happen.

Appreciate the curiosity. In this small trivial case, yes that works. But what happens when something in the logic changes?

You wind up needing to know the order of calculations since things are no longer lazily evaluated via recursion. This is a problem when you have dozens of "columns" (i.e. recursive functions or arrays as you are suggesting). Often times, the value in the array is NULL (or worse, leftover from a previous calculation). You are left to manually try and re-order the calculations, which is not trivial when there are hundreds of functions.

Excel takes care of these details for you automatically. Users program functionally and recursively (fill-down) without even thinking about it. Excel reactively updates when dependent values change (re-evaluates as necessary).

If power, speed, and scale are necessary, there are purpose-built systems (with Domain Specific Languages) which specifically solve this problem in the insurance domain (e.g. FIS Prophet, Risk Agility, AXIS, etc).

First of all, let me say that I've tried it :)

Your recursion needs to "bottom-out" in order for that to work. If you don't get a stack overflow / out of memory error, you're good. But bear in mind that there will be thousands of stack frames. Before you get to time=0 (the recursive base case) in a long-term liability actuarial calc.

The recursion isn't simple like the Fibonacci sequence . It's more like:

f(t+1) = if t > 0 (f(t) + g(t)) * h(t) else initial_constant

g(t) = f(t) + q(t) - d(t)

q(t) = ....

d(t) = ....

Think about the calculation of an insurance product with a Fund Value. Everything is forward recursive with respect to time. Been a while, so I might butcher some of this. It is likely that you'll want a 30 year projection, so you'll call fundValue(30 * 12)

fundValue(t+1) = if t > 0 fundValue(t) - charges(t) + intCred(t) else initialPrem

charges(t) = netAmtAtRisk(t) * costOfInsurance(t) + riderCosts(t) + policyFee(t)

netAmtAtRisk = (FaceAmt - fundValue(t))

Now think layering on decrements

surrenderMargin(t) = lapseDecrement(t) * (surrenderCharge(t) * fundValue(t))

mortalityMargin(t) = mortalityDecrement(t) * netAmtAtRisk(t)

investmentMargin(t) = (earnedRate(t) - intCred(t)) * assetBase(t)

Now think layering on calcs necessary to calculate the assetBase (e.g. reserves + required capital)...

One reason why Python is so successful is that it places very nicely with C code. Many of Python's libraries are thin wrappers around native DLLs.

For example, numpy is a wrapper around a BLAS DLL (e.g. Intel MKL). Pipenv manages the python side of things, but don't exert control over the system DLLs (like Docker does). Anaconda gets very close to what Docker does (by managing DLLs). Have not used poetry, so can't comment.

Ultimately, like most dependency management issues, lacking a stable DLL environment won't be a problem until it is :)

numpy is great for vectorizable calculations, but many calcs (particularly for long-term life contingent risks, i.e. reserves), are not vectorizable except in the most simplistic cases.

Up-front costs (mostly salaries, but all I.T. projects are "billable") 1.) Getting buy-in from solutions architect, software architecture, information security, I.T. management. This will be a 6 month process. 2.) Getting buy-in from actuarial management and audit. Another 6 month process.

Recurring annual costs (over 10 years) 3.) Contractor at $150 an hour = $300K annually 4.) Contractor PM at $50 an hour = $100K annually 5.) Information security compliance hoops, getting it to play nicely with the myriad of endpoint security tools, etc 6.) Ongoing maintenance and support (failed rollouts and upgrades, user desktop support, user training)

I think you are mocking me, but I'll bite.

Insurance companies are contractor heavy. They bill at $150 an hour. That's $300K annually per head. Won't take long to get a million, when you add PM overhead, information security oversight and governance, etc. Again, it shouldn't cost that much, but it does.

"As to the memoization, that is not hard to manage in Python."

Yes it is. Recursive calls for financial calculations easily go hundreds of thousands of calls deep. This is why high-end actuarial modeling software either decomposes it into a dependency graph and unrolls function calls where possible, or just "brute-forces" it by being a thin wrapper over c++, i.e. using operator overloading on ::operator().

I've seen ill-fated efforts of capable software developers attempting to unroll the recursive function calls, and ending up with 2000 line functions that are impossible to maintain.

The problem isn't feasibility, it's resources. Building and rolling out a standardized environment, and maintaining it, will cost millions of dollars. It shouldn't, but it does. And for what added benefit? The end-users don't want it, you'd have to spend another couple million for a lateral move at best. More than likely, you'll end up with a pile of Python spaghetti code that runs slower than the spreadsheet (see point #4 about massively recursive calcs).

It's been a couple years since I've used it, and I didn't feel it was a comparable alternative. It's decent for about 80% of spreadsheet users, but the keyboard shortcuts were lacking and it was missing some functions that I rely on.

For keyboard shortcuts, most Excel power users don't use the mouse, so while it sound trivial, it's really hard to feel productive when you have to hunt around for the right button to click.

From an enterprise perspective, Excel is so entrenched it would be a 5-10 year effort to port existing spreadsheets to sheets. Practically speaking, most companies wouldn't see the benefit.

I'm a research actuary working in reinsurance. Here is why I think Python creates more problems than it solves from the standpoint of most insurance business users:

1.) Environment management. There are many solutions for managing python dependencies, my favorite is Docker + pip. Good luck getting actuaries and underwriters to write Dockerfiles etc, and good luck getting I.T. to support Docker on Windows desktops. Like it or not, the best "feature" of Excel is that it is mostly the same on every corporate Windows machine.

2.) Unless you are using numpy / numba, Python isn't that much faster than VBA (if at all). Both are "compiled" to interpreter bytecode.

3.) Speed of development and traceability. Excel takes a lot of getting used to, but if you know the purpose of the spreadsheet (e.g. a reserve calculation), it's relatively easy to figure out what a mangled and convoluted formula is doing (Excel has a "debugger" that allows you to evaluate formulas by highlighting pieces).

4.) LAST BUT NOT LEAST. Many financial and actuarial (insurance) calculations are inherently recursive. Excel has built-in memoization (in the dynamic programming sense). It also has a reactive programming model. Good luck implementing that in Python without tripping up on the huge amount of function call overhead, even if you use a memoization decorator.

I think you misinterpreted what was said. A company taking an underwriting loss like that would be shut down by regulators in a heartbeat. There are very large regulatory capital requirements in life insurance, which is why you don't see new entrants into the market.

I'm an actuary and data scientist at a major life insurance company. It depends a lot on the product and business line. For employer-sponsored coverage, zipcode, age, sex, industry, salary, and collar (white/blue) are the major underwriting factors that determine what your employer pays in premium.

For individual life products (term, whole life, etc), it's much less about gaining an advantage from an underwriting perspective. A lot of it is marketing, product design, and investment strategies. State farm's products are pretty expensive compared to the rest of the industry, but their "one-stop-shop" approach and bundling discounts have given them a pretty good marketing niche. Other carriers have their own niches, e.g. using tax-havens to reduce capital requirements. Some invested in very long duration bonds at the right time, and are reaping the benefit of higher yields (on reserves aka float) compared to their peers.

And if the article is still down, the answer to the question of how life insurance companies make money is underwriting profits (charging more than they pay out in claims) and investing in high-quality fixed income investments. Sometimes less scrupulous companies (often owned by private equity firms) create tax arbitrages via offshore havens and tax loopholes.

I'm a former life insurance and annuity pricing actuary (credentialed). When you say actuarial loss, I think you mean the mortality margin (aka underwriting profit) is zero. No insurance company wants a product priced (or experiencing) a negative mortality margin. Zero is OK for some products.

Insurance companies do not crave float (aka reserves and required capital). Capital requirements in the life insurance business are onerous and interest rates are at historic lows. Regulatory requirements encourage diversified, highly-rated, fixed income investments, so the spread on what products are crediting (e.g. whole life, universal life, etc) vs. what bonds are earning is greatly diminished.

Companies and investors would rather have minimal capital requirements with high income cashflow from underwriting profits. This is the reason that the main benchmark of insurance companies is Return on Equity (ROE).

Yes, the vega architecture is supported by rocm (basically AMD's cuda). You're best bet would be to use the pre-built docker images though.

> GE sold off GE Capital over a decade now.

No, they spun off some of their LTC and Life Insurance business into Genworth, which, incidentally is suffering from some pretty severe LTC woes themselves.

LTC is literally the textbook case study in shitty actuarial assumptions. A combination of low interest rates, huge medical expense inflation, adverse experience (i.e. people staying on claim for 2x as long), and low lapse rates have bankrupted at least one insurer in the last two years (Coloniel Penn). Genworth may be next.

GE's auditor KPMG has had some "strikes" against them in recent years that are bad enough to draw attention from the PCAOB.

I guess it's interesting to see an alternative to Black Scholes. Fourier transform (FFT) is a common topic in advanced algos.

I price life insurance for a living. Combat death riders are not common.