Re: [swift-dev] Rationalizing FloatingPoint conformance to Equatable

[Jonathan Hull via swift-dev]

> On Oct 26, 2017, at 11:44 PM, Xiaodi Wu  wrote:
> 
> On Fri, Oct 27, 2017 at 1:30 AM, Jonathan Hull  > wrote:
> One completely different idea, which I brought up a year or so ago, is to do 
> what we do with pointers around this.  That is you have your fast/unsafe IEEE 
> Floats/Doubles/etc that have a scarier name.  These do not conform to 
> Equatable or Comparable, but have their own version of IEEE 
> equality/comparison. Let’s spell it &== and &< to make it feel different so 
> the users consider the possibility of NaN.  They don’t have any notion of 
> hashability.
> 
> As I wrote in my reply to Greg, IEEE equality and comparison is _the_ best 
> approximation of mathematical equality and comparison suitable for 
> floating-point types. If another one were superior, then floating-point 
> experts would have designated that as the standard.

We definitely have different world views.  I see the handling of NaN as a 
legacy/compatibility issue due to committee/vendor politics from the 1980’s.  I 
am pretty sure if they could do it over with modern tech, we would just have 
isNan() and NaN == NaN… or we might just have optionals instead.

Just to play devil’s advocate, there are actually much better and more accurate 
representations available using the same number of bits.  The main issue is 
that there isn’t common hardware support for them.  That is not what I am 
suggesting here however.
 

> Swift correctly exposes only one concept of equality for floating-point 
> types. It is and should be IEEE equality. People should be encouraged and not 
> scared to use it. NaN is and should continue to exist as a concept. Yes, 
> IEEE-compliant floating point is hard; the only thing harder than 
> IEEE-compliant floating point is non-IEEE-compliant floating point.

What I am suggesting is identical to IEEE in every way except for NaN.  It is 
just an IEEE value that has been filtered so that we can guarantee it isn’t 
NaN. It still uses all the same hardware instructions.  Basically, it 
semantically converts NaN to nil… and that lets us conform to 
Equatable/Comparable honestly.  It also still technically adheres to IEEE… it 
just never comes up because we are careful to filter/handle NaN before the user 
ever has to deal with it.

If you want/need to use NaN for some reason, you still have the IEEE types. 
What you can’t do is use them generically for ==.

Can you give me an example of where you would want NaN in a generic context 
(that might also contain Ints), but an optional Float (which had been filtered 
not to have NaN) wouldn’t meet your needs?  Remember, this is a generic 
context, not one that is special casing Floats.


> This thread is meant to discuss how to reconcile this scenario with the 
> semantics of Equatable.

Yes it is… and this is one possible approach to doing it.  We make it so Floats 
just don’t conform to Equatable, but we make a wrapper type that does conform 
(and can fully meet the guarantees).


> 
> Then you have your safe/friendly Swift Floating point type(s) which just have 
> no concept of NaN at all (and probably a single notion of zero). You have a 
> failable initializer from the IEEE versions. These types conform to 
> Equatable/Hashable/Comparable.  Care is taken with internal methods so that 
> NaN can’t creep into the type.
> 
> How do we handle math functions which might fail?  We do the same thing we do 
> in the rest of Swift... those functions return an optional.
> 
> When reading in data from the outside world or C code, you would use the IEEE 
> versions and then either convert or do your calculations directly.  They 
> would probably also be used for things like accelerate.  But most code, where 
> the values come from user input or literals, would never even have to touch 
> the IEEE version.
> 
> The advantage here is that you get full speed all the time, even in generic 
> contexts.  You just can’t use the IEEE versions directly in generic contexts. 
> You would have to convert them, which is a one-time cost (or use them 
> non-generically).
> 
> Again, generics and protocol-based numerics are important; that's what 
> Numeric is all about. Any idea that doesn't make this possible is a 
> non-starter.
> 

Why is everything “impossible” or a “non-starter”?  

