Re: [swift-evolution] [Pitch] Angle Type

> On Jan 15, 2018, at 4:31 PM, Karl Wagner via swift-evolution > wrote: > >> On 14. Jan 2018, at 21:12, Kelvin Ma via swift-evolution >> > wrote: >> >> This could work, but you’re also giving up all the

Re: [swift-evolution] f suffix for float32 literals, h suffix for float16 literals

> On Nov 3, 2017, at 3:33 PM, Kelvin Ma wrote: > > > > On Fri, Nov 3, 2017 at 2:05 PM, Steve Canon via swift-evolution > > wrote: > If/when 16b floats were added to the standard lib, you would just write: >

Re: [swift-evolution] [Proposal] Random Unification

> On Sep 8, 2017, at 8:09 PM, Xiaodi Wu via swift-evolution > wrote: > > This topic has been broached on Swift Evolution previously. It's interesting > to me that Steve Canon is so certain that CSPRNGs are the way to go. I wasn't > aware that hardware CSPRNGs have

Re: [swift-evolution] [Proposal] Random Unification

Quick thoughts: 1. A stdlib-level random number facility should default to a host-provided CSPRNG as the generator. Anything less is really not justifiable. The throughput of modern HW-backed CSPRNGs exceeds that of all but the fastest PRNGs, anyway. 2. MT is not a CSPRNG. – Steve > On Sep

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

> On Aug 2, 2017, at 7:03 PM, Karl Wagner via swift-evolution > wrote: > > It’s important to remember that computers are mathematical machines, and some > functions which are implemented in hardware on essentially every platform > (like sin/cos/etc) are definitely

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

> On Aug 2, 2017, at 6:37 PM, Nicolas Fezans via swift-evolution > wrote: > > I am of course not talking about a syntax sugar to call a sin or cos > function, but rather to manipulate other objects such as N-dimensional > matrices, defining maths functions that can

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

> On Jul 31, 2017, at 1:29 PM, Taylor Swift via swift-evolution > wrote: > > Also squareRoot() should be moved to the Math module if it is ever created. No; square root is an IEEE-754 required basic operation, just like addition or multiplication. It is part of the

Re: [swift-evolution] floating point numbers implicit conversion

> On Jun 19, 2017, at 5:43 PM, David Sweeris <daveswee...@mac.com> wrote: > > Sent from my iPhone > On Jun 19, 2017, at 13:44, John McCall via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >>> On Jun

Re: [swift-evolution] floating point numbers implicit conversion

> On Jun 19, 2017, at 11:46 AM, Ted F.A. van Gaalen via swift-evolution > wrote: > > var result: Float = 0.0 > result = float * integer * uint8 + double > // here, all operands should be implicitly promoted to Double before the > complete expression evaluation.

Re: [swift-evolution] [pitch] Comparison Reform

On Apr 27, 2017, at 7:35 PM, Jonathan Hull via swift-evolution wrote: > I doubt we would get rid of Double/Float, but I would love to see it used as > a core type in Swift 5. Not to be discouraging, but Swift 5 is wildly ambitious for the inclusion of unum in the

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 24, 2017, at 10:06 PM, Jonathan Hull via swift-evolution > wrote: > > As I am thinking about it more, this means that for == and < > > NaN == NaN > -0 == +0 > +Inf < NaN > > Since this would break from IEEE, I think we should also consider taking the >

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 22, 2017, at 6:55 PM, Xiaodi Wu wrote: > > Yes. Specifically, in floating point code. I guess that's the part about > shaping the rug not to cover the bump. IEEE does not require `==` to be the > spelling of the quiet equality comparison operator, and it does

Re: [swift-evolution] SE-0170: NSNumber bridging and Numeric types

