Some of the tests in KVOKeyPaths.swift check problems that were not fixed
until Swift 5.1 so they are not expected to pass when running with the
5.0 libraries.
rdar://problem/50173830
The testEncodingMultipleNestedContainersWithTheSameTopLevelKey check is new
in Swift 5.1 and will not pass when running with a 5.0 stdlib.
rdar://problem/50151131
This test checks that error bridging with ObjC bridging works when the stdlib is statically linked. We no longer support static linking of the stdlib on platforms with ObjC interop.
rdar://problem/49699316
Some tests are limited to only Linux, when they should also pass for
Android.
Additionally, InputStream.swift.gyb was disabled for Android ARMv7, but
wasn't for Android AArch64, which allow me to find the error on it and
fix it on #24521.
Finally, StringLowercasedUppercased is interesting in Android because it
checks the used ICU is correct for performing the tasks that the stdlib
needs.
These are testing for bitwise identical results, but don't guarantee that
the buffers being used always have identical alignment. This will result
in small rounding differences when vector codepaths are used for different
elements of some results.
This is partially an underlying bug in Accelerate (which is outside the
scope of this project to fix), and partly a test bug (which we can address
by adopting approximate comparisons here). In the short term, though, I'm
going to disable these.
`DoublePrecisionInterpolateBetweenNeighbours ` was occasionally faliing on tvOS simulator. Not using exact equality appears to have fixed this issue. The code I've used for `isAlmostEqual` is based on SE-0259
A buffer's `data` may contain padding when the `rowBytes` isn't equal to the number of chanels * width * size of the element. I've updated arrayFromBuffer to return an array that excludes any `rowByte` padding.
This does several different things to improve how platforms are described in availability diagnostics:
• Mentions the platform in diagnostics for platform-specific @available(unavailable) attributes.
• Replaces “OS X” with “macOS”.
• Replaces “fooOS application extension” with “application extensions for fooOS”.
• Replaces “on fooOS” with “in fooOS”.
Fixes <rdar://problem/49963341>.
A buffer's `rowBytes` doesn't have a direct relationship with its `height`, so `rowBytes / Int(width)` isn't a good way to calculate pixel size. To resolve this, I've added `pixelSize` as a parameter to `vImage_Buffer.copy`.
* Add availability information to the new Math function protocols
The protocols ElementaryFunctions, RealFunctions, and Real are new in Swift 5.1 and accordingly need to have availability attached to them for platforms that are ABI-stable. The actual implementation hooks (static functions) are unconditionally defined on scalar types and marked @_alwaysEmitIntoClient, so they are available even when targeting older library versions, but the protocols themselves, and anything defined in terms of them (the global functions and the SIMD extensions) is only available when targeting library versions that have the new protocols.
* Additionally provide concrete implementations of signGamma for each stdlib-builtin floating-point type.
* Remove Real[Functions] protocols pending re-review
Temporarily pull these back so we can make minor tweaks to the design and get a re-review on SE.
* Accelerate vImage Swift Overlays
A suite of functions, enumerations, and option sets to make working with vImage in Swift simpler.
* vImage_Buffer - new initializers to instantiate and initialize buffers with a single function call.
* vImage_Buffer - new functions to copy buffers and create CGImage instances from contents.
* vImage_CGImageFormat - new initializers.
* vImage_CGImageFormat - new equivalence operator.
* vImageConverter - methods to wrap free functions.
* vImageConverter - new make and convert functions.
* vImageCVImageFormat - new make functions.
* vImageCVImageFormat - methods to wrap free functions.
* vImage_Error - errorDescription function.
* vImage flags as an option set.
* Add new methods for generating CV -> CG and CG -> CV converters.
* update comments: `height` and `width` to `size`.
* `vImage_CGImageFormat.componentCount` should be `Int`.
* `vImage_CGImageFormat.componentCount` should be `Int`
* Move `self.init()` to after the size check for kvImageNoAllocate init.
* Buffer initializers to width and height rather than size.
* change vImage_CGImageFormat lightweight initializer to accept Int for `bitsPerComponent` and `bitsPerPixel`.
* Flesh out docs for vImage_Buffer.size
* Remove faux initializer in favor of new static function: `preferredAlignmentAndRowBytes`.
* Change functions to use proper error handling rather than inout error codes.
* Removed `flags` from basic init.
The only real flag to pass here is print diagnostics to console, and I now throw proper errors.
* Tests to check error throwing for buffer copy.
* remove unnecessary import, add missing docs.
* Add comments to error enums.
* Fix bug creating string from format code.
* Make `vImageCVImageFormat.formatCode` a `UInt32`.
* Remove equivalence operator from `CGImageFormat`.
* Swift overlay to vDSP cascaded biquad IIR filter.
* update comment in test
* Swift overlay to vDSP Discrete Cosine Transform
* Swift Overlays to vDSP Fast Fourier Transform and Discrete Fourier Transform
* Tests for DFT and FFT
* Some refactoring and begin documentation.
* Swift overlays to FFT and DFT operations.
* Expand docs.
* Implement `vDSP_destroy_fftsetup` and `vDSP_destroy_fftsetupD`
* Refactor Tests
* Refactor Tests
* Provide transform function that returns the result. Refactoring: parameter names more consistent with other vDSP operations, push `fileprivate` symbols to bottom of file.
* Add apply() function that returns the result.
* Added a version of DFT transform that returns the result.
* update some DFT comments
* Remove FFT overlays from this branch to separate DFT and FFT pull requests.
* [Accelerate] [vDSP] Swift Overlays to FFT Operations
This PR contains Swift overlays to simplify performing 1D and 2D fast Fourier transforms on single- and double-precision data.
This PR includes a subset of the operations (e.g. vDSP_fft_zrop for FFT). My plan is to add the additional operations (e.g. multiple signals, in-place operations, etc.) in a subsequent PR once this is approved.
cc: @moiseev @airspeedswift @stephentyrone
* Composite Branch
Contains FFT, DFT, DCT, and Biquad branches.
Contains the following:
[Accelerate] [vDSP] Swift Overlays to Sliding Window Summation Operations
[Accelerate] [vDSP] Swift Overlays to Linear Interpolation Operations
[Accelerate] [vDSP] Swift Overlays to Complex Vector Operations
[Accelerate] [vDSP] Swift overlays to 1D and 2D convolution operations.
[Accelerate] [vDSP] Swift overlays to dot product and distance functions.
[Accelerate] [vDSP] Swift overlays to `vDSP_desamp` and `vDSP_deq22`.
[Accelerate] [vDSP] Vector Reduction Functions
[Accelerate] [vDSP] Elementwise Vector-Vector and Vector-Scalar Arithmetic
[Accelerate] [vDSP] Miscellaneous Conversion Functions
[Accelerate] [vDSP] Polynomial Evaluation Functions
[Accelerate] [vDSP] Clipping, Limit, and Threshold Functions
[Accelerate] [vDSP] Fill, Clear, and Generation Functions
[Accelerate] [vDSP] Integration Functions
[Accelerate] [vDSP] Vector Type Conversion Functions
[Accelerate] [vDSP] Swift overlays to Vector-Vector Extrema and Single-Vector Operations
