The design and implementation have been updated, with a StaticBigInt.Words type and a Builtin.wordAtIndex_IntLiteral(_:_:) function.
Could the interchange formats be implemented as two generic types, outside of the standard library?
The namespace would be the package module.
public struct BinaryInterchangeFormat<BitPattern>
where BitPattern: FixedWidthInteger & UnsignedInteger {}
public typealias Binary16 = BinaryInterchangeFormat<UInt16>
public typealias Binary32 = BinaryInterchangeFormat<UInt32>
public typealias Binary64 = BinaryInterchangeFormat<UInt64>
public struct DecimalInterchangeFormat<BitPattern>
where BitPattern: FixedWidthInteger & UnsignedInteger {}
public typealias Decimal32 = DecimalInterchangeFormat<UInt32>
public typealias Decimal64 = DecimalInterchangeFormat<UInt64>
Are there any designs for arbitrary-precision floating-point literals?
Could the compiler generate a multiple-of-32-bits pattern, as an integer literal?
The generic type idea is interesting (as opposed to a protocol). Not sure if defining them outside the standard library would be as impactful but that's rather an orthogonal discussion I think.
Part of the point here is that built-in floating-point types support all the operations required for IEEE interchange formats, and that useful generic algorithms can be written for all such interchange types whether or not they support arithmetic operations (e.g., conversion among floating-point types of different precision). This is an argument for modeling this concept as a protocol as opposed to a generic type, since Float obviously cannot be retroactively typealiased as BinaryInterchangeFormat<UInt32> even as it is the type for the binary 32-bit floating-point interchange format.
For the purposes of this discussion here, I'm just hoping to bring into the collective awareness that the proposed StaticBigInt fits in some respects in the same niche with respect to built-in fixed-width integer types as interchange types do for floating point. This may have bearing on how the type is not just named but designed. For instance, which APIs should we offer? If we adopt this analogy with floating-point interchange formats, then we needn't be shy about not offering any arithmetic operations.
Sort of: the discussion in SR-7124 may be relevant here.
2 Likes
I wanted to use arbitrary-precision literals in the BigInt and DoubleWidth prototypes, but it doesn't seem possible to initialize those types from a sequence of words.
So instead, I've added a new prototype which implements large fixed-width integers, each stored as a SIMD vector of words. Multiplication and division aren't implemented yet.
The new prototype compiles in Swift 5.6, but not in Swift 5.7 unless the -requirement-machine flags are on. It's also listed as one of the slowest tests on Linux.
https://github.com/benrimmington/swift/blob/staticbigint/test/Prototypes/SIMDWordsInteger.swift
1 Like