fddr

The `torch.compile` API itself will not be available from C++. That means that you won't get the pytorch 2.0 performance gains if you use it via C++ API.

There's no plan to deprecate the existing C++ API, it should keep working as it is. However, a common theme of all the changes is implementing more of pytorch in python (explicitly the goal of primtorch), so if this plan works it could happen in the long run.

Do you actually think it would be a good thing if an IRB was required for this type of thing? Sure, it's "human experimentation" but the likelihood for any serious harm is basically zero.

It goes with the zeitgeist to argue for what makes the life of big tech companies hard, but they are big enough that they can afford things like that. It's smaller companies and academics that would end up not being able to innovate as much

Go down that road and you end up with an IRB evaluation requires for an A/B test that changes the color of a button

That it is a little different. There you are estimating a continuous parameter (which happens to be interpretable as a probability) and it makes sense to have a probability distribution over that.

But if you are talking about whether a single discrete events will happen or not, a single number (the probability) already fully captures the uncertainty about it.

They are giving probabilities for discrete events, which already captures their level of uncertainty. Probabilities of probabilities (i.e., a probability distribution of a probability) are not very useful concepts.

Yes, but most likely the fact that the natural gas is being used instead of oil or coal leads to a large net reduction in carbon emissions

Yes, 100% agree with last paragraph. And the waiting for me to type Hello back pattern is so annoying.

This really should be basic work etiquette. Type your whole question in one go. If you want to you can include pleasantries at the beginning but never if there is going to be a more than 2 second interval between them and your actual question.

Should probably be part of first day orientation for new hires.

You are not wrong, except it's not usually a big loan. The witholding rates are chosen so that in most cases what is withheld is close to your final tax bill.

In all countries I know of, tax withholding is not a perfect match to final tax bill, and that could amount to a no-interest loan to government like you say. Not sure if in practice that loan is unusually large in Portugal, could be.

You do get a paper receipt, which is just your normal sales receipt (which usually I just throw away immediately).

You can also check all your receipts online, on the Finance Ministry website.

It is true. The prize used to be a car, now it is government bonds.

It is fully automatic. You just tell the cashier your tax id number, and you are set. No need to keep the receipt.

It is not quite that bad. Tax withholding rates are not marginal, they do apply to the whole salary. But the actual tax rates at the end of the year are marginal. So it is possible a pay raise means you get less money after witholding on a monthly basis, but on an yearly basis, after taxes paid/refunded, a pay raise is always net positive.

Still silly, but not insane.

It may have been a "crusade", but it does not seem to me it was personal.

I am genuinely surprise at how confidently you (quite wrongly) diagnosed my problem.

What I did mean, was that for my use cases, I found Mathematica was superior to the alternatives. You are welcome to think this was because I was lazy or misguided, but it was definitely not because I liked not having to specify domains for my variables (and I do remember having to write Assuming[p>0 && x \in Reals, ...] and the like often, it definitely does not assume everything is a positive real).

One thing I used Mathematica a lot for was numerical integration of ODEs (that had been derived using the CAS part of Mathematica and had some pretty nasty coefficients). NDSolve in my experience was just better than competition. You can definitely get nonsense out of it, but with a modicum of care it works incredibly well.

As a former physicist that used Mathematica heavily not that long ago, I have to disagree. It would be great if there were open source alternatives that were "superior in every way" but that is just not the case.

For some use cases at least, Mathematica is clearly better than anything else I have tried.

I feel like something like ipython notebooks with the right combination of libraries might eventually get there, but that is unfortunately still years away.

This is not entirely correct. The reduction in tax liabilities will be much smaller than you might expect and this is not a merger motivated purely by that. For an in depth discussion see [1].

[1] http://www.bloombergview.com/articles/2014-08-25/burger-king....

> It’s not really a feature, it’s an operator that can be overloaded. That is, instead of using `mymodule.dot(a, b)`, you can use the much less readable `a @ b`.

I disagree with you, and think it's definitely a feature. If you are doing scientific computing it can be much more readable to use infix overloaded operators. What is better, `np.dot(x.T(), np.dot(M, x))` or `x.T() @ M @ x`? I find the second much more readable.

I get it that operator overloading can be abused and lead to unreadable code, but in some use cases it is a godsend.