Re: [swift-users] Sampling collections

[Jens Alfke via swift-users]

Well, write up a proposal and submit it 
 to 
swift-evolution and let people discuss it.

> I’m sorry we are spending so much time discussing why this may be difficult 
> for *someone* (because it likely won’t be us) to implement.

Welcome to the world of bike-shedding.  It’s not difficult to implement this, 
it’s difficult to design, because people have different needs and expectations. 
For a feature to go into a core library, there needs to be a strong enough need 
and there also needs to be agreement about how it should behave.

—Jens___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Sampling collections

[Jacob Bandes-Storch via swift-users]

I encourage anyone thinking about PRNG APIs to check out what C++ STL has
to offer: http://en.cppreference.com/w/cpp/numeric/random

And this analysis/extension of it:
http://www.pcg-random.org/posts/ease-of-use-without-loss-of-power.html

Jacob

On Sun, Apr 10, 2016 at 6:40 PM, Brent Royal-Gordon via swift-users <
swift-users@swift.org> wrote:

> > import Foundation
> >
> > (1..<4).sample
> > [1,2,3].sample
> > "abc".characters.sample
> > ["a": 1, "b": 2, "c": 3].sample
> >
> > Like so many users of Swift, I have extensions of IntegerType,
> ClosedInterval and CollectionType that avail me of the above methods and
> their family, but I’d much rather if such extensions came with Darwin or at
> least Foundation.
>
> I don't think a `sample` property or method is the right approach here. It
> would be using some sort of global source of random numbers, which means
> that:
>
> * It's not testable or repeatable
> * It needs to be synchronized with other threads
> * It can't be configured to use a different random number generator
>
> Personally, I would eventually like to see something like this in the
> standard library:
>
> protocol RandomizerProtocol {
> mutating func randomBytes(_ n: Int) -> [UInt8]
> // or possibly something involving a generic-length tuple,
> for speed
> }
> extension RandomizerProtocol {
> // for coin flips
> mutating func randomChoice() -> Bool { ... }
> // for choosing a random element
> mutating func randomChoice RandomAccessCollection>(from collection: CollectionType) ->
> CollectionType.Element { ... }
> // for choosing a random value from an uncountable range
> (e.g. Range)
> mutating func randomChoice(from
> range: Range) -> Element { ... }
> }
> struct Randomizer: RandomizerProtocol {
> init(state: [UInt8]) { ... }
> init() { self.init(state:
> somethingToMakeAGoodRandomState()) }
>
> mutating func randomBytes(_ n: Int) -> [UInt8] {
> // akin to arc4random()
> }
> }
>
> This would allow you to confine a random number generator to a particular
> thread, swap one implementation for another, or inject one with a fixed
> starting state as a dependency to make tests predictable. A design like
> this one works around the problems I described nicely.
>
> However, I don't think this is a high enough priority to address right
> now. This is borderline out-of-scope as "major new library functionality",
> and there's so much stuff to do that is truly core to the language, this
> simply seems like a distraction.
>
> --
> Brent Royal-Gordon
> Architechies
>
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Sampling collections

[Jens Alfke via swift-users]

> On Apr 10, 2016, at 6:01 PM, Milos Rankovic  
> wrote:
> 
> As I already stressed, I certainly do not imagine this to be 
> “Swift-specific”, nor do I see any reason it would need to be.

It sounds like you’re asking for a `sample` property to be added to NSArray, 
NSDictionary, NSSet, etc. You could certainly request that Apple do that, by 
filing a request at http://bugreport.apple.com, but don’t expect a reply; 
Apple’s framework teams are notoriously opaque.

Putting on my framework-designer hat, I’d argue that “random” is a broad 
concept with several possible implementations. Which RNG does `sample` use? 
Pick a cryptographic one and it might be too slow for some use cases; pick a 
fast one and it'd be insufficiently random, making it dangerous to use for 
anything related to security. The right answer might be to have a RNG protocol, 
with several implementations backed by different generators, that exposes a 
method like `randomElement(Collection)`.

> Also, it looks like you’ve missed my previous email in this thread where I 
> give examples of current Foundation extensions of Standard Library types, and 
> where I also make the bare bones of my wish-list rather more explicit.

The way those are implemented is a weird hack, so they’re not actually good 
examples of what you’re asking for. 

It’s not that Apple's Foundation framework contains any extensions to Swift; 
Foundation is lower-level and I don’t believe it has any knowledge at all of 
Swift. So this is not the same effect as when you import a Swift library to get 
extensions. Rather, importing Foundation is a hardwired signal to the Swift 
compiler to activate the implicit bridging between Swift’s String class and 
Foundation’s NSString (and likewise for Array/NSArray, etc.)

