praeclarum

Yes that syntax works right now.

Yeah I think I’ll reduce the accuracy requirement for some transcendental functions since GPUs seem all over the place.

Please do. I have a few test machines but cannot match the variety of hardware out there.

Sorry Safari does not support WebGPU yet. Please join me in writing to Apple and requesting it.

Yeah this is the trick. You need to maximize the use of workgroup parallelism and also lay things out in memory for those kernels to access efficiently. It’s a bit of a balancing act and I’ll be working on benchmarks to test out different strategies.

Yeah so the thing is WebGPU doesn’t correctly support IEEE floating point. Particularly, 0 is often substituted for +-Inf and NaN. See section 14.6 of the spec.

https://www.w3.org/TR/WGSL/#floating-point-evaluation

It’s not such a problem for real nets since you avoid those values like the plague. But the tests catch them and I need to make the tests are tolerant. Thanks for the results!

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.

I’m of the same opinion. While I think I will keep the standard parameter order from torch, I will include the options overload to give all the benefits you describe.

I've been working on a WebGPU optimized inference and autograd library with an API that matches PyTorch. The goal is to reach CUDA speeds in the browser. Many kernels have been implemented and it's been designed to be easily extensible. Available on NPM now! I'm working on supporting Stable Diffusion and hugging face transformers.

It’s open source and I have successfully compiled and ran it on my own machine. So I do not fear it going away. The biggest risk is it could not be updated at some point. But, again, OSS. The community could continue the work.

I owe the iCircuit community vacuum tubes. I've been promising them for some 10 years now.

My hesitance has mostly been my inability to verify the simulations. I prefer to have physical elements available so I can double-check the app. But I think I will have to resign myself to verifying against SPICE or something.

Nailed it. I started iOS development using Obj-C++ but switched to C# after a couple years because of my familiarity and comfort in that ecosystem. At this point I've used it for 10 years on several iOS and Mac apps and know its ins and outs. I've been accused of making my own job harder but honestly it feels the opposite for me. The .NET debugger, reflection, choice of languages, package ecosystem, it's all very lovely.

There is tons of TPL (Task Parallel Library, async and await), I was just trying to keep the blog simple. Once you have thread-safe primitives, you can build higher level abstractions on top of those. In fact I worked a bit on the TPL when I worked at Microsoft so I definitely abuse it. :-)

What you call gaming, I call working around the government’s idiotic visa requirements.

This is a priority for the next update - git just ended up being a lot of work and got cut for the initial release.

Yes three is absolutely a toggle switch. C# and F# are mostly tolerant of this style of programming. But if you like writing "while" and "for" loops then the eager execution can really hurt. Also, if you do a lot of CPU or net intensive stuff then it's also a good time to turn "auto run" off.

At least on an iPad Pro, I have found the split view with Safari docked to the right to be very adequate (actually, good) as the app contains lots of links to online docs.

I worked hard to make sure F# got equal support to C# - semantic highlighting, code completion, all that. The only real difference is the F# builds are a bit slower than C#.

If you develop a cool app and want to distribute it on the App Store, then you will indeed have to transfer it to a Mac and recompile it there using Xamarin's free product. This is a mix of limitations of Continuous (doesn't have an ARM compiler included) plus a limitation of Apple (you need a Mac per their rules).

The truth is they are essentially the same. I just draw the distinction because porting apps between them isn't always automatic.

Windows RT (aka Metro, aka Store Apps). It's a model based on WPF but not fully compliant - it took in lessons learned form Silverlight. Call it WPFlight.

Sorry - I have a very client-side/consumer facing attitude and these low level debuggers just don't matter. But I acknowledge that it's certainly useful in the scenario you outlined.

Thank you for the clarification!

What got me interested in the CLR in the first place was how easy it is to write a compiler for it. When insomnia hits, I'll still load F# and write a little parser and code emitter for some silly language I have been thinking of. It's fun.

In fact it runs quite well on .NET. My favorite demo is seeing how much faster Eclipse loads on the .NET runtime than the Java.

Mono has a lot of GPL code. Xamarin has a license to impart commercial licenses to their customers. So Xamarin customers are fine. Mono users will have to abide by the GPL'd bits.

Microsoft's CoreCLR is MIT licensed. Nice. :-)

In terms of maturity and feature-completeness, GTK# is the answer. Unfortunately, it's no beauty either.

Especially on Mac it does its own control rendering and, while it tries to match the OS, has problems.

XWT was meant to replace GTK# and has some good underpinnings but it doesn't seem super active right now.

AFAIK WPF is managed by the Windows team. All this open sourcing has been happening form the Azure and developer teams. Chances of Windows open sourcing some of their code? Less likely.

As someone who worked on WPF though, I will comment that the code may not actually be too useful. It is heavily tied to Windows and its graphics infrastructure.

I'm more interested in seeing something like Moonlight ported to modern platforms.

Calca takes ideas from Soulver and super sizes them:

* Soulver allows free text editing within a line of computation; Calca allows free editing in the entire file

* Both update as you type

* Soulver understands arithmetic; Calca knows algebra, calculus, and algorithms

* Soulver requires that all variables be defined; Calca does not

* Soulver does not support user defined functions; to Calca, everything is a function

* Soulver has no programming constructs; Calca is one step away from being a general purpose programming language.

* Soulver does not support matrices; Calca does

It's from scratch C# code using Xamarin to build the UI layers for iOS/OS X. Well, I also use a parser generator jayc which is based on jay which is a yacc cc. Everything else is mine. It's a pretty standard Expression tree implementation with a symbolic interpreter.

Developer here, yep that was a bad omission. The worst part is I do that kind of math all the time! You can count on it showing up in updates either as a function or as syntax.