[swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[David Sweeris]

> On Aug 2, 2017, at 4:29 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> 
>> On Wed, Aug 2, 2017 at 6:17 PM, David Sweeris <davesweeris at mac.com> wrote:
>> 
>> 
>> 
>> Sent from my iPad
>> On Aug 2, 2017, at 3:43 PM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>>> 
>>>> On Wed, Aug 2, 2017 at 17:37 Nicolas Fezans <nicolas.fezans at gmail.com> wrote:
>>>> I think that the items mentioned earlier in the list (just reminded below) should not all be treated equally.
>>>> 
>>>> - RNG and cryptography library (CryptoSwift could be a good base for this)
>>>> - Generic Math library/Vector library
>>>> - Basic data structures (Tree, Balanced Tree, Heap, Queue, SkipList, graphs, etc)
>>>> - Modern DateTime library
>>>> - Modern String processing toolkit
>>>> - 2D Graphics library (similar to cairo)
>>>> - Windowing/UI library
>>>> 
>>>> By that I mean that I see at least one distinction to make between:
>>>> 
>>>> a) the libraries that would make Swift and the programmer experience with these libraries under Swift significantly better if they are (or at least feel) deeply integrated in the language (for instance with associated syntax / syntax sugar)
>>>>     and 
>>>> b) those that would not really benefit from such an integration to the language.
>>>> 
>>>> For me a core math library, clearly belongs to category a)
>>>> 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 take such matrices as argument e.g. sin(A) with A as matrix produces a matrix of the same size where all elements are the sinus values of the elements of A (sorry but things like this calling map() with 'sin' looks quite ugly for scientists).
>>>> Such a good math syntax should be compact enough to have complete equations looking "close enough" to the maths equations you could have written in a LaTeX or Word documentation of your scientific code. IMO a well integrated swift core math library should feel a Julia or Matlab code (while still having the power of Swift in terms of speed and modern programming paradigms) instead of looking and feeling like 'numpy'. But the latter is what you get if you just make a math library with no integration to the language syntax, operators, and basic functions.
>>> 
>>> I agree that if this would require compiler support, then it needs to be part of the standard library. However, I don't see anything about what you describe that cannot be supported as a third-party library.
>> 
>> Getting the syntax right could possibly require some compiler changes. Maybe. Depends on what "right" means. Declaring a variable, x, to be "the set of all real numbers such that x*sin(x) is an integer" using syntax like this, "let x = {x ∈ ℝ | x * sin(x) ∈ ℕ}", would be neat (I'm a bit hazy on my set notation... that might not actually be correct).
>> We're actually not that far off from that, compiler-wise, I mean. Aside defining the relevant types, operators, and identifiers, that exact syntax pretty much just requires the compiler to allow using a certain types of variables in their own declaration and either one heck of an `ExpressibleByClosureLiteral` protocol, or improvements to the type inference engine.
> 
> We must prioritize features that make the biggest impact for the general community, however. Swift still lacks ABI stability, ownership, concurrency, etc. In terms of math facilities, we still don't have a model for dealing with floating point errors. And, yes, there are improvements to be made in terms of having consistent special functions (sin, cos) in Swift (Glibc and Darwin don't always give you the same answer). All of these things represent sorely needed yet large undertakings; none of these require more syntax.

Oh, I know. I wasn't claiming that we need massive compiler changes right now or anything, just providing an example of a syntax that a hypothetical "CoreMath" type of library might want to support which can't currently be made into legal swift code. 

- Dave Sweeris 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170802/92189583/attachment.html>