> On Apr 18, 2017, at 12:17 PM, Joe Groff wrote: > > >> On Apr 17, 2017, at 5:56 PM, Xiaodi Wu via swift-evolution >> wrote: >> >> It seems Float.init(exactly: NSNumber) has not been updated to behave >> similarly? >> >> I would have to say, I

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 18, 2017, at 11:40 AM, Ben Cohen via swift-evolution > wrote: > > >> On Apr 17, 2017, at 9:40 PM, Chris Lattner via swift-evolution >> > wrote: >> >> >>> On Apr 17, 2017, at 9:07 AM, Joe Groff

Re: [swift-evolution] [Discussion] What is the future of tuples in Swift?

> On Mar 3, 2017, at 7:57 AM, Adrian Zubarev via swift-evolution > wrote: > > The question here is, how is a tuple different from a mathematical vector? I > wasn’t referring to vector concepts from other languages, but used the > keyword vector to indicate a

Re: [swift-evolution] [swift-evolution-announce] [Re-Review] SE-0104: Protocol-oriented integers

> On Feb 22, 2017, at 10:48 AM, David Sweeris via swift-evolution > wrote: > > Eh, maybe… At least in Xcode, autocomplete works for free functions. I was > just thinking about how people who already know about “signum" would expect > it to work. Like if a

Re: [swift-evolution] Basic element-wise operator set for Arrays, Arrays of Arrays, etc.

> On Feb 17, 2017, at 10:51 AM, Xiaodi Wu via swift-evolution > wrote: > > There's nothing, afaik, which stands in the way of that syntax today. The > proposal is to extend the standard library to add syntax for a math library. > The idea of having a core math

Re: [swift-evolution] protocol-oriented integers (take 2)

It’s (a) the inverse operation of doubleWidthMultiply. (b) an important building block for fast “small bignum arithmetic” (2-16 ish words). If you have this operation, it’s easy to build the divide that does DoubleWidth / DoubleWidth. (c) the widest divide operation that maps reasonably cleanly

Re: [swift-evolution] protocol-oriented integers (take 2)

The bitwise stuff isn't on ArithMETic | ARITHmetic | Number | whatever. > On Jan 27, 2017, at 9:13 AM, T.J. Usiyan via swift-evolution > wrote: > > Regarding `Number` or `Numeric`: Does everything in Arithmetic apply to > complex numbers and do we want it to? The

Re: [swift-evolution] protocol-oriented integers (take 2)

> On Jan 25, 2017, at 1:58 PM, David Sweeris via swift-evolution > wrote: > > >> On Jan 25, 2017, at 07:59, Anton Mironov via swift-evolution >> wrote: >> >> Hi everyone, >> >> I want to suggest a tiny extension to an Arithmetic

Re: [swift-evolution] protocol-oriented integers (take 2)

> On Jan 16, 2017, at 3:25 AM, Xiaodi Wu via swift-evolution > wrote: > > Unless I'm mistaken, after removing division, models of SignedArithmetic > would have the mathematical properties of a ring. For every element a in ring > R, there must exist an additive

Re: [swift-evolution] protocol-oriented integers (take 2)

Responding to the thread in general here, not so much any specific email: “Arithmetic” at present is not a mathematically-precise concept, and it may be a mistake to make it be one[1]; it’s a mathematically-slightly-fuzzy “number” protocol. FWIW, if I had to pick a mathematical object to pin it

Re: [swift-evolution] protocol-oriented integers (take 2)

> On Jan 14, 2017, at 11:18 AM, Xiaodi Wu wrote: > > On Fri, Jan 13, 2017 at 7:51 PM, Xiaodi Wu > wrote: > Thanks, that's very helpful. Yes, my question was more directed to those > situations that can't be optimized

Re: [swift-evolution] protocol-oriented integers (take 2)

> On Jan 13, 2017, at 5:14 PM, Xiaodi Wu via swift-evolution > wrote: > > [Resending to list with original message removed for length.] > > This is fantastic. Glad to see it take shape. Very neat and insightful to > have trailingZeros on BinaryInteger but

