Complex Numbers

Evolution Pitches
102

This library needs to be refactored to be cross platform (it imports Darwin now for some reason), but all the hooks are available already.

That said, this library needs some serious work to make it conform to the API naming conventions. That is probably a useful project in any case.

103

Ahhh. I see now. Hm.

We should push this project as a proposal to Swift-Evolution then.

Also: are those hooks available for a library compiled outside the Apple/Swift repo? That'd be important if anyone's gonna try and build something reliant on SIMD functionality without that library.

104

wait so all you have to do is add a definition to the standard library that wraps Builtin.Vec4xFPIEEE64 and friends and write the operators, and that will just,, work? That doesn’t seem too hard of a Swift Evolution implementation


(Narrator: It was too hard of a Swift Evolution implementation!)

2 Likes
105

The -parse-stdlib flag grants access to the Builtin module and disables implicit importing of the Swift module (you can still explicitly import it). This shouldn't be used by user code because the Builtin module has no stability guarantee at all. Instead, we should define a proper cross-platform SIMD module in the Swift project, built in terms of those internal builtins. Higher level code would layer on top of it.

-Chris

6 Likes
106

We could start with something like BLAS's Level 1. Afaik, those are the operations that directly translate to SIMD. The other ones seem to be built on top of it for the most part. Functionality like Levels 2 and 3 could be let to the higher level code to implement.

107

So what’s stopping us from making a PR in the standard library to expose the basic operations? it seems like we have literally all the tools we need right now

108

I would really love to see a methodical approach to this. Here are some pointers:

I'd strongly recommend exploring the SIMD module that @scanon spent a bunch of time on (years ago) and the language features we built for OpenCL that are part of Clang here: Clang Language Extensions — Clang 16.0.0git documentation

LLVM has a bunch of underlying features (LLVM Language Reference Manual — LLVM 16.0.0git documentation) that are exposed more-or-less directly through the Builtin module. It is important to understand them as well if you plan to do work in this area.

-Chris

1 Like
109

sweet. but are we really going to bring swizzling into Swift? don’t get me wrong, i love this feature in GLSL but I’m not sure it’s very Swifty

we also need to seriously start thinking about vector literals. maybe it’s time to add Tuple Literals to Swift?

110

I'm not sure what your objection is to swizzling, can you elaborate? The OpenCL syntax isn't at all important of course, but the semantics have payed for itself many times over.

111

just that the number of accessors that would have to be defined on each type would be ridiculous (256?)

112

It depends on the size of the vector, but there's an example implementation up at Math/Swizzle.swift at master · SwiftGL/Math · GitHub. All of those members would have to be marked @inlinable, too.

113

I actually have a more general “simd 2” module that doesn’t depend on any Darwin SDK support which I intend to propose in some hand-wavy “soon” timeframe (wildly out of scope for 4.2, so I’ve been deliberately sitting on it). It’s still WIP, and there are some questions to resolve about whether it goes in the stdlib proper, or is (one of) the first non-default standard libs or what and exactly what the bindings look like, etc, but it exposes the bulk of the builtin llvm ext_vector support for a wide range of types and vector lengths.

It does not support arbitrary lengths via weird template params or anything exotic like that. That’s out of scope for my purposes.

11 Likes
114

Very cool, are you able to post it somewhere (e.g. as a gist or a "do not merge" PR on swift.org)?

115

Still a little bit of a work-in-progress, but soon!

3 Likes
116

any update on this? i just remembered this lol

117

Yes! Well, sort of. I haven't had much time to spend on this, but I have played around with some solutions. Honestly, I'm kind of stuck on how to proceed at this point.

You can check out the readme on my MathTypes project on Github for a summary of what I think are some of the major design criteria that came out of this discussion. The MathProtocols.swift is a sketch of how the algebra described in the readme might be encoded as protocols. However, I think there might be a better way... I'm not sure what :slight_smile:

The playground in there shows some basic functionality that comes from an early draft---it pulls from MathTypes.swift, which is a brute force, but effective (partial) implementation.

3 Likes
118

what about the llvm-level vector types?

119

Yeah, now that 4.2 stuff is winding down and 5.0 stuff is winding up, I'll pick it back up and circulate a draft ~soonish.

5 Likes
120

Would something like this see for the introduction of some type of a Fraction type to help represent values with utmost precision?

121

Fractions are worse than both floating-point and fixed-point numbers is almost every way. Most importantly:

  • If you don't round results, in computations that aren't designed to work out just so, the size of the numerator and denominator is exponential in the number of terms in the computation.
  • If you do round results, the result will generally be significantly less accurate than what you would get with an equivalently-sized fixed- or floating-point representation, because rationals are not uniformly spaced and have redundant representations.

The are legitimately useful for some computational geometry operations where the number of terms involved is tightly bounded, but those computations can also just be rephrased in terms of integers, so you don't really need a rational type to implement them.

They're also real good at representing 1/3 exactly, which seems appealing, but has more psychological benefit than anything else.

7 Likes