Functions that accept arrays or array slices

[wgjcv (William James)]

@ksluder

This is the part I don’t understand. Rather use [UInt] directly as the type of a big integer, why not create a nominal BigInt type that wraps a [UInt] , and implement your algorithms as methods on BigInt ? That should avoid the need to understand anything about ArraySlice.

Almost all Swift Big Integer Libraries including mine have a similar construct such as below. I think this is what you are calling wrapping [UInt].

public struct APMInt: ExpressibleByStringLiteral, ExpressibleByIntegerLiteral,
                           SignedNumeric, BinaryInteger, SignedInteger {
    
   .......
    // instance variables
    var sign: Int                  // -1 for negative, 0 for zero, 1 for positive
    public var words: [UInt] = []   // magnitude of a APMInt
   .......
}

The major benefit of organizing the functions that operate on two arrays into an array extension is code reuse. For instance the array add functions are used in the library 37 times, but only once to add two APMInts.

I don't understand avoiding the need to understand anything about ArraySlice. I don't use ArraySlice now except to slice arrays and immediately convert back to arrays. The challenge is to figure out how to use them (without conversion to arrays) without a complete refactoring of my existing code and causing significant loss of performance.

[AlexanderM (Alexander Momchilov)]

Relevant: Use it or lose it: why safe C is sometimes unsafe Swift

[ksluder (Kyle Sluder)]

@wgjcv

The major benefit of organizing the functions that operate on two arrays into an array extension is code reuse. For instance the array add functions are used in the library 37 times, but only once to add two APMInts.

Aha, this is the part that I was missing. I know little about this problem space, so I wasn’t aware that addition of bignums is useful apart from implementing the actual bignum type.