<Complex> and Quaternions/Vectors

[BraedonWooding]

I think currently one of the big places Zig could be really useful is in data science, for this to occur Zig needs damn good math functionality including stuff like Quaternions and Vectors along with some good complex number support (quaternions are 4 tuple complex numbers if you don't know, furthermore quaternions do need good euler angle support for game dev).

I currently have a brief hackish solution for vectors, which currently only supports a single 3D vector though of course that means it supports 2D vectors (and has a few optimisations in place for those cases such as for getting the angle or doing a cross product). Currently I implemented a quick invsqrt with a doom like fast inv sqrt which is more for game development where you only care about 1-2 decimal points of precision in some cases.

You can find it here.

Anyways at minimum I'm going to make a library that holds them for my stuff, but I think they would be very valuable for the std lib.

[fithisux]

I also believe that Zig can shine in scientific computing in general. There is a lot of code abandoned or written once and forgotten in universities or by post-grads for research purposes that carries a lot of value but is written in C or C++(in the C with objects style) or desperately slow Java in a very clumsy manner or after a fierce fight with compiler.

Zig can help here to do an incremental port from C-whatever to Zig and apply proper development best practices (without spending time to rewrite the code from scratch or manually transpile). There are other languages out there but Zig can focus on this area, from proteins, genomics to computational fluid dynamics or climate science. Computing is not only or webapps or mobileapps (people got it wrong).

[BraedonWooding]

Completely agree that we need to deeply consider scientific computing! I think however the problem is a two phase issue, the first is to provide some nice utilities that are standardised around handling things like 'bigInts', vectors, matrices and so on. Then have a separate library (probably not official) to handle the more specific needs of scientific computing such as handling equations and the general use 'maple/matlab/whatever' that academics use (well not just academics also data scientists these days).

We have to be careful that we don't develop a bloated std like in C++, and that we take a more conservative approach like in C/go (but don't go too far and be too inconsistent like C, where for some reason quick sort exists but almost anything else you have to build yourself). So I think having a well done mathematical library with things like Sedenions and Octonions should be separate to the std kinda like how numpy and scipy are done with python, however I do think that quite a few features in numpy like multidimensional arrays should be in python, but others are just not needed, especially around the region of graphing.

[fithisux]

@BraedonWooding : You have it right. Keep Zig a core part and make everything a library. Community should be able to build everything with Zig. The only requirements of Zig is ergonomics and enablement, no bloat not swiss army knife in the true spirit of C and Scheme.

[lerno]

Just a note here: if there are built in fundamental types for n-dimensional vectors, complex and quarternion numbers + matrices, then we could have built-in overloading for those types, allowing basic operations to be expressed clearly, e.g. a * b + c instead of add(mult(a, b), c).

[isaachier]

@lerno I agree that might make more sense, but my own preference would be to keep fundamental types to those exposed by the LLVM IR. Otherwise, they are just additional features that need not be in the compiler. Furthermore, you might consider allowing operator overloads (like C++ and Ruby) if you prefer that syntax.

[lerno]

I assumed operator overloading was out for Zig?

I assumed operator overloading was out for Zig?

yes this is why, as I understand, he argues that your proposal is a contradiction to the current design decision

IF your proposal was accepted then zig would also need/ have op overloading in general because your proposal implies that this is a useful feature/ good tradeoff

[lerno]

From what I understand C is doing some form of overloading too in its support of complex numbers. The use case is not general operator overloading but specific overloading for certain basic math operations. General operator overloading is a bad idea.

Thats just super weird IMO, I did not know this but you're definitely right that its a "feature".
But c also has "generics" ...

IMO if zig would acknowledge that op overloading is a useful feature, it should go all the way and make it accessible to all users (what about my own finite field arithmetic?) not only compiler supported types. Thus I don't think this fits onto zig anymore.

Maybe one possible option might be to allow op overloading for * / + - ^ or some subset of operations.

[isaachier]

I think the issue with operator overloading is that it is too prone to abuse. So as I said originally, it is probably best to avoid relying on operators unless the type is fundamental. When it comes to fundamentals, the LLVM IR is probably the best way to decide.

[binary132]

It seems like a lot of people want various built-in features that, while interesting, don't seem to fit with the spirit of Zig as a lean, mean C competitor. I sometimes wonder if the right way to let them all get what they want is to support language extension via third-party package, a bit like GHC's LANGUAGE pragma, but with an API that can support third-party extension and resolution of third-party LANGUAGE packages.

I certainly don't care for built-in operator-overloaded linear algebraic features, and I would prefer not to waste the time of core developers with many nice-to-have features. But it would be awesome if there way a way for interested parties to develop syntax packages. @andrewrk any feedback?

[kyle-github]

One problem with operator overloading, even for things like matrices, is that you so easily hide what is going on. C++ takes this to an extreme where just seeing "a + b" gives you no real idea of what is going on. Matrix addition? String concatenation? Set union?

Since Zig already started down the path of having + and +% and so on, perhaps there is a way to provide for some amount of operator overloading to make these things a little nicer on the eyes but still keep basic operations clear. Perhaps names like "_+_" could be overloaded or something (do not take that particular syntax as a real proposal). Then matrices could be added with "a _+_ b".

Not a serious proposal, but perhaps there is some happy medium that allows external packages to provide almost the same syntax as built in things but still allow a very clear indication of when some operation needed more investigation before you automatically assume what it does. If I see "add()", I know it is a function and I need to go look up what it does. If I see "+", I have to know the types of both arguments in C++ and even then this gets hard with all the automatic coercion that goes on. If I saw "_+_" I could treat it like "add()" and make the effort to find out what it really calls.