[Sketch]Arbitrary-precision BigInt #84

rothomp3 · 2019-12-17T18:23:53Z

Fixes #5

This is the step 2 "Sketch" PR. It's actually very complete, but obviously perhaps not ideal in style and documentation (since there is none of the latter). Probably needs more tests too, though there are some.

The basic architecture is based on Knuth's algorithms for this purpose. An integer is broken up into "digits" where each digit is in base 64 (or base 32 on 32-bit systems, which are supported). This maps nicely onto the BinaryInteger protocol since we can simply use an array of Uint for the words. We're also using 2's complement internally, which is super convenient because then for any pair of BigInts that are each only one word long, we can simply delegate to the regular operators for a minimal overhead.

stephentyrone · 2019-12-17T18:51:18Z

Sources/NumericsShims/include/NumericsShims.h

@@ -143,6 +143,18 @@ HEADER_SHIM float libm_log10f(float x) {
  return __builtin_log10f(x);
 }

+HEADER_SHIM float libm_ceilf(float x) {


These don't appear to be used anywhere?

No, I only use the double version in the BigInt implementation, but I thought for the sake of completeness I would add all the variants. If that's wrong, I'd be happy to take 'em out!

As noted at the use sites, you don't need any of these.

stephentyrone · 2019-12-17T18:55:00Z

Sources/BigInt/BigInt.swift

+    }
+
+    public init?<T>(exactly source: T) where T : BinaryFloatingPoint {
+        if libm_ceil(Double(source)) != Double(source) { return nil }


This check can be source.rounded(.towardZero) != source. But you also need to eliminate infinity, right?

stephentyrone · 2019-12-17T19:10:06Z

Sources/BigInt/BigInt.swift

+        var float = Double(isNegative ? -source : source)
+        var words = Words()
+        while float > 0.0 {
+            let digit = UInt(libm_remainder(float, Double(UInt.max) + 1.0))


This doesn't do what you want it to; remainder(a,b) produces a value in [-b/2, b/2], but you need a result in [0,b). This will trap for many inputs when you try to init UInt with a negative value. The standard library gives you everything you need here:

let radix = T(sign: .plus, exponent: T.Exponent(UInt.bitWidth), significand: 1) repeat { digit = UInt(float.truncatingRemainder(dividingBy: radix)) words.append(digit) float = (float / radix).rounded(.towardZero) } while float != 0

You need to handle a bunch of edge cases that this currently ignores, too: infinity, NaN, and the case where UInt.max > T.greatestFiniteMagnitude (in which case you get a single word that is just UInt(float).)

stephentyrone · 2019-12-17T19:10:32Z

Sources/NumericsShims/include/NumericsShims.h

@@ -143,6 +143,18 @@ HEADER_SHIM float libm_log10f(float x) {
  return __builtin_log10f(x);
 }

+HEADER_SHIM float libm_ceilf(float x) {


As noted at the use sites, you don't need any of these.

rothomp3 · 2019-12-17T20:33:24Z

Ok, new commit to address the floating-point feedback. There doesn't seem to be any easy way to test the one with the T.greatestFiniteMagnitude absent a Float16 type in the stdlib.

Sajjon · 2019-12-18T13:55:56Z

@rothomp3 Friendly reminder that you can "bulk" manage "access control" using extensions. Extension also give more clear groupings (especially when used with // MARK (which renders nicely in Xcode 11)).

I recommend declaring BigInt in one scope with just the stored properties (and if applicable any "designated" initializer. I write "designated" since structs does not have that formally, but sometimes conceptually).

So:

public extension BigInt {
    func foo() {}

    func bar() {}
}

Which you can at any point change to internal just by changing one statement, as opposed to what you currently have:

extension BigInt {
    public func foo() {}

   public func bar() {}
}

Sajjon · 2019-12-18T13:57:56Z

@rothomp3 I have not yet looked through your PR in detail, I'm sure it is great! But I just wanted to give you two references - which you surely know about, but if not they might be useful:

Apple's own BigInt Prototype

attaswift/BigInt

rothomp3 · 2019-12-18T19:13:51Z

@rothomp3 I have not yet looked through your PR in detail, I'm sure it is great! But I just wanted to give you two references - which you surely know about, but if not they might be useful:

Apple's own BigInt Prototype

attaswift/BigInt

So both of those use additional storage for the sign, and all the extra math required for that, instead of using 2's complement to store the BigInts the same way the language/CPU already store signed integers of 64 bits or less. I believe my way more effectively leverages the hardware.

xwu · 2019-12-19T15:07:58Z

I believe my way more effectively leverages the hardware.

Do we have benchmarks that demonstrate this? (The BigInt implementations I’ve seen use sign-magnitude, and I don’t think it’s principally for ease of implementation.)

stephentyrone · 2019-12-19T17:11:13Z

I believe my way more effectively leverages the hardware.

Do we have benchmarks that demonstrate this?

It makes (approximately) no difference. This is pretty easy to see even without benchmarks.

First off, note that converting from one to the other is O(n), and every arithmetic and bitwise operation defined on FixedWidthInteger is at least O(n), so there can be no difference in asymptotic performance--you could always just convert, do the operation, and convert back.

So we're only interested in the the constants.

bitwise operations are exactly the same either way.
addition and subtraction are slightly easier in the 2s complement representation.
multiplication requires a tiny bit more bookkeeping (I really mean a tiny bit--the difference is essentially immaterial, a couple additional operations on Int / UInt for schoolbook multiplication because you need to treat the high-order word differently from the rest, and essentially no additional operations for fast multiplication algorithms).
division is just multiplication and subtraction, so doesn't matter.

This approach is fine, and most closely matches the semantics of FixedWidthInteger, so it's the easiest to use in some ways.

@rothomp3, sorry, I've been busy this week, but I'll give this a more thorough review next week and once we're to a good place I'll set up a branch to merge it onto for further development.

stephentyrone · 2019-12-19T17:15:16Z

@rothomp3 Friendly reminder that you can "bulk" manage "access control" using extensions.

We deliberately don't do this in the standard library, and I'm going to follow that style with Swift Numerics to facilitate moving code into the standard library if evolution wants some of these features in the future. I know that people have strong opinions about it, but ultimately it doesn't matter very much. Please keep explicit access control for now for simplicity.

Wildchild9 · 2019-12-23T21:15:07Z

I was looking at the code for the BigInt failable initializer that takes a String and I had a couple of thoughts:

We should allow for the presence of a prefix + operator
We can do remove redundant operations by dropping leading zeros

I think the initializer should be modified to something along the lines of the following:

public init?(_ description: String) {
    guard let firstCharacter = description.first else { return nil }
    var description = description
    var isNegative = false
    
    if firstCharacter == "-" {
        guard description.count > 2 else { return nil }
        isNegative = true
        description.removeFirst()
    } else if firstCharacter == "+" {
        guard description.count > 2 else { return nil }
        description.removeFirst()
    }
    
    let validDigits = Set("0123456789")
    guard description.allSatisfy({ validDigits.contains($0) }) else { return nil }
    var result: BigInt = 0
    
    for (i, char) in description.drop(while: { $0 == "0" }).reversed().enumerated() {
        result += BigInt(char.wholeNumberValue!) * pow(10, BigInt(i))
    }
    
    if isNegative {
        result = -result
    }
    
    words = result.words
}

Eliminate unnecessary math function calls, and also handle floating point edge cases better.

…dback

benrimmington

(Not a full review)

benrimmington · 2019-12-30T18:22:29Z

Package.swift


    .testTarget(name: "ComplexTests", dependencies: ["Complex", "NumericsShims"]),
    .testTarget(name: "RealTests", dependencies: ["Real"]),
+    .testTarget(name: "BigIntTests", dependencies: ["BigInt"]),


The existing products, targets, dependencies are in alphabetical order.

benrimmington · 2019-12-30T18:23:22Z

Sources/BigInt/BigInt.swift

+//  BigInt.swift
+//  swift-numerics
+//
+//  Created by Robert Thompson on 2/4/19.


The existing swift files in Sources and Tests:

begin with a standard copyright/license comment.

use an indent width of two spaces.

benrimmington · 2019-12-30T18:31:19Z

Sources/BigInt/BigInt.swift

+//  Created by Robert Thompson on 2/4/19.
+//
+
+public struct BigInt: BinaryInteger, SignedNumeric, SignedInteger, CustomStringConvertible, LosslessStringConvertible, Hashable {


I think this list can be reduced (if needed):

SignedInteger inherits from BinaryInteger and SignedNumeric.

BinaryInteger inherits from CustomStringConvertible and Hashable.

LosslessStringConvertible inherits from CustomStringConvertible.

Suggested change

public struct BigInt: BinaryInteger, SignedNumeric, SignedInteger, CustomStringConvertible, LosslessStringConvertible, Hashable {

public struct BigInt: SignedInteger, LosslessStringConvertible {

Sources/BigInt/BigInt.swift

benrimmington · 2019-12-30T18:44:04Z

Sources/BigInt/BigInt.swift

+
+    @inlinable
+    public func signum() -> BigInt {
+        return _isNegative ? -1 : 1


Should this return zero when self == 0?

As per benrimmington's excellent suggestion Co-Authored-By: Ben Rimmington <[email protected]>

Includes reformatting to use 2-space indentation and the correct file headers, among other simplifications.

@Wildchild9

as per further suggestions from @Wildchild9, adding in the removing leading zeros part I missed.

rothomp3 · 2019-12-30T21:04:28Z

Let me just say I think it's hilarious how much scrutiny the LosslessStringConvertible initializer has gotten, all because it happens to be the first method in the file ;)

stephentyrone · 2019-12-30T21:52:37Z

Hi @rothomp3, I created a "biginteger" branch for this work, since there's more development to be done than fits neatly in a single PR. Can you update this PR to point to that branch (I can do this for you if you need help, but it will need to wait a couple days).

rothomp3 · 2019-12-30T22:33:49Z

Retargeted PR to biginteger branch!

Sources/BigInt/BigInt.swift

UInt64, Int64, etc have more than one word on 32-bit architectures

nixberg · 2020-02-14T12:19:36Z

Sources/BigInt/BigInt.swift

+
+  public var bitWidth: Int { words.count * UInt.bitWidth }
+
+  public var trailingZeroBitCount: Int { words.first?.trailingZeroBitCount ?? 0 }


Shouldn’t that be something like

var trailingZeroBitCount: Int { var totalZeros = 0 for word in words { let zeros = word.trailingZeroBitCount totalZeros += zeros if zeros < UInt.bitWidth { break } } return totalZeros }

No, imagine that the entire array of Uints is one giant integer. Only the trailing zeros in the least significant word are actually trailing, the rest are in the middle!

If the least significant word is all zeroes (e.g. UInt.max + 1), you'll need to keep going up the chain.

Doh! You're right! I feel suddenly stupid, I'll fix that.

Fixed it and added some quick tests for it too.

Also add a couple tests for it

xwu · 2020-02-15T08:56:18Z

Sources/BigInt/BigInt.swift

-  public var trailingZeroBitCount: Int { words.first?.trailingZeroBitCount ?? 0 }
+  public var trailingZeroBitCount: Int {
+    var totalZeros = 0
+    for word in words {


You don’t need to invoke trailingZeroBitCount on every word and then compare to bitWidth. That’s just asking if word == 0.

That's true, I think. I'll take a look.

Ok, updated to just explicitly check for word == 0, as I agree that's likely to be slightly faster.

dwaite · 2020-03-28T10:17:59Z

Sources/BigInt/BigInt.swift

+      let lhsWord = lhs.words[0]
+      let rhsWord = rhs.words[0]
+
+      let (result, isOverflow) = lhsWord.addingReportingOverflow(rhsWord)
+
+      if !isOverflow && result < Int.max {
+        lhs.words[0] = result
+        return
+      }
+      let knownNegativeResult = lhsWord > Int.max && rhsWord > Int.max
+
+      if lhsWord > Int.max || rhsWord > Int.max, !knownNegativeResult {
+        // positive + negative is always smaller, so overflow is a red herring
+        lhs.words[0] = result
+        return


Have you evaluated using pattern matches to clarify some of this code and make it a bit easier to spot any edge cases. For instance, here I believe you could do:

if lhs.words.count == 1, rhs.words.count == 1 { let lhsWord = lhs.words[0] let rhsWord = rhs.words[0] let lhsNegative = lhsWord > Int.max let rhsNegative = rhsWord > Int.max let sum = lhsWord &+ rhsWord let sumNegative = sum > Int.max switch (lhsNegative, rhsNegative, sumNegative) { case (true, true, false); lhs.words = [sum, UInt.max] return case (false, false, true); lhs.words = [sum, 0] return default: lhs.words[0] = sum return } }

rothomp3 · 2020-03-30T16:22:44Z

We definitely could do something like that, I’d need to try this code and make sure it actually catches all the cases correctly (looks fine at first glance).

…

On Mar 28, 2020, at 6:18 AM, David Waite ***@***.***> wrote: @dwaite commented on this pull request. In Sources/BigInt/BigInt.swift <#84 (comment)>: > + let lhsWord = lhs.words[0] + let rhsWord = rhs.words[0] + + let (result, isOverflow) = lhsWord.addingReportingOverflow(rhsWord) + + if !isOverflow && result < Int.max { + lhs.words[0] = result + return + } + let knownNegativeResult = lhsWord > Int.max && rhsWord > Int.max + + if lhsWord > Int.max || rhsWord > Int.max, !knownNegativeResult { + // positive + negative is always smaller, so overflow is a red herring + lhs.words[0] = result + return Have you evaluated using pattern matches to clarify some of this code and make it a bit easier to spot any edge cases. For instance, here I believe you could do: if lhs.words.count == 1, rhs.words.count == 1 { let lhsWord = lhs.words[0] let rhsWord = rhs.words[0] let lhsNegative = lhsWord > Int.max let rhsNegative = rhsWord > Int.max let sum = lhsWord &+ rhsWord let sumNegative = sum > Int.max switch (lhsNegative, rhsNegative, sumNegative) { case (true, true, false); lhs.words = [sum, UInt.max] return case (false, false, true); lhs.words = [sum, 0] return default: lhs.words[0] = sum return } } — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#84 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA6NZ2R5V7N54VYEIXZV32LRJXFGJANCNFSM4J37T7WA>.

See also: apple#97

xwu · 2020-06-02T18:11:52Z

Hey @rothomp3, are you still working on this issue? I've been exploring a design where we keep the lowest word inline. It seems promising and I'd like to work on it more, but don't want to step on any ongoing plans you have.

xwu · 2020-06-08T20:37:24Z

Hi all, I've shared an alternative implementation at #120 which starts from a different approach.

rothomp3 · 2020-06-10T15:30:07Z

Sorry I missed this message at the time, I am happy to keep working on it, but hadn’t heard anything in quite a while from the people responsible for merging it or telling me why they can’t ;) Anyway, I actually explored this option myself long before I made this PR, and in my testing it was _dramatically_ worse. It’s possible I’m doing it wrong though! Robert Thompson Platform Software Engineer WillowTree https://willowtreeapps.com

…

On Jun 2, 2020, at 2:12 PM, Xiaodi Wu ***@***.***> wrote: Hey @rothomp3 <https://github.com/rothomp3>, are you still working on this issue? I've been exploring a design where we keep the lowest word inline. It seems promising and I'd like to work on it more, but don't want to step on any ongoing plans you have. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#84 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA6NZ2WJXSFS4PMGISEM2SDRUU6HPANCNFSM4J37T7WA>.

xwu · 2020-06-10T21:43:17Z

Anyway, I actually explored this option myself long before I made this PR, and in my testing it was dramatically worse. It’s possible I’m doing it wrong though!

Yup. Keeping the lowest word inline sure does make things worse! Check out some of the other ideas I've been exploring over at the other PR though :)

rothomp3 · 2020-06-11T19:12:29Z

Anyway, I actually explored this option myself long before I made this PR, and in my testing it was dramatically worse. It’s possible I’m doing it wrong though!

Yup. Keeping the lowest word inline sure does make things worse! Check out some of the other ideas I've been exploring over at the other PR though :)

I don't even have a good explanation for why, other than perhaps "the people who wrote Swift.Array are very smart, and very good at their jobs!"

[BigInt] Rename module

stephentyrone · 2020-06-17T14:02:42Z

I don't even have a good explanation for why

The short version is pretty much "special cases make things slower". For some input distributions, it should be a win to have a special small representation (like we do for String), but that's definitely something that we would take about adding down the road--we want to get the general implementation right first.

ezfe · 2022-01-27T01:02:13Z

What's the status on these changes?

rothomp3 · 2022-01-27T15:27:23Z

What's the status on these changes?

Well, I’m still here, I’m not sure what the next step should be, though!

stephentyrone · 2022-01-27T15:35:43Z

The main thing that's missing at this point is that the tests need to be bulked up pretty enormously, and we should be looking at better benchmarks as well. That's something that's OK to do on a branch, though, so I think that it's pretty reasonable to give this a final review and merge it in the near future.

I will probably do a fairly invasive restructuring of the code once it's merged to split it out into somewhat finer-grained files to bring it more in line with the rest of the project, FWIW, which will cause you some hassle if you have changes on other branches that you're waiting to merge after this.

rothomp3 · 2022-01-27T15:37:02Z

Nope, go for it!

LiarPrincess · 2022-04-01T09:12:55Z

The main thing that's missing at this point is that the tests need to be bulked up pretty enormously, and we should be looking at better benchmarks as well. That's something that's OK to do on a branch, though, so I think that it's pretty reasonable to give this a final review and merge it in the near future.

As far as the tests go: there is Violet - Python VM written in Swift which has its own implementation of BigInt, so this may be useful. Our tests are quite robust, but the problem is that Violet implementation is quite different:

In Violet we use an union (via tagged pointer) of Int32 (called Smi, after V8) and a heap allocation (magnitude + sign representation) with ARC for garbage collection. You can see our documentation for details.

Which means that technically we have 3 different implementations of BigInt:

Bigint - combines Smi and BigIntHeap into a single external interface (just be careful on COW) - BigInt.swift
small Int32* stored inline inside the pointer (we call it Smi) - Smi.swift
BigIntHeap - heap allocated when we do not fit in Smi - BigIntHeap.swift for the math part and BigIntStorage.swift for the memory layout/representation

Also, in most of the cases we went with property based testing with means that we test millions of inputs to check if the general rule holds (for example: a+b=c -> c-a=b etc.). This takes time, but pays for itself by finding weird overflows in bit operations (we store “sign + magnitude”, so bit operations are a bit difficult to implement).

[*] There is an 64-bit assumption for the whole project. Violet is more-or-less a closed system where we write with the assumption that we are the only consumers. This allows us to concentrate on things that we need, instead of designing for every use case (for BigInt we heavily optimize for small integers assuming non-uniform distribution of inputs).

LiarPrincess · 2022-10-28T20:00:45Z

What are we doing about tests?

I can create a pull request(s) with tests from Violet - Python VM written in Swift. In each pull request we would decide if we want them or not. The code has already been written, so this cost was already paid.

If we decide not to merge them then no biggie. I think that it is worth to run them, to check if something fails.

LiarPrincess · 2022-10-28T20:13:58Z

Btw. It may be a good idea to write an 'Int semantics' article for the official Swift blog.

This would include common pitfalls:

when things overflow - everyone knows that add, sub and mul overflow, but how many programmers know that div can also overflow? (signed numbers in 2 complement Int.min / -1 is unrepresentable)
rounding modes in shifts - many programmers believe that instead of dividing by a power of 2 you can just shift. Well... this is true in some cases. Tbh. maybe we should expose additional methods with enum RoundingMode as an argument?
etc.

rothomp3 changed the title ~~Arbitrary-precision BigInt~~ [Sketch]Arbitrary-precision BigInt Dec 17, 2019

stephentyrone reviewed Dec 17, 2019

View reviewed changes

Robert Thompson added 5 commits December 30, 2019 10:33

Initial commit of BigInt

96d41bc

Use NumericShims for math functions

bc2f9fb

Address PR feedback

cb56525

Eliminate unnecessary math function calls, and also handle floating point edge cases better.

BigInt no longer depends on NumericsShims

ea2b6f8

slightly refactor LosslessStringConvertible initializer as per PR fee…

524dc69

…dback

rothomp3 force-pushed the BigInt branch from f1e4754 to 524dc69 Compare December 30, 2019 15:41

whoops

ac50a90

benrimmington reviewed Dec 30, 2019

View reviewed changes

Robert Thompson and others added 5 commits December 30, 2019 15:12

Update Sources/BigInt/BigInt.swift

eceae6d

As per benrimmington's excellent suggestion Co-Authored-By: Ben Rimmington <[email protected]>

oops, change both occurrences of digitsAndDash

b46dcf9

Update following suggestions from @benrimmington

821fcbd

Includes reformatting to use 2-space indentation and the correct file headers, among other simplifications.

Missed a spot where things should be alphabetical

cced27a

Update LosslessStringConvertible initializer

6785869

as per further suggestions from @Wildchild9, adding in the removing leading zeros part I missed.

rothomp3 changed the base branch from master to biginteger December 30, 2019 22:33

benrimmington reviewed Dec 31, 2019

View reviewed changes

Sources/BigInt/BigInt.swift Outdated Show resolved Hide resolved

This comment has been minimized.

Sign in to view

Robert Thompson added 4 commits January 29, 2020 09:55

Another fix for arm32 and actually for anything with multi-word ints

caeeaaa

UInt64, Int64, etc have more than one word on 32-bit architectures

Actual fix for multi-word integer types

52e7e70

Another fix for conversion of multi-word Ints

aaeb902

Fix two tests for arm32, should all pass now

cd88f16

nixberg reviewed Feb 14, 2020

View reviewed changes

Fix trailingZeroBitCount as per @nixberg

b74c1ce

Also add a couple tests for it

xwu reviewed Feb 19, 2020

View reviewed changes

Probably a slightly faster way to get trailingZeroBitCOunt

5ea7711

dwaite reviewed Mar 28, 2020

View reviewed changes

[BigInt] Rename module

2f60891

See also: apple#97

Merge pull request #7 from benrimmington/BigInt

935eac1

[BigInt] Rename module

sadiredd-sv approved these changes Nov 4, 2020

View reviewed changes

sadiredd-sv mentioned this pull request Nov 5, 2020

feat(smithy-swift): Big Number Support smithy-lang/smithy-swift#64

Merged

stephentyrone approved these changes Oct 28, 2022

View reviewed changes

Merge branch 'biginteger' into BigInt

f11ce9b

stephentyrone merged commit fd9722e into apple:biginteger Oct 28, 2022

	public struct BigInt: BinaryInteger, SignedNumeric, SignedInteger, CustomStringConvertible, LosslessStringConvertible, Hashable {
	public struct BigInt: SignedInteger, LosslessStringConvertible {


		public var bitWidth: Int { words.count * UInt.bitWidth }

		public var trailingZeroBitCount: Int { words.first?.trailingZeroBitCount ?? 0 }

[Sketch]Arbitrary-precision BigInt #84

[Sketch]Arbitrary-precision BigInt #84

Conversation

rothomp3 commented Dec 17, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rothomp3 commented Dec 17, 2019

Sajjon commented Dec 18, 2019

Sajjon commented Dec 18, 2019

rothomp3 commented Dec 18, 2019

xwu commented Dec 19, 2019

stephentyrone commented Dec 19, 2019 • edited Loading

stephentyrone commented Dec 19, 2019

Wildchild9 commented Dec 23, 2019

benrimmington left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rothomp3 commented Dec 30, 2019

stephentyrone commented Dec 30, 2019

rothomp3 commented Dec 30, 2019

This comment has been minimized.

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

xwu Feb 15, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rothomp3 commented Mar 30, 2020 via email

xwu commented Jun 2, 2020

xwu commented Jun 8, 2020

rothomp3 commented Jun 10, 2020 via email

xwu commented Jun 10, 2020 • edited Loading

rothomp3 commented Jun 11, 2020

stephentyrone commented Jun 17, 2020

ezfe commented Jan 27, 2022

rothomp3 commented Jan 27, 2022

stephentyrone commented Jan 27, 2022 • edited Loading

rothomp3 commented Jan 27, 2022

LiarPrincess commented Apr 1, 2022

LiarPrincess commented Oct 28, 2022

LiarPrincess commented Oct 28, 2022

stephentyrone commented Dec 19, 2019 •

edited

Loading

xwu Feb 15, 2020 •

edited

Loading

xwu commented Jun 10, 2020 •

edited

Loading

stephentyrone commented Jan 27, 2022 •

edited

Loading