Re: [swift-evolution] Symmetrical operators

> On Nov 16, 2016, at 10:47 AM, David Sweeris via swift-evolution > > wrote: > >> >> On Nov 16, 2016, at 9:25 AM, Karl via swift-evolution >> > wrote: >> >> >>> On 14

Re: [swift-evolution] Contiguous Memory and the Effect of Borrowing on Safety

> On Nov 10, 2016, at 1:30 PM, Dave Abrahams via swift-evolution > wrote: > > > on Thu Nov 10 2016, Joe Groff wrote: > >>> On Nov 8, 2016, at 9:29 AM, John McCall wrote: >>> On Nov 8, 2016, at 7:44 AM, Joe Groff via swift-evolution

Re: [swift-evolution] [Discussion] Breaking precedence

> On Aug 2, 2016, at 12:18 AM, Félix Cloutier via swift-evolution > wrote: > > I disagree. The binary operators have properties that are comparable to > arithmetic operators, and their precedence is easy to define as such. & has > multiplication-like properties

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> The point of this design is that `===` means identity and that `.same ` > also means identity. > > Since this is new territory I suppose we get to decide what identity > means for floating point. Should +0 and -0 have the same identity or > not? I’ll leave the answer to folks more

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 6:55 PM, Matthew Johnson wrote: > >> On Jul 22, 2016, at 5:50 PM, Stephen Canon > > wrote: >> >>> On Jul 22, 2016, at 6:34 PM, Matthew Johnson via swift-evolution >>>

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 6:34 PM, Matthew Johnson via swift-evolution > wrote: > > Sorry if it wasn’t clear. I’m not suggesting taking that away. I’m asking > whether we have considered defining `==` on floating point types to be the > equivalence relation that is

Re: [swift-evolution] [pitch] remove global sqrt

> On Jul 11, 2016, at 6:55 PM, Chris Lattner wrote: > > On Jul 11, 2016, at 3:52 PM, Stephen Canon wrote: I would also plan to provide this and other math.h-ish globals in a future (post swift 3) Math module. >>> >>> I’m very concerned with

Re: [swift-evolution] [pitch] remove global sqrt

> On Jul 11, 2016, at 6:42 PM, Chris Lattner <clatt...@apple.com> wrote: > > >> On Jul 11, 2016, at 2:28 PM, Stephen Canon via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Post SE-0067 FloatingPoint provides the usual global opera

Re: [swift-evolution] [pitch] remove global sqrt

