Re: [swift-users] Incorrect Fisher-Yates shuffle in example code

[Saagar Jha via swift-users]

Saagar Jha

> On Dec 17, 2017, at 22:24, Nevin Brackett-Rozinsky via swift-users 
>  wrote:
> 
> …well that was more complicated than I anticipated.
> 
> The “random” function was (Int) -> Int, so when I removed the “IndexDistance 
> == Int” constraint on “shuffle” I either had to add several “numericCast” 
> calls or make “random” generic.
> 
> So I made “random” generic. And also fixed the modulo bias issue in the Glibc 
> version that Saagar mentioned. Or at least I hope I did. I haven’t tested 
> that part (nor any of the non-Swift-4 / non-macOS parts). Also, I am not sure 
> why “random” had been a closure value stored in a “let” constant, but I 
> changed it to a function.

Great! I'll close my pull request, then.

> 
> While I was at it, I removed the random-access constraint I had placed on 
> “shuffle”. It will now shuffle any MutableCollection, with complexity O(n) 
> for a RandomAccessCollection and O(n²) otherwise. (The constraint was 
> different in different Swift versions, so the entire extension had to be 
> duplicated. Without the constraint the implementation is much sleeker.)
> 
> Nevin
> 
> 
> On Sun, Dec 17, 2017 at 9:26 PM, Nevin Brackett-Rozinsky 
> > 
> wrote:
> On Sun, Dec 17, 2017 at 7:37 PM, Dave Abrahams  > wrote:
> 
>> On Dec 16, 2017, at 4:34 PM, Nevin Brackett-Rozinsky via swift-users 
>> > wrote:
>> 
>> public extension MutableCollection where Self: RandomAccessCollection, 
>> IndexDistance == Int {
> 
> IndexDistance == Int is an over-constraint, FWIW.  Adding it is generally a 
> mistake.  Not a serious one, but it does limit utility somewhat.
> 
> HTH,
> Dave
> 
> You are correct, however there is an accepted-and-implemented proposal 
> (SE–0191 
> )
>  to eliminate IndexDistance and replace it with Int, so the constraint will 
> always be satisfied starting in Swift 4.1.
> 
> I wrote a version of shuffle() without that constraint, but it is less 
> elegant: the line “for n in 0 ..< count - 1” no longer compiles, and writing 
> “0 as IndexDistance” doesn’t fix it because the resulting Range is not a 
> Sequence, since IndexDistance.Stride does not conform to SignedInteger (at 
> least in Swift 4.0 according to Xcode 9.2).
> 
> A while loop works of course, though a direct conversion requires writing 
> “var n = 0 as IndexDistance” before the loop. Luckily, with a bit of 
> cleverness we can eliminate all mention of IndexDistance, and this time we 
> really and truly don’t need the “guard !isEmpty” line:
> 
> extension MutableCollection where Self: RandomAccessCollection {
> mutating func shuffle() {
> var n = count
> while n > 1 {
> let i = index(startIndex, offsetBy: count - n)
> let j = index(i, offsetBy: random(n))
> n -= 1
> swapAt(i, j)
> }
> }
> }
> 
> Essentially, the constraint is there to make the code nicer on pre-4.1 
> versions of Swift, though I’m happy to remove it if you think that’s better. 
> If nothing else, removing the constraint means people reading the example 
> code in the future won’t be misled into thinking they need to use it 
> themselves, so perhaps it should go just on that account.
> 
> Okay, you’ve convinced me, I’ll update the PR. :-)
> 
> Nevin
> 
> ___
> 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] Incorrect Fisher-Yates shuffle in example code

[Nevin Brackett-Rozinsky via swift-users]

…well that was more complicated than I anticipated.

The “random” function was (Int) -> Int, so when I removed the
“IndexDistance == Int” constraint on “shuffle” I either had to add several
“numericCast” calls or make “random” generic.

So I made “random” generic. And also fixed the modulo bias issue in the
Glibc version that Saagar mentioned. Or at least I hope I did. I haven’t
tested that part (nor any of the non-Swift-4 / non-macOS parts). Also, I am
not sure why “random” had been a closure value stored in a “let” constant,
but I changed it to a function.

While I was at it, I removed the random-access constraint I had placed on
“shuffle”. It will now shuffle any MutableCollection, with complexity O(n)
for a RandomAccessCollection and O(n²) otherwise. (The constraint was
different in different Swift versions, so the entire extension had to be
duplicated. Without the constraint the implementation is much sleeker.)

Nevin


On Sun, Dec 17, 2017 at 9:26 PM, Nevin Brackett-Rozinsky <
nevin.brackettrozin...@gmail.com> wrote:

> On Sun, Dec 17, 2017 at 7:37 PM, Dave Abrahams 
> wrote:
>
>>
>> On Dec 16, 2017, at 4:34 PM, Nevin Brackett-Rozinsky via swift-users <
>> swift-users@swift.org> wrote:
>>
>> public extension MutableCollection where Self: RandomAccessCollection,
>> IndexDistance == Int {
>>
>>
>> IndexDistance == Int is an over-constraint, FWIW.  Adding it is generally
>> a mistake.  Not a serious one, but it does limit utility somewhat.
>>
>> HTH,
>> Dave
>>
>
> You are correct, however there is an accepted-and-implemented proposal (
> SE–0191
> )
> to eliminate IndexDistance and replace it with Int, so the constraint will
> always be satisfied starting in Swift 4.1.
>
> I wrote a version of shuffle() without that constraint, but it is less
> elegant: the line “for n in 0 ..< count - 1” no longer compiles, and
> writing “0 as IndexDistance” doesn’t fix it because the resulting Range is
> not a Sequence, since IndexDistance.Stride does not conform to
> SignedInteger (at least in Swift 4.0 according to Xcode 9.2).
>
> A while loop works of course, though a direct conversion requires writing
> “var n = 0 as IndexDistance” before the loop. Luckily, with a bit of
> cleverness we can eliminate all mention of IndexDistance, and this time we
> really and truly don’t need the “guard !isEmpty” line:
>
> extension MutableCollection where Self: RandomAccessCollection {
> mutating func shuffle() {
> var n = count
> while n > 1 {
> let i = index(startIndex, offsetBy: count - n)
> let j = index(i, offsetBy: random(n))
> n -= 1
> swapAt(i, j)
> }
> }
> }
>
> Essentially, the constraint is there to make the code nicer on pre-4.1
> versions of Swift, though I’m happy to remove it if you think that’s
> better. If nothing else, removing the constraint means people reading the
> example code in the future won’t be misled into thinking they need to use
> it themselves, so perhaps it should go just on that account.
>
> Okay, you’ve convinced me, I’ll update the PR. :-)
>
> Nevin
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Compiler fLag to activate SE-0143 (conditional conformance)?

[Slava Pestov via swift-users]

> On Dec 14, 2017, at 7:42 PM, Dave Abrahams  wrote:
> 
> IMO it makes as much sense to mention the flag in the proposal as it does to 
> point at a proof-of-concept implementation that accompanies a proposal. 
> Generally we only accept proposals that “have an implementation” these days.  

I believe the proposal was accepted before the rule came into effect.

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

Re: [swift-users] Incorrect Fisher-Yates shuffle in example code

[Nevin Brackett-Rozinsky via swift-users]

On Sun, Dec 17, 2017 at 7:37 PM, Dave Abrahams  wrote:

>
> On Dec 16, 2017, at 4:34 PM, Nevin Brackett-Rozinsky via swift-users <
> swift-users@swift.org> wrote:
>
> public extension MutableCollection where Self: RandomAccessCollection,
> IndexDistance == Int {
>
>
> IndexDistance == Int is an over-constraint, FWIW.  Adding it is generally
> a mistake.  Not a serious one, but it does limit utility somewhat.
>
> HTH,
> Dave
>

You are correct, however there is an accepted-and-implemented proposal (
SE–0191
)
to eliminate IndexDistance and replace it with Int, so the constraint will
always be satisfied starting in Swift 4.1.

I wrote a version of shuffle() without that constraint, but it is less
elegant: the line “for n in 0 ..< count - 1” no longer compiles, and
writing “0 as IndexDistance” doesn’t fix it because the resulting Range is
not a Sequence, since IndexDistance.Stride does not conform to
SignedInteger (at least in Swift 4.0 according to Xcode 9.2).

A while loop works of course, though a direct conversion requires writing
“var n = 0 as IndexDistance” before the loop. Luckily, with a bit of
cleverness we can eliminate all mention of IndexDistance, and this time we
really and truly don’t need the “guard !isEmpty” line:

extension MutableCollection where Self: RandomAccessCollection {
mutating func shuffle() {
var n = count
while n > 1 {
let i = index(startIndex, offsetBy: count - n)
let j = index(i, offsetBy: random(n))
n -= 1
swapAt(i, j)
}
}
}

Essentially, the constraint is there to make the code nicer on pre-4.1
versions of Swift, though I’m happy to remove it if you think that’s
better. If nothing else, removing the constraint means people reading the
example code in the future won’t be misled into thinking they need to use
it themselves, so perhaps it should go just on that account.

Okay, you’ve convinced me, I’ll update the PR. :-)

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

[swift-users] TWISt-shout Newsletter 2017-12-18

[Kenny Leung via swift-users]

Hi All.