In Swift 3 this will supposedly change: these APIs will be added directly to 
the Swift classes, removing the need for bridging.

—Jens___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Sampling collections

[Milos Rankovic via swift-users]

> On 10 Apr 2016, at 23:12, Jens Alfke  wrote:
> You can easily implement your own `sample` property. 

The very first email of this thread has a link to my example implementation. 
Here it is again if you mist it: http://stackoverflow.com/a/30285125/1409907 
… however, my whole point is that 
I’d prefer if this important feature came with `Foundation`.

> So far Apple hasn’t added Swift-specific functionality to system frameworks…

As I already stressed, I certainly do not imagine this to be “Swift-specific”, 
nor do I see any reason it would need to be. Also, it looks like you’ve missed 
my previous email in this thread where I give examples of current Foundation 
extensions of Standard Library types, and where I also make the bare bones of 
my wish-list rather more explicit.

Please note, though, that my original mail was simply trying to find out if 
there are people who also wished they had this functionality available upon 
importing Foundation; if they too would enjoy using it in playgrounds, when 
teaching, or while testing their code… Imagine opening a blank playground and 
typing something silly like the following, while fully expecting there to be a 
`sample` method on arrays, just as there is `componentsSeparatedByString` on 
strings:

import Foundation

extension String {
var define: String? {
return DCSCopyTextDefinition(nil, self, CFRangeMake(0, 
utf16.count)).map{
$0.takeRetainedValue() as String
}
}
var trail: String {
var trail = [self]
while let word = 
trail.last?.define?.componentsSeparatedByString(" ").sample {
trail.append(word)
}
return trail.joinWithSeparator(" ") + "!"
}
}

for i in 1...100 {
print("Random".trail)
}

milos

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

[swift-users] Trouble assigning an array of C pointers to a C struct field

[Jens Alfke via swift-users]

I’m bridging a C API (that I wrote) to Swift; I’ve got most of it together, but 
I’m stuck on one part, where I can’t get the bridging code to compile without 
errors no matter how I write it.

The basic problem is I’ve got a dynamically-allocated opaque C pointer type 
(C4Key*), and there’s a struct in the C API with a field that points to a C 
array of these, plus a count. In Swift I have an array of these pointers, typed 
as [COpaquePointer], and I want to point the struct field to it.

Here’s the relevant bit of the C API:

typedef struct c4Key C4Key; // opaque type

C4Key* c4key_new(void);

typedef struct {
// ...
const C4Key **keys;
size_t keysCount;
} C4QueryOptions;

In my Swift code I have:

var opt = C4QueryOptions()
var keyHandles: [COpaquePointer] = wrappedKeys.map {$0.handle}
// Attempt 1, error is “Cannot assign [COpaquePointer] to 
COpaquePointer”:
opt.keys = 
// Attempt 2, error is "cannot assign value of type 
'UnsafePointer<[COpaquePointer]>' (aka 'UnsafePointer') 
to type 'UnsafeMutablePointer'"
withUnsafePointer() { keysPtr in
opt.keys = keysPtr
DoSomethingWith(opt)
}

It’s definitely a type-checking problem; I can’t convince the compiler to give 
me a pointer to the elements of the array as a COpaquePointer. Any clues?

—Jens___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Sampling collections

[Dave Yost via swift-users]

Every package that wraps C functions should be accompanied by a higher-level 
package that wraps the raw interface in best Swift fashion, IMO.

A C package without higher-level Swift wrappers is an invitation to chaos as a 
zillion people publish competing higher-level wrappers.

> On 2016-04-10, at 3:12 PM, Jens Alfke via swift-users  
> wrote:
> 
> 
>> On Apr 10, 2016, at 1:00 PM, Milos Rankovic  
>> wrote:
>> 
>> The ObjC–Swift bridge is relevant here only in the sense that I would also 
>> like sampling methods added to `NSArray`, `NSSet` or `NSDictionary`…
> 
> Any library or program can add methods to any class using extensions. You can 
> easily implement your own `sample` property. There may be a Swift library 
> somewhere that provides one; all you’d have to do is import it.
> 
> If you want to implement it yourself, you can call the C functions `random` 
> or `arc4random` directly from Swift. (You may need to add an #include to your 
> bridging header in Xcode.)
> 
>> What I would personally like to see, however (and what I was wondering the 
>> community feels about), is that one of these frameworks extends Standard 
>> Library data types and protocols with this functionality
> 
> So far Apple hasn’t added Swift-specific functionality to system frameworks; 
> the frameworks are in Objective-C or C, and the Swift compiler and runtime 
> bridge to that. What you’re suggesting would go the other direction, with a 
> framework offering custom API wrappers. Maybe that will happen in the near 
> future.
> 
> —Jens
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Sampling collections

