[swift-evolution] [Proposal] Random Unification

Jonathan Hull jhull at gbis.com
Sat Jan 13 19:48:31 CST 2018 

Basically, my point is that I want to be able to operate generically.

> On Jan 13, 2018, at 5:20 AM, Letanyan Arumugam <letanyan.a at gmail.com> wrote:
> 
> 
>> On 13 Jan 2018, at 02:24, Jonathan Hull <jhull at gbis.com <mailto:jhull at gbis.com>> wrote:
>> 
>> I think we have different definitions of consistency.  I am fine with the ergonomics of (0…100).random() as a convenience, but it really worries me here that everything is special cased.  Special cased things are fine for individual projects, but not the standard library.  We should make sure that the design is flexible and extensible, and that comes in part from having a consistent interface.
>> 
> 
> I think we just want different consistencies. Mine is that I want the same mental model of having to get a random value from some explicit ’set’/’space’.
> 
>> Also, as I said before, we really shouldn’t be doing these crazy contortions to avoid ‘random() % 100’.  Instead we should look for that pattern and issue with a warning + fixit to change it to random(in:).  I think that will be much more effective in actually changing the behavior in the long run.
>> 
>> Finally, tying everything to Range is extremely limiting.  I understand if we don’t want to add other types to the standard library, but I should be able to build on what we add to do it myself without having to reinvent the wheel for each type.  It is important to have a consistent story for these things (including multi-dimensional types) so that they can interoperate.
>> 
> 
> As a stated above I don’t think of it as being tied to a range, but rather a set of possible values. If you want to have multi-dimensional generators, could you not add an extension on an array to generate a value treating the array's elements as constraints?
> 
> Using CGPoint as an example with Nate’s api design of random.
> 
> public enum ConstraintKind<T: Comparable> {
> 	case constant(T)
> 	case range(T, T)
> 	case custom((RandomNumberGenerator) -> T)
> }
> 
> public enum PointConstraint {
> 	case x(ConstraintKind<CGFloat>)
> 	case y(ConstraintKind<CGFloat>)
> }
> 
> extension Array where Element == PointConstraint {
> 	func random(from constraintKind: ConstraintKind<CGFloat>,
> 			using generator: RandomNumberGenerator = Random.default
> 		) -> CGFloat {
> 		switch constraintKind {
> 		case let .constant(a): return a
> 		case let .range(min, max): return (min...max).random(using: generator)
> 		case let .custom(f): return f(generator)
> 		}
> 	}
> 	
> 	public func createRandom(using generator: RandomNumberGenerator = Random.default) -> CGPoint {
> 		var x: CGFloat? = nil
> 		var y: CGFloat? = nil
> 		
> 		for constraint in self {
> 			switch constraint {
> 			case let .x(c): x = random(from: c, using: generator)
> 			case let .y(c): y = random(from: c, using: generator)
> 			}
> 		}
> 		
> 		return CGPoint(x: x ?? 0.0, y: y ?? 0.0)
> 	}
> }
> 
> let pointSpace: [PointConstraint] = [
> 	.x(.range(2, 32.5)),
> 	.y(.constant(4))
> ]
> 
> pointSpace.createRandom()
> 
> 
> 
> This uses the idea that constraints create a space of possible CGPoint values that createRandom 'gets' from.
> 
> 
> You could make array conform to some ConstraintRandom protocol when we get conditional conformance.
> 
>> We really should be looking at GamePlayKit more for design inspiration.  There are several use-cases there that are being blatantly ignored in this discussion.  For example, what if I want to randomly generate a game world (e.g. The square from The Battle For Polytopia” formerly “SuperTribes”)?  Or what if I want an effect where it randomly fades in letters from a String.  (…).random() will be completely inadequate for these things.
>> 
>> Thanks,
>> Jon
>> 
>> 
>> 
>>> On Jan 12, 2018, at 5:11 AM, Letanyan Arumugam <letanyan.a at gmail.com <mailto:letanyan.a at gmail.com>> wrote:
>>> 
>>> Nate’s design follows a consistent idea of getting a random value from some set of values. Adding the static method random() to a type essentially creates an implicit set which you yourself said leads to inconsistency (Double/Int). Secondly I don’t see why random(in:) should be added when it is just a different spelling for what is already provided. If my second statement is incorrect and there’s something I’m missing please correct me?
>>> 
>>> I think that consistency outweighs the random trapping inconsistency, however I would actually be fine if random returned an optional. Though the way random is used would likely lead to less opportunities for a trap than the other methods you mention. 
>>> 
>>> 
>>> Letanyan
>>> 
>>>> On 12 Jan 2018, at 04:39, Alejandro Alonso <aalonso128 at outlook.com <mailto:aalonso128 at outlook.com>> wrote:
>>>> 
>>>> If anything, Nate’s design is inconsistent as properties like `.first` and `.last` return an optional, and methods like `.min()` and `.max()` return an optional as well. Having `.random()` on ranges be an exception and return non optionals are inconsistent with other collection facilities, and with other collections that aren’t ranges that return optionals on `.random()`.
>>>> 
>>>> - Alejandro
>>>> 
>>>> On Jan 11, 2018, 12:06 PM -0600, Letanyan Arumugam via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>>, wrote:
>>>>> This is really cool and seems very powerful. However I don’t think we should sacrifice consistency for extendability. Especially when the extendability would not be what most people need. 
>>>>> 
>>>>> What I am basically trying to say is that. I think the proposals current design direction fits better in a Random library rather than the Standard Library. And Nate’s design more directly addresses the motivating points of the proposal.
>>>>> 
>>>>> Letanyan
>>>>> 
>>>>>> 
>>>>>> Sure. Small disclaimer that this was originally written back in the Swift 1~2 days, so it is overdue for a simplifying rewrite.
>>>>>> 
>>>>>> Also, I should point out that the term “Source” has a special meaning in my code.  It basically means that something will provide an ~infinite collection of values of a type T.   I have what I call a “ConstantSource” which just wraps a T and gives it back when asked.  But then I have a bunch of other “sources" which let you create repeating patterns and do deferred calculations and things like that.  Finally I have a “RandomSource” which is part of what started this discussion.  You set up a RandomSource with a set of constraints, and then it gives you random values of T that adhere to those constraints (e.g. colors with a range of hues but the same saturation) whenever you ask for them.
>>>>>> 
>>>>>> This is really useful for doing things like graphic effects because, for example, I can ask for a source of colors and a source of line widths and then get out a large variety of interesting patterns from the same algorithm.  I can make simple stripes with ConstantSources, or I can make repeating patterns of lines with repeating sources, or I can have random colors which look good together by using a RandomSource.  I can take a BezierPath and make it look hand-drawn by breaking it into a bunch of lines and then offset the points a small amount using a RandomSource of CGVectors.
>>>>>> 
>>>>>> Not sure how useful this concept of randomness (and pattern) is to others, but I find it immensely useful!  Not sure of the best way to implement it.  The way I do it is a type erased protocol with private conforming structs and then public initializers on the type-erasing box.  The end result is that I can just say:
>>>>>> 
>>>>>> let myConst = Source(1) //ConstantSource with 1 as a value
>>>>>> let myPattern = Source([1, 2]) //OrderedSource which repeats 1, then 2 over and over forever
>>>>>> let myMeta = Source([myConst, myPattern]) //Will alternate between sub-sources in order. Can be nested.
>>>>>> //…and so on.
>>>>>> 
>>>>>> It is quite extensible and can make very complex/interesting patterns very easily.  What I like about it is that (well controlled) random values and patterns or constant values can be interchanged very easily.
>>>>>> 
>>>>>> The RandomSource has a RandomSourceCreatable Protocol that lets it take random bits and turn them into objects/structs of T adhering to the given constraints.  This is way more complex under the hood than it needs to be, but it works well in practice, and I haven’t gotten around to cleaning it up yet:
>>>>>> 
>>>>>> public protocol RandomSourceCreatable {
>>>>>>     associatedtype ConstraintType = Self
>>>>>>     
>>>>>>     
>>>>>> ///This should be implimented by simple types without internal components
>>>>>>     
>>>>>> static func createRandom(rnd value:RandomSourceValue, constraint:RandomSourceConstraint<ConstraintType>)->Self
>>>>>>     
>>>>>> ///This should be implimented by complex types with multiple axis of constraints
>>>>>>     
>>>>>> static func createRandom(rnd value:RandomSourceValue, constraints:[String:RandomSourceConstraint<ConstraintType>])->Self
>>>>>>     
>>>>>>     
>>>>>> ///Returns the proper dimension for the type given the constraints
>>>>>>     
>>>>>> static func dimension(given contraints:[String:RandomSourceConstraint<ConstraintType>])->RandomSourceDimension
>>>>>>     
>>>>>>     
>>>>>> ///Validates the given contraints to make sure they can create valid objects. Only needs to be overridden for extremely complex types
>>>>>>     static func validateConstraints(_ constraints:[String:RandomSourceConstraint<ConstraintType>])->Bool
>>>>>>     
>>>>>>     
>>>>>> ///Convienience method which provides whitelist of keys for implicit validation of constraints
>>>>>>     static var allowedConstraintKeys:Set<String> {get}
>>>>>>    }
>>>>>> 
>>>>>> Most of these things also have default implementations so you only really have to deal with them for complex cases like colors or points.  The constraints are given using a dictionary with string keys and a RandomSourceConstraint value, which is defined like this:
>>>>>> 
>>>>>> public enum RandomSourceConstraint<T> {
>>>>>>     case none
>>>>>>     case constant(T)
>>>>>>     case min(T)
>>>>>>     case max(T)
>>>>>>     case range (T,T)
>>>>>>     case custom ( (RandomSourceValue)->T )
>>>>>> //A bunch of boring convenience code here that transforms values so I don’t always have to switch on the enum in other code that deals with this. I just ask for the bounds or constrained T (Note: T here refers to the type for a single axis as opposed to the generated type. e.g. CGFloat for a point) 
>>>>>>     }
>>>>>> 
>>>>>> I have found that this handles pretty much all of the constraints I need, and the custom constraint is useful for anything exotic (e.g. sig-figs).  The RandomSource itself has convenience inits when T is Comparable that let you specify a range instead of having to create the constraints yourself.
>>>>>> 
>>>>>> I then have conformed many standard types to RandomSourceCreatable so that I can create Sources out of them.  Here is CGPoint for reference:
>>>>>> 
>>>>>> extension CGPoint:RandomSourceCreatable {
>>>>>>     
>>>>>>     
>>>>>> public static func dimension(given contraints:[String:RandomSourceConstraint<CGFloat>])->RandomSourceDimension {
>>>>>>         
>>>>>> return RandomSourceDimension.manyWord(2)
>>>>>>     }
>>>>>>     
>>>>>>     public typealias ConstraintType = CGFloat
>>>>>>     public static var allowedConstraintKeys:Set<String>{
>>>>>>         return ["x","y"]
>>>>>>     }
>>>>>>     
>>>>>>     
>>>>>> public static func createRandom(rnd value:RandomSourceValue, constraints:[String:RandomSourceConstraint<CGFloat>])->CGPoint {
>>>>>>         let xVal = value.value(at: 0)
>>>>>>         let yVal = value.value(at: 1)
>>>>>>         
>>>>>> //Note: Ints have a better distribution for normal use cases of points
>>>>>>         let x = CGFloat(Int.createRandom(rnd: xVal, constraint: constraints["x"]?.asType({Int($0 * 1000)}) ?? .none))/1000
>>>>>>         let y = CGFloat(Int.createRandom(rnd: yVal, constraint: constraints["y"]?.asType({Int($0 * 1000)}) ?? .none))/1000
>>>>>>         return CGPoint(x: x, y: y)
>>>>>>     }
>>>>>>     }
>>>>>> 
>>>>>> Notice that I have a RandomSourceValue type that provides the random bits of the requested dimension. When I get around to updating this, I might do something closer to the proposal, where I would just pass the generator and grab bits as needed.  The main reason I did it the way I did is that it lets me have random access to the source very easily.  
>>>>>> 
>>>>>> The ‘asType’ method converts a constraint to work with another type (in this case Ints).
>>>>>> 
>>>>>> Colors are a bit more complicated, mainly because I allow a bunch of different constraints, and I also have validation code to make sure the constraints fit together properly. I also ask for different amounts of randomness based on whether it is greyscale or contains alpha. Just to give you a sense, here are the allowed constraint keys for a CGColor:
>>>>>> public static var allowedConstraintKeys:Set<String>{
>>>>>>         return ["alpha","gray","red","green","blue", "hue", "saturation", "brightness"]
>>>>>>     }
>>>>>> 
>>>>>> and here is the creation method when the keys are for RGBA (I have similar sections for HSBA and greyscale):
>>>>>> 
>>>>>> let rVal = value.value(at: 0)
>>>>>>     let gVal = value.value(at: 1)
>>>>>>     let bVal = value.value(at: 2)
>>>>>>     let aVal = value.value(at: 3)
>>>>>>     let r = CGFloat.createRandom(rnd: rVal, constraint: constraints["red"] ?? .range(0,1))
>>>>>>     let g = CGFloat.createRandom(rnd: gVal, constraint: constraints["green"] ?? .range(0,1))
>>>>>>     let b = CGFloat.createRandom(rnd: bVal, constraint: constraints["blue"] ?? .range(0,1))
>>>>>>     let a = CGFloat.createRandom(rnd: aVal, constraint: constraints["alpha"] ?? .constant(1.0))
>>>>>>             
>>>>>>     return self.init(colorSpace: CGColorSpaceCreateDeviceRGB(), components: [r,g,b,a])!
>>>>>> 
>>>>>> 
>>>>>> The end result is that initializing a source of CGColors looks like this (either parameter can be omitted if desired):
>>>>>> 
>>>>>> let colorSource:Source<CGColor> = Source(seed: optionalSeed, constraints:["saturation": .constant(0.4), "brightness": .constant(0.6)])
>>>>>> 
>>>>>> Anyway, I hope this was useful/informative.  I know the code is a bit messy, but I still find it enormously useful in practice.  I plan to clean it up when I find time, simplifying the RandomSourceValue stuff and moving from String Keys to a Struct with static functions for the constraints.  The new constraints will probably end up looking like this:
>>>>>> 
>>>>>> let colorSource:Source<CGColor> = Source(seed: optionalSeed, constraints:[.saturation(0.4), .brightness(0.4...0.6)])
>>>>>> 
>>>>>> Thanks,
>>>>>> Jon
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> swift-evolution mailing list
>>>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>>> 
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20180113/ab566d78/attachment.html>

More information about the swift-evolution mailing list