m16ghost

> (all in d/m/y format, mind you)

The examples you gave are in m/d/y format though, and DATEVALUE() parses your examples correctly into Jan 15th, 2024 and January 3rd, 2024.

DATEVALUE() parses ambiguous short date formats (e.g. 1/3/24) using the short date format specified in the Region settings of Windows Control Panel. So if you want to parse d/m/y format, you can try changing the settings there.

Thanks. What I am getting from this is that pi is believed to have this property, but proving this is still an unresolved problem.

> Therefore, inside pi is contained every discovery and every work of art!

Is this actually true? It is not clear to me that pi necessarily contains every possible sub-sequence.

I think we can agree that something will need to change as medical trend cannot outpace inflation forever. I don't think the issue is with executive compensation, because even if insurance companies magically could perform all their services for free, you would only reduce premiums by less than 20%.

>Having no idea what the real trend is, couldn't any other factors counteract the perverse effect, making both parent's and your observations true at the same time ?

Absolutely. There could be other factors that are counteracting the effect, including those within the ACA itself since the bill contains many changes to healthcare, not just the restriction on medical loss ratios.

You are correct, those are some of the advantages of claims-made vs. occurrence policies. Claims-made policies started because the industry went through a crisis in the 60's and 70's.

>Buying a policy to file a claim for an event that already happened is called fraud, and while it does happen, it's generally pretty easy for insurers to detect and prevent.

Detection has underwriting costs associated with it. Investigating whether you knowingly purchased an insurance policy with an incoming claim is not something that is automated. By default a claims made policy will prevent the issue in the first place by resetting what is known as the retroactive date. This causes the lapse in coverage the OP was referring to.

There are specialty insurers who will allow you to explain extenuating circumstances, and/or set retroactive dates prior to the effective date of the first claims-made policy. You obviously pay for the additional risk this poses to the insurer though.

> I recently just renewed my errors and omissions policy and was a little shocked to find out if you let the policy expire then the policy does not protect you even in past while the policy was active.

This is to protect the insurer against adverse selection. Errors and omissions policies are typically on a "claims-made" basis, which means they cover claims that were filed against you during the policy period, as opposed to incidents occurring during the policy period.

It is assumed that if you let your policy lapse and then buy a new policy, that you know that there is some incoming claim against you for which you need protection from.

Which version of Python/JS do they implement?

I think part of the problem is that any scripting language rolled directly into Excel will be expected to keep backwards compatibility. Microsoft doesn't have full control over Python/JS, and they would like to avoid issues such as the changeover from Python 2 to 3.

Microsoft could implement its own fork of those languages, but is that what customers actually want?

It is not much better than the canonical example given in the article. It still has the following usability issues:

-You still need to enumerate and label each new column and their types. This particular problem is fixed by crosstabN().

-You need to know upfront how many columns are created before performing the pivot. In the context of data analysis, this is often dynamic or unknown.

-The input to the function is not a dataframe, but a text string that generates the pre-pivot results. This means your analysis up to this point needs to be converted into a string. Not only does this disrupt the flow of an analysis, you also have to worry about escape characters in your string.

-It is not standard across SQL dialects. This function is specific to Postgres, and other dialects have their own version of this function with their own limitations.

The article contains several examples like this where SQL is much more verbose and brittle than the equivalent pandas code.

>Pandas is a very popular tool for data analysis. It comes built-in with many useful features, it's battle tested and widely accepted. However, pandas is not always the best tool for the job.

SQL is very useful, but there are some data manipulations which are much easier to perform in pandas/dplyr/data.table than in SQL. For example, the article discusses how to perform a pivot table, which takes data in a "long" format, and makes it "wider".

In the article, the pandas version is:

>pd.pivot_table(df, values='name', index='role', columns='department', aggfunc='count')

Compared to the SQL version:

>SELECT role, SUM(CASE department WHEN 'R&D' THEN 1 ELSE 0 END) as "R&D", SUM(CASE department WHEN 'Sales' THEN 1 ELSE 0 END) as "Sales" FROM emp GROUP BY role;

Not only does the SQL code require you to know up front how many distinct columns you are creating, it requires you to write a line out for each new column. This is okay in simple cases, but is untenable when you are pivoting on a column with hundreds or more distinct values, such as dates or zip codes.

There are some SQL dialects which provide pivot functions like in pandas, but they are not universal.

There are other examples in the article where the SQL code is much longer and less flexible, such as binning, where the bins are hardcoded into the query.