[Jens Alfke via swift-users]

> On Apr 10, 2016, at 1:00 PM, Milos Rankovic  
> wrote:
> 
> The ObjC–Swift bridge is relevant here only in the sense that I would also 
> like sampling methods added to `NSArray`, `NSSet` or `NSDictionary`…

Any library or program can add methods to any class using extensions. You can 
easily implement your own `sample` property. There may be a Swift library 
somewhere that provides one; all you’d have to do is import it.

If you want to implement it yourself, you can call the C functions `random` or 
`arc4random` directly from Swift. (You may need to add an #include to your 
bridging header in Xcode.)

> What I would personally like to see, however (and what I was wondering the 
> community feels about), is that one of these frameworks extends Standard 
> Library data types and protocols with this functionality

So far Apple hasn’t added Swift-specific functionality to system frameworks; 
the frameworks are in Objective-C or C, and the Swift compiler and runtime 
bridge to that. What you’re suggesting would go the other direction, with a 
framework offering custom API wrappers. Maybe that will happen in the near 
future.

—Jens
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Sampling collections

[Milos Rankovic via swift-users]

> On 10 Apr 2016, at 22:16, Erica Sadun  wrote:
> 
> I don't think general random sources are a good fit for core functionality

I’m sorry, Erica, I still do not understand how your comments about “core 
functionality” reflect on my original question – have you seen it?

Certainly, there is plenty of precedent where Foundation extends Standard 
Library types and protocols:

// Foundation

extension String {
public func enumerateLinguisticTagsInRange…
}

// CoreGraphics

extension Double {
public init(_ value: CGFloat)
}

// Darwin

func yn(n: Int, _ x: Double) -> Double //...which are the bessel functions of 
first and second kind!

What I’m talking about would not look out of place with linguistic tags and 
bassel functions:

// Foundation

extension UnsignedIntegerType {
static var random: Self
}

extension ClosedInterval where Bound : UnsignedIntegerType {
var random: Bound
}

extension ClosedInterval where Bound : SignedIntegerType {
var random: Bound
}

extension CollectionType where Index.Distance == Int {
var sample: Generator.Element?
}

… which we could use by:

import Foundation

(1..<4).sample
[1,2,3].sample
"abc".characters.sample
["a": 1, "b": 2, "c": 3].sample

milos

> On 10 Apr 2016, at 22:16, Erica Sadun  wrote:
> 
> 
>> On Apr 10, 2016, at 2:39 PM, Milos Rankovic > > wrote:
>> 
>>> On 10 Apr 2016, at 21:23, Erica Sadun >> > wrote:
>>> 
>>> I do not think it's the role of a core language to worry about things like 
>>> distributions, bias, and sampling.
>> 
>> Why do you mention “the role of a core language” here? That was explicitly 
>> not the ambition of my question. I’m talking about extending the Standard 
>> Library types and protocols in the Foundation framework (as this is already 
>> done on a large scale). Or, if this is what you mean by “core language”, how 
>> does capitalising strings according to the rules of grammar of every 
>> language on the planet qualify as any more fitting the domain of the core 
>> language?
>> 
>> milos
>> 
> 
> While I don't think general random sources are a good fit for core 
> functionality, apparently, NSRandomSpecifier exists: 
> https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSRandomSpecifier_Class/index.html#//apple_ref/occ/cl/NSRandomSpecifier
>  
> 
> 
> Other material I consulted:
> Standard Library: https://en.wikipedia.org/wiki/Standard_library 
> 
> Foundation: 
> https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/ObjC_classic/
>  
> 
>  
> GameplayKit Randomization: 
> https://developer.apple.com/library/ios/documentation/General/Conceptual/GameplayKit_Guide/RandomSources.html#//apple_ref/doc/uid/TP40015172-CH9-SW1
>  
> 
> 
> -- E
> 

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Sampling collections

[Erica Sadun via swift-users]

> On Apr 10, 2016, at 2:39 PM, Milos Rankovic  
> wrote:
> 
>> On 10 Apr 2016, at 21:23, Erica Sadun > > wrote:
>> 
>> I do not think it's the role of a core language to worry about things like 
>> distributions, bias, and sampling.
> 
> Why do you mention “the role of a core language” here? That was explicitly 
> not the ambition of my question. I’m talking about extending the Standard 
> Library types and protocols in the Foundation framework (as this is already 
> done on a large scale). Or, if this is what you mean by “core language”, how 
> does capitalising strings according to the rules of grammar of every language 
> on the planet qualify as any more fitting the domain of the core language?
> 
> milos
> 