areRoot()` as >>> a method. >>> >>> I don’t necessarily care if these functions are in the global namespace, or >>> if they’re imported from a `Math` module. I’m also not convinced that they >>> should be part of the core FloatingPoint prot

Re: [swift-evolution] [pitch] remove global sqrt

and vetted, it would form an excellent base for proposing a math module once Swift 3 closes down. – Steve > On Jul 11, 2016, at 6:13 PM, Stephen Canon via swift-evolution > <swift-evolution@swift.org> wrote: > > It wouldn’t delay code intended to operate generically at all. Th

Re: [swift-evolution] [pitch] remove global sqrt

> should be part of the core FloatingPoint protocol. `sqrt` probably should > be, but the trig functions would naturally fit together in a protocol that > itself conforms to FloatingPoint. > >> On Jul 11, 2016, at 14:28 , Stephen Canon via swift-evolution >> <swift-

[swift-evolution] [pitch] remove global sqrt

Post SE-0067 FloatingPoint provides the usual global operators, as well as a single global function: func sqrt(_: T) -> T It seems out of place and lonely, and it would be nice if we can keep the default members of the global namespace to a minimum. I’d like to suggest removing this

Re: [swift-evolution] Besides pi, include also e as a builtin mathematical constant into floats

> On Jul 1, 2016, at 2:33 PM, David Waite via swift-evolution > wrote: > > That only is about tau, which is a much more controversial operator. > Unfortunately, I wasn’t able to find the discussion of pi or E in the > archives (but neither pi nor e are very

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0113: Add integral rounding functions to FloatingPoint

> On Jul 1, 2016, at 1:20 PM, Erica Sadun <er...@ericasadun.com> wrote: > > >> On Jul 1, 2016, at 11:13 AM, Stephen Canon via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> On Jul 1, 2016, a

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0113: Add integral rounding functions to FloatingPoint

> On Jul 1, 2016, at 1:11 PM, Jordan Rose via swift-evolution > wrote: > > [Proposal: > https://github.com/apple/swift-evolution/blob/master/proposals/0113-rounding-functions-on-floatingpoint.md > >

Re: [swift-evolution] [Review] SE-0113: Add integral rounding functions to FloatingPoint

> On Jul 1, 2016, at 1:14 PM, Karl via swift-evolution > wrote: > > >> On 1 Jul 2016, at 13:44, Joseph Lord via swift-evolution >> wrote: >> >> >>> The review of "SE-0113: Add integral rounding functions to FloatingPoint" >>> begins

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

These are already included with SE-0067, we’re just working on finishing up the implementation. /// Remainder of `self` divided by `other`. This is the IEEE 754 remainder /// operation. /// /// For finite `self` and `other`, the remainder `r` is defined by /// `r = self - other*n`,

Re: [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines

On Jun 30, 2016, at 9:12 PM, Dave Abrahams via swift-evolution wrote: > I don't believe that “stride” *is* the accepted term of art for this > meaning. I never heard of the idea of types having an intrinsic > “stride” until I arrived on the Swift project. That usage

Re: [swift-evolution] [Review] SE-0113: Add integral rounding functions to FloatingPoint

> On Jul 1, 2016, at 7:44 AM, Joseph Lord via swift-evolution > wrote: > > >> The review of "SE-0113: Add integral rounding functions to FloatingPoint" >> begins now and runs through July 5. The proposal is available here: >> >> >>

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

> On Jun 29, 2016, at 1:10 PM, Matthew Johnson wrote: > > My criticism of the 'toNearestOrGreatest' still stands though. I think this > name is misleading given the stated semantics. The name indicates "greater > value" not "greater magnitude" which are opposites in

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

> On Jun 29, 2016, at 1:00 PM, Stephen Canon wrote: > > >> On Jun 29, 2016, at 12:46 PM, Matthew Johnson > > wrote: >> >> +1 to adding robust rounding to he standard library. >> >> I’m curious why we have both `up`

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

> On Jun 29, 2016, at 12:46 PM, Matthew Johnson wrote: > > +1 to adding robust rounding to he standard library. > > I’m curious why we have both `up` and `down`, but only have `towardZero` > without `awayFromZero`. > > I’m also curious what the use case is for

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

On Jun 29, 2016, at 9:33 AM, David Sweeris wrote: > Types where it makes sense, or types for which such semantics would be a good > idea? Because, for example, you could do something like this: > struct HTMLParser : IntegerLiteralConvertible { > init(integerLiteral

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

> On Jun 27, 2016, at 3:34 PM, Saagar Jha wrote: > > Seems fine to me. One addition though: some sort of round(withPrecision: Int) I noted in another post on this thread that this doesn’t actually make any sense for FloatingPoint. I’ll flesh that out here for

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

> On Jun 27, 2016, at 12:34 PM, Karl wrote: > > >> On 27 Jun 2016, at 16:23, Stephen Canon > > wrote: >> >> >>> On Jun 25, 2016, at 05:06, Karl via swift-evolution >>>

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

> On Jun 26, 2016, at 6:38 PM, Károly Lőrentey via swift-evolution > wrote: > > I’m not sure if this has been mentioned yet, but the semantics of Integer > operations also needs to be tied down. In particular, the expected behavior > of the remainder operation (in

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

> On Jun 25, 2016, at 05:06, Karl via swift-evolution > > wrote: > >> Proposal: https://gist.github.com/karwa/273db66cd8a5fe2c388ccc7de9c4cf31 >> Karl, thanks for

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

> On Jun 24, 2016, at 2:52 PM, Haravikk via swift-evolution > wrote: > > >> On 24 Jun 2016, at 18:17, Károly Lőrentey via swift-evolution >> wrote: >> I’m especially stoked about `FixedWidthInteger.doubleWidthMultiply`, which >> will

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

On Jun 23, 2016, at 2:23 AM, Félix Cloutier via swift-evolution wrote: > Is there a way to get an optional initializer that returns `nil` if the > operand can't be represented? That’s in the Arithmetic Protocol in the proposal: /// Initializes to the value of

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

On Jun 23, 2016, at 2:23 AM, Félix Cloutier via swift-evolution wrote: > Do we lose the ability to create a signed integer from an unsigned bit > pattern? The existing `init(bitPattern x: UIntN)` are still present on the concrete types in the prototype. There’s a

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

> On Jun 23, 2016, at 2:23 AM, Félix Cloutier via swift-evolution > wrote: > > What is the cost of heterogeneous comparison? Smaller-than-wordsize comparisons will fall out for free in most cases. For word size and larger types, there’s one extra test in some

Re: [swift-evolution] Thoughts on clarity of Double and Float type names?

On Jun 20, 2016, at 7:22 AM, Ben Rimmington via swift-evolution wrote: > DEC64 > as the default number type! At some danger of going off on a tangent, I should point out that DEC64 has very little to recommend it. It’s not much

Re: [swift-evolution] Add max/min to floating point types

> On Jun 10, 2016, at 5:20 PM, Darren Mo wrote: > >> – They’re not actually the maximum and minimum values of the type. In >> particular, that `max(Float.infinity, .max)` wouldn’t be `Float.max` is >> pretty seriously confusing. > > Infinity is a special value. I would

Re: [swift-evolution] Thoughts on clarity of Double and Float type names?

[Charlie, this is more of a reply to the thread than to your message in particular.] There is absolutely no good reason to have a “word size” floating-point type. We happen to have one on Apple systems (CGFloat), but that should be viewed as a historical curiosity, not as guidance that it’s a

Re: [swift-evolution] unums in Swift?

What do you find interesting about them? I haven’t spent more than a few hours reading about them (and the definition of “unum” seems to be a moving target, so I’m not sure that it would have been useful to study them further), but my rough thoughts are: - SORN are a cute alternative to

Re: [swift-evolution] Allow FloatLiteralType in FloatLiteralConvertible to be aliased to String

> On May 6, 2016, at 12:41 PM, Joe Groff via swift-evolution > wrote: > >> >> On May 6, 2016, at 2:24 AM, Morten Bek Ditlevsen via swift-evolution >> wrote: >> >> Currently, in order to conform to FloatLiteralConvertible you need to >>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0080: Failable Numeric Conversion Initializers

First, a general +1 to these, thanks for proposing them. In SE-0067 we spelled these “exactly” rather than “exact”. init?(exactly value: Source) As for –0, Int(exactly: -0.0) should *not* fail. My rationale for this is as follows: - While information (the signbit) is lost, the essential

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

> On Apr 27, 2016, at 1:54 PM, Dave Abrahams via swift-evolution > wrote: > > on Tue Apr 26 2016, Chris Lattner wrote: > >> On Apr 26, 2016, at 7:34 PM, Tony Allevato via swift-evolution >> wrote: >>> Would

Re: [swift-evolution] [Review #2] SE-0067: Enhanced Floating Point Protocols

Do you actually want a method added, or just conformance to AbsoluteValuable? – Steve > On Apr 26, 2016, at 7:41 PM, Xiaodi Wu wrote: > > Unrelated to this discussion about comparison operators, please remember to > put back .abs() or .absoluteValue() somewhere in

Re: [swift-evolution] [Review #2] SE-0067: Enhanced Floating Point Protocols

> On Apr 26, 2016, at 10:03 AM, Nicola Salmoria via swift-evolution > wrote: > > it should be enough to do > > func <= (lhs: T, rhs: T) -> Bool > { > return lhs.isLess(than: rhs) || lhs.isEqual(to: rhs) > } > > Or is there some case of x, y where (x <= y) is

Re: [swift-evolution] [Review #2] SE-0067: Enhanced Floating Point Protocols

> On Apr 25, 2016, at 8:45 PM, Xiaodi Wu via swift-evolution > wrote: > > Suggestions re naming of `isLessThanOrEqualTo(_:)`: > "Less-than" can be regarded as a unit. Thus, `isLessThan(_:)` is reasonable. > However, `isEqualTo(_:)` is kind of a stretch, but it could

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

> On Apr 25, 2016, at 2:12 PM, Jordan Rose wrote: > >> On Apr 22, 2016, at 7:13, Stephen Canon > > wrote: >> >>> /// A signaling NaN (not-a-number). >>> @warn_unused_result >>> static func signalingNaN: Self { get } >>>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

> On Apr 23, 2016, at 8:53 PM, Brent Royal-Gordon via swift-evolution > wrote: > > A few things… > > First, something absent: I'm a little bit concerned by the act that there's > no means to convert between different concrete FloatingPoint types. Something > like

Re: [swift-evolution] [Idea] Bringing the partial/total ordering distinction into Comparable

> On Apr 24, 2016, at 6:08 PM, Xiaodi Wu via swift-evolution > wrote: > > Something else to consider if you insist that all floating point values must > be "orderable" would be how two NaNs are ordered if they have different > payloads. As far as I'm aware, that

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

> On Apr 22, 2016, at 12:42 PM, Dave Abrahams via swift-evolution > wrote: > > This argument makes no sense to me. A floating point number is made up > of three parts, and one part *is* not like the other ones. In what way is it

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

> On Apr 22, 2016, at 12:09 PM, Xiaodi Wu wrote: > >> >> This runs into exactly the same issues; in the (extremely rare) cases where >> such enormous exponents are used, they tend to be coupled with surprisingly >> modest significands, so I don’t think this fixes

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

> On Apr 22, 2016, at 12:21 PM, Xiaodi Wu wrote: > > To expand, the hypothetical use case I'm trying to leave open is this: > suppose I want to implement a Float1024 type with 79 exponent bits and > 944 fraction bits. Could I conform it to BinaryFloatingPoint? As > currently

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

> On Apr 22, 2016, at 11:58 AM, Xiaodi Wu wrote: > > On Fri, Apr 22, 2016 at 10:31 AM, Stephen Canon wrote: >> >>> On Apr 22, 2016, at 11:26 AM, Xiaodi Wu wrote: >>> >>> On Fri, Apr 22, 2016 at 9:56 AM, Stephen Canon

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

elf, >> magnitudeOf other: Self)`? >> >> >> On Fri, Apr 22, 2016 at 9:54 AM, Xiaodi Wu <xiaodi...@gmail.com> wrote: >>> On Fri, Apr 22, 2016 at 9:13 AM, Stephen Canon via swift-evolution >>> <swift-evolution@swift.org> wrote: >>>> >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

