t-vi

No, Arcturus is CDNA (the Compute rather than Render architecture). Still with the Radeon VII EOL it would be good if they had a consumerish ROCm card, so RDNA2-support would be great.

Indeed.

The main questionable implicit assumption that is made is that Python can't "the future" (which is severely underspecified without a time horizon) because of what is bad about it today. It even is literally there "Python isn't the future... It can't be" <because something in Python is bad>.

That's highly questionable, because it leaves out - that people appear to have reasons to adopt Python, likely because of something that is good about it, (this complements the observation that not that many people might be impacted by the disadvantages). - that Python and the ML tools in Python might not be static and actually evolve in "the future".

It seems to me a curious lack of reflection substituted for by being particularly assertive about it.

To my mind Python not being the future is more likely to happen if Python becomes less likable or the attempts to improve the shortcomings (which are there, HPy as a medium-term way to get out of the "C extension vs. parallelism/speedup/GIL" corner, mypyc/numba/TorchScript/JAX pushing the "what can be efficiently expressed in Python" boundary) fail.

Julia, Swift, Dex-Lang, HaskTorch all get things right that Python doesn't. But do they get all the things right that Python does get right?

Disclaimer: I'm biased because I like Python and have some involvement in Python ML tools.

In the special purpose for computation (like Numba) department, but more general: TorchScript from PyTorch https://pytorch.org/docs/stable/jit_language_reference.html#...

It doesn't compile to C but to an IR, but some ideas around typing might be similar.

A more charitable view on the PyTorch forums thread is that Ed's explanation "torch.jit, at this point in time, is not designed to take pointwise loops as you’ve written here, and compile them into machine code directly." is a description of "this is the feature you're implicitly asking about, and it isn't implemented in PyTorch yet". What would have been a better answer in your view?

It would seem btw that 1.5 years later, people are working on implementing generated kernels for reductions, even if it is still somewhat experimental.

The speed comparison, which is about 9 months old, is marginally related. The issue here is optimization of pointwise operations, which would be handled by the JIT fuser, except it is disabled by default on the CPU. The latest version of the benchmark code seems to not run on recent PyTorch versions as given. It still still a fair comparison in terms of it is what a user will get by default. I won't be the first PyTorch developer to say that Julia and its libs do a great job at JITed optimizations. Nonetheless I'm relatively certain that a determined PyTorch user would find ways to get that a better optimization of that ODE step using some of the disabled by default features.

The other truth, of course, is that for PyTorch, there still is more emphasis on GPU when it comes to implementing optimizations.