Here is your TWISt-shout Newsletter for the week of 2017-12-11 to 2017-12-17

https://github.com/pepperdog/TWISt-shout/blob/master/2017/TWISt-shout-2017-12-18.md
 


Enjoy!

-Kenny




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

Re: [swift-users] Incorrect Fisher-Yates shuffle in example code

[Dave Abrahams via swift-users]

> On Dec 16, 2017, at 4:34 PM, Nevin Brackett-Rozinsky via swift-users 
>  wrote:
> 
> public extension MutableCollection where Self: RandomAccessCollection, 
> IndexDistance == Int {
> 

IndexDistance == Int is an over-constraint, FWIW.  Adding it is generally a 
mistake.  Not a serious one, but it does limit utility somewhat.

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

Re: [swift-users] A problem about interact with C macros

[Geordie Jay via swift-users]

Thinking about this a bit more:

Imagine you imported another header later that “#undef SITUATION2” and then
redefined it with a different value. The fact that SITUATIONALL is an
expression and not a value would then produce a different result. For some
this would be expected and for others a debugging nightmare. Since there is
no “right” answer, I’d say macro expressions like this will never be
imported by Swift.

- Geordie
Geordie Jay via swift-users  schrieb am So. 17. Dez.
2017 um 14:40:

> I think this is because the C preprocessor will interpret SITUATIONALL not
> as a value but as an expression. That means your C code at that spot will
> be turned into “(SITUATION1 | SITUATION2 | etc)” and not into the result of
> that expression directly.
>
> The clang importer could probably figure this out, but I suspect there are
> diminishing returns in figuring out what really is a constant as opposed to
> another expression etc. Especially in this example, the inconvenience of
> defining your own SITUATIONALL in Swift is likely lower than the
> inconvenience of that where the macro expression imports incorrectly and
> does unexpected things.
>
> Please (anyone) correct me if I’m wrong here though, I’d like to know the
> definitive answer myself.
>
> - Geordie
>
> Li Keqing via swift-users  schrieb am So. 17. Dez.
> 2017 um 13:08:
>
>> Here are some macros in C headers such as
>>
>> #define SITUATION1 0x0001
>> #define SITUATION1 0x0002
>> #define SITUATION3 0x0004
>> #define SITUATION4 0x0008
>> #define SITUATIONALL (SITUATION1 | SITUATION2 | SITUATION3 | SITUATION4)
>>
>> when use these value in swift
>> those lines are okay
>> let value1 = SITUATION1
>> let value2 = SITUATION2
>> let value3 = SITUATION3
>> let value4 = SITUATION4
>> but this line would show error
>> let valueAll = SITUATIONALL
>>
>>  Is it a bug ? or just be designed as it?
>> ___
>> 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
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] A problem about interact with C macros

[Geordie Jay via swift-users]

I think this is because the C preprocessor will interpret SITUATIONALL not
as a value but as an expression. That means your C code at that spot will
be turned into “(SITUATION1 | SITUATION2 | etc)” and not into the result of
that expression directly.

The clang importer could probably figure this out, but I suspect there are
diminishing returns in figuring out what really is a constant as opposed to
another expression etc. Especially in this example, the inconvenience of
defining your own SITUATIONALL in Swift is likely lower than the
inconvenience of that where the macro expression imports incorrectly and
does unexpected things.

Please (anyone) correct me if I’m wrong here though, I’d like to know the
definitive answer myself.

- Geordie

Li Keqing via swift-users  schrieb am So. 17. Dez.
2017 um 13:08:

> Here are some macros in C headers such as
>
> #define SITUATION1 0x0001
> #define SITUATION1 0x0002
> #define SITUATION3 0x0004
> #define SITUATION4 0x0008
> #define SITUATIONALL (SITUATION1 | SITUATION2 | SITUATION3 | SITUATION4)
>
> when use these value in swift
> those lines are okay
> let value1 = SITUATION1
> let value2 = SITUATION2
> let value3 = SITUATION3
> let value4 = SITUATION4
> but this line would show error
> let valueAll = SITUATIONALL
>
>  Is it a bug ? or just be designed as it?
> ___
> 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

[swift-users] A problem about interact with C macros

[Li Keqing via swift-users]

Here are some macros in C headers such as

#define SITUATION1 0x0001
#define SITUATION1 0x0002
#define SITUATION3 0x0004
#define SITUATION4 0x0008
#define SITUATIONALL (SITUATION1 | SITUATION2 | SITUATION3 | SITUATION4)

when use these value in swift
those lines are okay
let value1 = SITUATION1
let value2 = SITUATION2
let value3 = SITUATION3
let value4 = SITUATION4
but this line would show error
let valueAll = SITUATIONALL

 Is it a bug ? or just be designed as it?___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users