> On Apr 22, 2016, at 10:54 AM, Xiaodi Wu wrote: > > Naive question: is it necessary to make a trade-off here? Why not an > associated type Exponent that's Int for Float, Double, and Float80, > allowing for something else for bignums? It’s an added (fairly minor)

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

> On Apr 21, 2016, at 9:13 PM, Jordan Rose wrote: > > [Proposal: > https://github.com/apple/swift-evolution/blob/master/proposals/0067-floating-point-protocols.md > > ] >

Re: [swift-evolution] [Review] SE-0067: Enhanced Floating Point Protocols

On Apr 20, 2016, at 4:07 PM, Dave Abrahams via swift-evolution wrote: > Isn't this really maxResultOfAdding1 (Assuming default rounding) yes, that’s one of the things that you could call it. - Steve___ swift-evolution

Re: [swift-evolution] [Review] SE-0067: Enhanced Floating Point Protocols

Comments inline. > On Apr 20, 2016, at 12:04 PM, Xiaodi Wu wrote: > > On Wed, Apr 20, 2016 at 5:38 AM, Stephen Canon wrote: >> Hi Xiaodi — >> >> Thanks for the detailed comments. Some thoughts inline. >> >>> On Apr 19, 2016, at 6:34 PM, Xiaodi Wu via

Re: [swift-evolution] [Review] SE-0067: Enhanced Floating Point Protocols

Hi Xiaodi — Thanks for the detailed comments. Some thoughts inline. > On Apr 19, 2016, at 6:34 PM, Xiaodi Wu via swift-evolution > wrote: > > * What is your evaluation of the proposal? > > +1 in intent. Specifics require further refinement. For example: > >

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

On Apr 15, 2016, at 11:05 AM, Guillaume Lessard via swift-evolution wrote: > I don’t see why this is needed; there isn't an AdditivelyInvertible protocol That’s precisely SignedArithmetic, just under a different name. –

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

> On Apr 15, 2016, at 11:14 AM, Erica Sadun <er...@ericasadun.com> wrote: > > On Apr 15: 2016: at 11:56 AM: Joe Groff via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> >>> On Apr 15:

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

> On Apr 15, 2016, at 9:52 AM, Stephan Tolksdorf via swift-evolution > wrote: > > but the documentation for Equatable and Comparable states that == and < must > implement an equivalence relation and a strict total order, which is > incompatible with the default

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

> On Apr 14, 2016, at 11:48 PM, Nicola Salmoria > wrote: > >> /// The quotient of `self` dividing by `rhs`. >> // Arithmetic provides a default implementation of this method in terms >> // of the mutating `divide` operation. >> @warn_unused_result >> func

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

> On Apr 15, 2016, at 7:23 AM, plx via swift-evolution > wrote: > > One is if there’s any ETA or similar for a glimpse at the “complete picture” > of Swift’s revised numeric protocols; these floating-point protocols look > really, really good, but this is also (I

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

:55 PM, Stephen Canon via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> public protocol FloatingPoint: SignedArithmetic, Comparable { >> ... >> /// The greatest finite number. >> /// >>

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

> On Apr 14, 2016, at 10:12 PM, Erica Sadun wrote: > > >> On Apr 14, 2016, at 10:36 PM, Stephen Canon > > wrote: >> >> Hi Erica, thanks for the feedback. >> >>> On Apr 14, 2016, at 6:29 PM, Erica Sadun

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

, 2016, at 9:49 PM, Stephen Canon <sca...@apple.com >> <mailto:sca...@apple.com>> wrote: >>>> On Apr 14, 2016, at 4:55 PM, Stephen Canon via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>>&

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

Hi Brent, thanks for the feedback. > On Apr 14, 2016, at 8:34 PM, Brent Royal-Gordon > wrote: > > First of all: I do *not* do crazy things with floating-point numbers, so > there's a good chance I'm missing the point with some of this. Consider > anything having to do

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

Hi Howard, thanks for the feedback. > On Apr 14, 2016, at 6:05 PM, Howard Lovatt wrote: > > +1 great addition. > > Would suggest the naming could be more consistent, in particular: > Anything returning Self could be named xxxed. In the current proposal this > naming

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

Joe’s isn’t saying that “Indexes” is more common, rather that it’s regular (i.e. follows the usual declension rule for plurals); there’s tradeoffs each way, but using the regular plural might make it more familiar for some non-native speakers/readers. – Steve > On Apr 11, 2016, at 9:42 AM,

Re: [swift-evolution] Missing initializers from/to FloatingPointType

The draft proposal may be easier reading: https://github.com/stephentyrone/swift-evolution/blob/master/-floating-point-protocols.md > On Apr 7, 2016, at 11:16 AM, Max Moiseev via swift-evolution > wrote: > > Hi Dan, > > New protocols are in the making for both

Re: [swift-evolution] Feature proposal: Range operator with step

> On Apr 6, 2016, at 2:25 PM, Dave Abrahams via swift-evolution > wrote: > > > on Wed Apr 06 2016, Erica Sadun wrote: > >>On Apr 6, 2016, at 3:05 PM, Dave Abrahams via swift-evolution >> wrote: >> >>on Wed Apr 06 2016,

Re: [swift-evolution] Feature proposal: Range operator with step

> On Apr 6, 2016, at 11:26 AM, Erica Sadun <er...@ericasadun.com> wrote: > >> >> On Apr 6, 2016, at 12:23 PM, Stephen Canon via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> >>>

Re: [swift-evolution] Feature proposal: Range operator with step

> On Apr 6, 2016, at 11:20 AM, Stephen Canon via swift-evolution > <swift-evolution@swift.org> wrote: > >> On Apr 6, 2016, at 11:16 AM, Dave Abrahams via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>

Re: [swift-evolution] Feature proposal: Range operator with step

> On Apr 6, 2016, at 11:16 AM, Dave Abrahams via swift-evolution > wrote: > > One question that I *do* think we should answer, is whether the elements > of > >(0..<199).striding(by: -2) > > are even or odd. Odd. I don’t believe that many real use cases care,

Re: [swift-evolution] Feature proposal: Range operator with step

> On Apr 6, 2016, at 10:10 AM, Dave Abrahams via swift-evolution > wrote: > > > on Wed Apr 06 2016, Brent Royal-Gordon wrote: > >>> For example, there are all kinds of other ways to slice this: >>> >>> stride(over: 0..<200, by: -2) >> >> This seems like a

Re: [swift-evolution] Feature proposal: Range operator with step

> On Apr 5, 2016, at 3:22 PM, Erica Sadun via swift-evolution > wrote: > >> On Apr 5, 2016, at 4:17 PM, Dave Abrahams via swift-evolution >> wrote: >> >> on Tue Apr 05 2016, Erica Sadun wrote: >> >>> On Apr

Re: [swift-evolution] Feature proposal: Range operator with step

General numerics comments: We’ll want internal state and computation to be Double for Float or Double, and Float80 for Float80. This confers a couple significant advantages: - There are useful loops with more than 2**31 steps, which means having _step be Int is insufficient on 32-bit systems.

Re: [swift-evolution] Feature proposal: Range operator with step

> On Mar 31, 2016, at 11:16 AM, Rainer Brockerhoff via swift-evolution > wrote: > > On 3/31/16 15:06, Dave Abrahams via swift-evolution wrote: >> >> on Thu Mar 31 2016, Xiaodi Wu wrote: >> >>> Thoughts on an edge case: so long as it's possible to use >>>

Re: [swift-evolution] Implicit Type Conversion For Numerics Where Possible.

On Mar 30, 2016, at 1:35 PM, Ted F.A. van Gaalen via swift-evolution wrote: >> As long as data loss is an "unintended" effect of a certain class of >> coercions, I don't believe it deserves to be implicit. If you "know what >> you're doing", the preference so far

Re: [swift-evolution] Pre-proposal: Safer Decimal Calculations

> On Mar 24, 2016, at 10:01 AM, Rainer Brockerhoff > wrote: > > There's the mismatch between decimal representation of binary formats, > causing confusion for very common cases like 0.01. There's your work in > upgrading the FloatingPoint protocol. There's the question

  1   2   >