(Disclaimer: I'm one of the people on that thread.)

Sounds like my advanced PyTorch course (except that I didn't put as much emphasis on distributed). :) I haven't become enchanted with moving to online yet. You ask about interactivity, and that seems to be the difficult part to me. For the exercises, I haven't found anything just like sitting in front of the same screen with my students.

I'm not a HR person but would get applications as local team lead for an actuarial consultancy. I would expect "insurance" and "consultancy" to be related to in the cover letter and invite precisely the people who either do both or have something really interesting somewhere else. A well-written cover letter would also start the conversation in the interview.

But I'm based in Germany, not the US.

I can only speak for myself, but my understanding is that the Navi cards are not intended nor advertised for compute. Now, one might wish to get a consumer card with Arcturus after the Instinct MI100 is released or dislike that the Radeon VII is discontinued, or even that it wasn't split into render and compute lines, but basically, to me the complaint about Navi not being supported by ROCm sounds a bit like buying a boat and complaining that it can't fly. Driver support was bumpy for me with Linux 5.0 or so, but I haven't had trouble with just running whatever kernel Debian ships for quite a while now. But I must admit I don't use the GPU for anything but compute, so I don't know about graphics.

But your mileage may vary, I don't want to make people swear.

PyTorch supports ROCm quite well if you can follow three step build instructions instructions (https://lernapparat.de/pytorch-rocm/). TVM.ai also supports ROCm well. TF I didn't check.

FP32 performance for the VII is comparable to GTX20280Ti e.g. on Resnet training. Tensor Cores are cool, but 90% of people don't use FP16 that much.

I'm not sure that is the best reply that stackoverflow has ever seen.

That is because AMD split graphics vs. compute and you look at a non-compute card. The Vega-based chips work quite well and the Radon VII is (or was, I'm afraid) an excellent value proposition.

Well, if you want to define accounting in an alternate universe, you can define it that way. However, if you want to describe accounting as it is done, it is utterly wrong. Doing this will bite you once you read other sources on accounting, talk to accountants, the tax office, etc.

From my experience, if you're doing accounting beyond a hobby, you likely want to follow whatever GAAP (generally accepted accounting practices), and likely need to consult references for how specific cases are represented. If you then don't use the same language and conventions as everyone else, it's just even more of a pain than it is.

My experience here is that I was with a large audit company, albeit as an actuary rather than an accountant. I did have the opportunity to dig quite deep accounting records of insurance companies there. Now I own an incorporated company and do my own accounting and taxes (with GnuCash for accounting, even if I hand-rolled reporting for XBRL export and all).

So we've had type hints for a lot of PyTorch in Feb 2019 after working on it since Oct 2018.

I must say that of the 140 or so features and bug-fixes this was the singular most draining thing to work on, mainly from the comments on the bug reports.

But I'm glad if it sparks more joy now.

The shape vs. type is something that many people want, part of the problem is that shapes do depend on inputs. Often on input values (often constant ones) rather than types (convolution padding, "kernel" size in pooling, ...). But you would also need to know the constants from class members. For other bits it's completely unpredictable (like value-based advanced indexing or nonzero or so). So one would really need to be more "dynamic" than the static type annotations (meta-programming).

There is a bug open around that, but I haven't really followed along.

The other part is that I personally think that stubs (pyi) rather than inline type annotations are 1) wrong, because they'll go out of date, 2) ruin the joy. But the Python 2 compat everyone wanted last year kept us using them.

You can compile PyTorch this pretty easily, I wrote a recipe here:

https://lernapparat.de/pytorch-rocm/

No docker involved, just Debian + the ROCm packages from their repository.

I'm doing this relatively regularly, and it has worked well for me for the past half year or so.

I guess I could upload wheels somewhere, but I'm never sure how tight the dependency on ROCm has to be.

Over the last release cycle, PyTorch/ROCm gained support for TorchVision including GPU ops among other things (based on support for extension compiled via setup.py). Master has support for loading extensions that are compiled just in time.

If you find things not working as well as they should, don't hesitate to tag me on a bug report or send a mail.

(The PyTorch/ROCm is mostly for my own entertainment, so I don't speak for anyone.)

Any profit made not by genuinely improving efficiency/productivity is made through causing someone else a loss of the same amount.

Now, very few parts of the finance industry genuinely improve efficiency - classic market making (classic stock market, taking savings and giving out loans to real people) does, but that is just a tiny drop of water in the ocean of dodgy modern finance.

The same applies to tech, too, see Uber and AirBnB.

While I'm not sure there actually are a lot of high school prerequisites for higher maths, I think the experience of attempts 1-3 reflect pretty much what might be the key to studying maths successfully.

So in my first year of studying maths, I had 8 hours of maths lectures (and 4 hours of a minor which was of negligible effort). The exercises that came with the maths lectures made this a full-time program (and I estimate that while I didn't usually study all weekend, I typically only had 1-2 weekends per year in which I didn't look at anything at all). So one thing that can easily go wrong is underestimating that for every minute spent reading / listening to a class, one would want to spend 4 minutes working the problems.

The other comment I would have is that, yes, university level mathematics is (at least it was for me) incredibly hard. The reward is also astonishing: All these hard exercises I struggled with one year, are easy to do on a napkin during breakfast in the next year.

The idea is that you should know basic maths (say what matrix multiplication does and what a vector space is) and a bit of Python. We work very hard on keeping everything hands-on from there. (Disclaimer: I'm not unbiased.)