The wrapper version would adhere to Numeric and would be fully usable in 
generic contexts.  You can wrap the IEEE Floats, and the NaNs get converted to 
optionals, where you can apply the generic algorithm.  If your “generic” 
algorithm was depending on the bit representation of NaN or the fact that it 
breaks ==, then I would argue you really don’t want a generic algorithm after 
all… you have a Float specific algorithm.

Also, in terms of speed, we should find something with the semantics we want 
(that should be the main focus of our discussion)… and then we can figure out 
how to tweak it so it goes as fast as we need it to once we know what we are 
aiming for.  Anything e

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - Ubuntu 14.04 (master) #1315

[Xi Ge via swift-dev]

The following builds are fine.

--
Xi



> On Oct 26, 2017, at 11:44 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-14_04 [#1315]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-14_04/1315/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-14_04
> Date of build:Fri, 27 Oct 2017 00:52:20 -0500
> Build duration:   53 min
> Identified problems:
> 
> Regression test failed: This build failed because a regression test in the 
> test suite FAILed. Below is a list of all errors:
> Indication 1 
> 
> Compile Error: This build failed because of a compile error. Below is a list 
> of all errors in the build log:
> Indication 1 
> 
> Changes
> 
> Commit a0c014698d527f603404f5ae6622538785bbd701 by spestov:
> Re-organize multi-file tests a bit
> 
> add: test/multifile/error-type/imported/Inputs/library.swift
> add: test/multifile/constant-tuple-with-padding/Inputs/other.swift
> delete: test/multifile/synthesized-accessors/one-module-imported/library.swift
> delete: test/multifile/error-type/one-module/library.swift
> add: test/multifile/error-type/two-modules/Inputs/library.swift
> add: 
> test/multifile/synthesized-accessors/one-module-imported/Inputs/library.swift
> delete: test/multifile/synthesized-accessors/one-module-public/library.swift
> add: test/multifile/error-type/imported/Inputs/objc_enum_errortype.h
> delete: test/multifile/typealias/two-modules/library.swift
> add: test/multifile/extensions/two-modules/Inputs/library.swift
> delete: test/multifile/error-type/imported/library.swift
> add: test/multifile/synthesized-accessors/two-modules/Inputs/library.swift
> delete: test/multifile/imported-conformance/option-set/library.swift
> edit: test/multifile/synthesized-accessors/one-module-imported/main.swift
> edit: test/multifile/constant-tuple-with-padding/main.swift
> edit: test/multifile/synthesized-accessors/one-module-internal/main.swift
> edit: test/multifile/typealias/one-module/main.swift
> delete: test/multifile/typealias/one-module/library.swift
> add: 
> test/multifile/synthesized-accessors/one-module-internal/Inputs/library.swift
> edit: test/multifile/constant-struct-with-padding/main.swift
> add: test/multifile/class-layout/final-stored-property/Inputs/library.swift
> edit: test/multifile/synthesized-accessors/two-modules/main.swift
> delete: test/multifile/error-type/imported/objc_enum_errortype.h
> edit: test/multifile/error-type/one-module/main.swift
> delete: test/multifile/synthesized-accessors/two-modules/library.swift
> add: 
> test/multifile/synthesized-accessors/one-module-public/Inputs/library.swift
> edit: test/multifile/error-type/two-modules/main.swift
> edit: test/multifile/extensions/two-modules/main.swift
> add: test/multifile/typealias/one-module/Inputs/library.swift
> delete: test/multifile/error-type/two-modules/library.swift
> add: test/multifile/error-type/one-module/Inputs/library.swift
> edit: test/multifile/synthesized-accessors/one-module-public/main.swift
> edit: test/multifile/typealias/two-modules/main.swift
> add: test/multifile/constant-struct-with-padding/Inputs/other.swift
> add: test/multifile/imported-conformance/option-set/Inputs/library.swift
> add: test/multifile/typealias/two-modules/Inputs/library.swift
> edit: test/multifile/class-layout/final-stored-property/main.swift
> delete: test/multifile/constant-tuple-with-padding/Other.swift
> add: 
> test/multifile/synthesized-accessors/two-modules-imported/Inputs/library.swift
> edit: test/multifile/synthesized-accessors/two-modules-imported/main.swift
> edit: test/multifile/imported-conformance/option-set/main.swift
> delete: test/multifile/class-layout/final-stored-property/library.swift
> delete: test/multifile/synthesized-accessors/one-module-internal/library.swift
> delete: test/multifile/constant-struct-with-padding/Other.swift
> edit: test/multifile/error-type/imported/main.swift
> delete: 
> test/multifile/synthesized-accessors/two-modules-imported/library.swift
> delete: test/multifile/extensions/two-modules/library.swift
> 
> Commit 0f2da217a4ada84f0b447aba24ea60dc8503ded0 by spestov:
> Sema: Fix some issues with overrides of materializeForSet
> 
> add: 
> test/multifile/synthesized-accessors/materialize-for-set-2/Inputs/library1.swift
> edit: lib/Sema/TypeCheckDecl.cpp
> add: test/multifile/synthesized-accessors/materialize-for-set-2/main.swift
> edit: lib/AST/ASTVerifier.cpp
> add: test/multifile/synthesized-accessors/materialize-for-set-1/main.swift
> add: 
> test/multifile/synthesized-accessors/materialize-for-set-2/Inputs/library2.swift
> add: 
> test/multifile/synth

Re: [swift-dev] Rationalizing FloatingPoint conformance to Equatable

[David Sweeris via swift-dev]

> On Oct 27, 2017, at 3:06 AM, Jonathan Hull via swift-dev 
>  wrote:
> 
>> 
>> On Oct 26, 2017, at 11:44 PM, Xiaodi Wu > > wrote:
>> 
>> On Fri, Oct 27, 2017 at 1:30 AM, Jonathan Hull > > wrote:
>> One completely different idea, which I brought up a year or so ago, is to do 
>> what we do with pointers around this.  That is you have your fast/unsafe 
>> IEEE Floats/Doubles/etc that have a scarier name.  These do not conform to 
>> Equatable or Comparable, but have their own version of IEEE 
>> equality/comparison. Let’s spell it &== and &< to make it feel different so 
>> the users consider the possibility of NaN.  They don’t have any notion of 
>> hashability.
>> 
>> As I wrote in my reply to Greg, IEEE equality and comparison is _the_ best 
>> approximation of mathematical equality and comparison suitable for 
>> floating-point types. If another one were superior, then floating-point 
>> experts would have designated that as the standard.
> 
> We definitely have different world views.  I see the handling of NaN as a 
> legacy/compatibility issue due to committee/vendor politics from the 1980’s.  
> I am pretty sure if they could do it over with modern tech, we would just 
> have isNan() and NaN == NaN… or we might just have optionals instead.

For a sufficiently non-mathematical definition of "logic"...

Logically speaking, NaN == NaN, but mathematically speaking it does not. NaN 
is, by definition, not a number, so asking if it's equal to itself or anything 
else is a mathematically meaningless question (same goes for < and >). If 
you're keeping track of why the answer is NaN, then there's at least a basis 
for discussing the matter... like in `1.0 == sin(x)/x`, where x is 0... Well, 
0/0 is classic example of an undefined result, but the limit of sin(x)/x as x 
approaches 0 does equal 1, so in some sense -- AFAIK a very non-rigorous sense 
-- you'd be not entirely wrong to say that `1 == sin(0)/0` could kinda sorta be 
considered to be "proximately related to `true`" or something. For `==` to know 
that, though, .nan would need to carry the relevant closure and its arguments 
as a payload so that some other bits of logic could know how we got to 0/0, and 
`==` would need in-hardware calculus to verify, in a timely manner, that the 
limit both exists and is the same from both sides (or I suppose the `/` op 
could do it... that'd save on the payload requirements, but you're still stuck 
doing calculus in hardware). Since that's prohibitively impractical, if `==` 
has to give a boolean answer, it is much more correct to say "NaN != NaN". One 
could argue that the semantics of Swift's `==` ought be closer to "matches" 
than "equals", though, which I think is what Xiaodi is getting at.

- Dave Sweeris___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - Ubuntu 16.04 (master) #1231

[Arnold via swift-dev]

Some libdispatch craziness ... not my patch.

error: Can not open file ... module.modulemap: No such file or directory

> On Oct 27, 2017, at 2:04 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_04 [#1231]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_04/1231/
> Project:  oss-swift-incremental-RA-linux-ubuntu-16_04
> Date of build:Fri, 27 Oct 2017 15:48:59 -0500
> Build duration:   16 min
> Identified problems:
> 
> Compile Error: This build failed because of a compile error. Below is a list 
> of all errors in the build log:
> Indication 1
> Tests:
> 
> Name: Swift(linux-x86_64)
> Failed: 0 test(s), Passed: 10018 test(s), Total: 10018 test(s)
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 483 test(s), Total: 483 test(s)
> 
> Changes
> 
> Commit b6f39e3132de823f3ddf51d77fd45308c039f3b4 by aschwaighofer:
> IRGen: Whe emitting a call to a builtin runtime function transfer the
> 
> edit: lib/IRGen/GenBuiltin.cpp
> 
> Commit e0646d4321ac6e3fae22ecf145c5ab9f66ce8343 by aschwaighofer:
> IRGen: Use swiftcc for swift_unexpectedError and swift_errorInMain
> 
> edit: stdlib/public/runtime/ErrorObject.h
> edit: include/swift/Runtime/RuntimeFunctions.def
> edit: test/IRGen/builtins.swift
> 
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] "For" loop iterator and "enum"

[Joe Groff via swift-dev]

> On Oct 24, 2017, at 8:32 AM, Sam Ding via swift-dev  
> wrote:
> 
> Hi,
> 
> It is found that "for" loop iterate and "enum" does not work on s390x.
> Here is a sample code:
> enum IntKey : Int {
> case a = 3
> case b = 4 // Implicitly 4
> case c = 1
> }
> for ( a1, a2) in [(IntKey.a, 1)] {
> print ("+ test \n")
> }
> 
> The for loop inifinitly iterates on s390x. Note that it works fine if 
> replacing the enum with normal tuple in the above code.
> When debugging this code, after one iteration, the logic gets a "nil" in 
> "IndexingIterator.next()" as follows:
> 
> frame #0: 0x03fffd5b4088 
> libswiftCore.so`IndexingIterator.next(self=0x03fff460) at 
> Collection.swift:411
> 408 @inline(__always)
> 409 public mutating func next() -> Elements.Element? {
> 410 if _position == _elements.endIndex {
> -> 411 return nil
> 412 }
> 413 let element = _elements[_position]
> ..
> Then comes "Enum.cpp:211" (swift::swift_storeEnumTagSinglePayload) and no 
> difference on both s390x and x86_64.
> However, It continues goes into the loop body on s390x, and terminates on 
> x86_64, respectively.
> 
> Have anyones know well this implementation and give us a hint for the 
> problems?
> 
> Thanks,
> 

At a binary level, Swift is going to represent the result of the next() 
operation as an value of the element type wrapped in an Optional, `(IntKey, 
Int)?`, and the compiler is going to recognize that it can represent the `nil` 
case by using unused representations of IntKey. Our code for doing enum layout 
was originally written in a very little-endian-centric way, and if s390x is 
big-endian, there's a possibility that the code in IRGen or the runtime that 
encodes the `nil` result is not correct, or that the runtime and IRGen do not 
agree on the representation of `nil`. That could lead to the infinite loop 
you're seeing.

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