While I don't think general random sources are a good fit for core 
functionality, apparently, NSRandomSpecifier exists: 
https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSRandomSpecifier_Class/index.html#//apple_ref/occ/cl/NSRandomSpecifier
 


Other material I consulted:
Standard Library: https://en.wikipedia.org/wiki/Standard_library 

Foundation: 
https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/ObjC_classic/
 

 
GameplayKit Randomization: 
https://developer.apple.com/library/ios/documentation/General/Conceptual/GameplayKit_Guide/RandomSources.html#//apple_ref/doc/uid/TP40015172-CH9-SW1
 


-- E

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Sampling collections

[Milos Rankovic via swift-users]

> On 10 Apr 2016, at 21:23, Erica Sadun  wrote:
> 
> I do not think it's the role of a core language to worry about things like 
> distributions, bias, and sampling.

Why do you mention “the role of a core language” here? That was explicitly not 
the ambition of my question. I’m talking about extending the Standard Library 
types and protocols in the Foundation framework (as this is already done on a 
large scale). Or, if this is what you mean by “core language”, how does 
capitalising strings according to the rules of grammar of every language on the 
planet qualify as any more fitting the domain of the core language?

milos

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Sampling collections

[Milos Rankovic via swift-users]

Thank you, Jens, for your response. 

I do however disagree with both points you are making. First, you write that 
sampling collection elements at random is:

> a pretty obscure feature


But how can this be? When you teach students how to implement a card playing 
game in Swift, how do you shuffle the deck? And when you test your code, do you 
not feed your methods with randomly generated and sampled simulated data, or do 
so at random intervals? And when you’re simply checking out an idea in the 
playground, do you not want randomly sampled or reshuffled inputs? Should any 
of these activities qualify as obscure?

As for:

> I don’t understand the comparison with capitalizedString; this works after 
> importing Foundation because...


Indeed, nothing after that “because” would help understand what I meant by the 
comparison. It is the fact of the import that I was trying to highlight. That 
`Foundation` extends fundamental Standard Library types and protocols (like 
`String` in this case). The ObjC–Swift bridge is relevant here only in the 
sense that I would also like sampling methods added to `NSArray`, `NSSet` or 
`NSDictionary`...

At present, when we need a source of random bits on Apple’s platforms, we dip 
into `Darwin` or `GameplayKit` frameworks. This is fine, and even if it wasn’t, 
it is unlikely to change (even when new RNG algorithms get introduced). 

What I would personally like to see, however (and what I was wondering the 
community feels about), is that one of these frameworks extends Standard 
Library data types and protocols with this functionality, which most of us gets 
the taste of right with our first encounters with computer programming and 
which we continue to rely on throughout our careers.

milos

> On 10 Apr 2016, at 17:33, Jens Alfke  wrote:
> 
> It sounds like you’re suggesting that a “sample” property (that returns a 
> randomly chosen element) should be added to the standard library? You could 
> suggest that on the swift-evolution list, though IMHO it seems like a pretty 
> obscure feature that not many users would need.
> 
> I don’t understand the comparison with capitalizedString; this works after 
> importing Foundation because of the bridging between String and NSString, 
> which is an artifact of the Mac/iOS Swift 2.x’s dependency on the Cocoa 
> frameworks.
> 
> —Jens
> 
>> In the playground:
>> 
>> "works?".capitalizedString // error: value of type 'String' has no 
>> member 'capitalizedString'
>> 
>> … but:
>> 
>> import Foundation
>> “works!”.capitalizedString // “Works!” 
>> 
>> Would it not be nice if all the following likewise worked:
>> 
>> import Foundation
>> 
>> (1..<4).sample
>> [1,2,3].sample
>> "abc".characters.sample
>> ["a": 1, "b": 2, "c": 3].sample
>> 
>> Like so many users of Swift, I have extensions 
>>  of IntegerType, ClosedInterval 
>> and CollectionType that avail me of the above methods and their family, but 
>> I’d much rather if such extensions came with Darwin or at least Foundation.
>> 
>> milos

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

[swift-users] Sampling collections

[Milos Rankovic via swift-users]

In the playground:

"works?".capitalizedString // error: value of type 'String' has no member 
'capitalizedString'

… but:

import Foundation
“works!”.capitalizedString // “Works!” 

Would it not be nice if all the following likewise worked:

import Foundation

(1..<4).sample
[1,2,3].sample
"abc".characters.sample
["a": 1, "b": 2, "c": 3].sample

Like so many users of Swift, I have extensions 
 of IntegerType, ClosedInterval 
and CollectionType that avail me of the above methods and their family, but I’d 
much rather if such extensions came with Darwin or at least Foundation.

milos

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users