zlacker

[parent] [thread] 6 comments
1. modele+(OP)[view] [source] 2023-05-20 01:18:16
Without multidimensional array slicing or operator overloading it seems like Typescript could never be anywhere near as ergonomic as Python for ML, despite its other advantages.
replies(2): >>praecl+x1 >>phailh+K3
2. praecl+x1[view] [source] 2023-05-20 01:39:23
>>modele+(OP)
Those are niceties and can be implemented with some small hacks. Most big nets do very little slicing. Lots of dimension permutations (transpose, reshape, and friends) but less slicing. I personally use a lot of slicing so will do my best to support a clean syntax.
replies(2): >>tysam_+Ml >>whimsi+fp1
3. phailh+K3[view] [source] 2023-05-20 02:09:24
>>modele+(OP)
What's the advantage of those "ergonomics" if you have to memorize all the quirks? With a language like Typescript, all those operations become explicit instead of implicit, letting you take full advantage of your IDE with autocomplete, documentation, and compile-time warnings. Python sacrifices all of those just to save a few keystrokes.
replies(1): >>int_19+KTa
◧◩
4. tysam_+Ml[view] [source] [discussion] 2023-05-20 06:48:48
>>praecl+x1
I've come to believe over the last few years that slicing is one of the most critical parts of a good ML array framework for a number of things and I've used it heavily. PyTorch, if I understand correctly, still doesn't have it right in terms of some forms of slice assignment and the handling of slice objects (please correct me if I'm wrong) though it is leagues better than tensorflow was.

I've written a lot of dataloader and such code over the last number of years, and the slicing was probably the most important (and most hair-pulling) parts for me. I've really debated writing my own wrapper at some point (if it is indeed worth the effort) just to keep my sanity, even if it is as the expense of some speed.

◧◩
5. whimsi+fp1[view] [source] [discussion] 2023-05-20 17:44:41
>>praecl+x1
I disagree with this, slice notation is powerful and I use it quite a bit in DL.

Even just the [:, None] trick replacing unsqueeze is super useful for me.

◧◩
6. int_19+KTa[view] [source] [discussion] 2023-05-23 20:30:17
>>phailh+K3
What is implicit about either feature, and what difference do they make from the IDE perspective assuming equivalent type annotations in both languages?
replies(1): >>phailh+6xb
◧◩◪
7. phailh+6xb[view] [source] [discussion] 2023-05-24 01:22:01
>>int_19+KTa
"Assuming equivalent type annotations" is the problem. Can't do it with Python, full stop. If we could, we wouldn't be having this conversation at all! It can't catch any mistakes because its type system is simply not expressive enough. You have to hold the type information in your head and make sure you slice and multiply correctly.
[go to top]