Re: [swift-evolution] Which functionality should be covered by a native Swift math/numerics library that ships with the standard lib?

[Xiaodi Wu via swift-evolution]

For matrix math, there are several projects in existence. I know of Surge
and its forked cousin Upsurge, and a quick googling reveals a few more.
On Tue, Aug 9, 2016 at 14:22 Maximilian Hünenberger <
swift-evolution@swift.org> wrote:

> I think this is a great idea!
>
> As Chris said we should use GitHub or something else to start such a
> project. Does someone already has a Math library where we can discuss and
> commit?
>
> I'll soon push a small Math library to my GitHub repo and let you know.
>
> Best regards
> Maximilian
>
> > Am 03.08.2016 um 14:41 schrieb Björn Forster via swift-evolution <
> swift-evolution@swift.org>:
> >
> > Hello Swift community,
> > to make use of Swift more appealing and useful for science, engineering
> and finance and everything else involving actually calculating things, I
> think it would be a big step forward if Swift would ship with its own
> math/numerics library.
> >
> > Wouldn't it be great if Swift would offer functionality similar to Numpy
> in its native math lib? It think it would be great to have a "standard"
> annotation for vector arithmetic that the Swift community has agreed on and
> that scientific packages can build on.
> >
> > Which functionality should be covered by a Swift's math lib and where
> should be drawn the line?
> >
> > Any thoughts?
> >
> > (If it is not the right time now to talk this topic, as it is not
> mentioned in the goals for Swift 4 by Chris, I apologize for bringing this
> up now. But I think then this should be discussed later at some point not
> in the infinite future)
> >
> > Björn
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Which functionality should be covered by a native Swift math/numerics library that ships with the standard lib?

[Maximilian Hünenberger via swift-evolution]

I think this is a great idea!

As Chris said we should use GitHub or something else to start such a project. 
Does someone already has a Math library where we can discuss and commit?

I'll soon push a small Math library to my GitHub repo and let you know.

Best regards
Maximilian

> Am 03.08.2016 um 14:41 schrieb Björn Forster via swift-evolution 
> :
> 
> Hello Swift community,
> to make use of Swift more appealing and useful for science, engineering and 
> finance and everything else involving actually calculating things, I think it 
> would be a big step forward if Swift would ship with its own math/numerics 
> library.
> 
> Wouldn't it be great if Swift would offer functionality similar to Numpy in 
> its native math lib? It think it would be great to have a "standard" 
> annotation for vector arithmetic that the Swift community has agreed on and 
> that scientific packages can build on.
> 
> Which functionality should be covered by a Swift's math lib and where should 
> be drawn the line?
> 
> Any thoughts?
> 
> (If it is not the right time now to talk this topic, as it is not mentioned 
> in the goals for Swift 4 by Chris, I apologize for bringing this up now. But 
> I think then this should be discussed later at some point not in the infinite 
> future)  
> 
> Björn
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Which functionality should be covered by a native Swift math/numerics library that ships with the standard lib?

[Félix Cloutier via swift-evolution]

If you'd allocate memory for a fixed-size array, you might as well use a 
non-fixed-size array. You need the overhead of a full object header to be able 
to implement copy-on-write semantics anyway.

Right now, C fixed-size arrays are imported as tuples. int[4] translates to 
(Int32, Int32, Int32, Int32). If nothing else, fixed-size arrays as first-class 
constructs would let you access objects at a variable index or iterate over 
them without doing the little raw pointer dance.

Félix

> Le 5 août 2016 à 11:00:58, Taras Zakharko  a écrit :
> 
> You could use the pointer/raw memory API to implement that. 
> 
> One reason why I dislike the idea of introducing fixed-size arrays as a 
> first-class language feature is that it adds an additional construct with 
> quite niche use. Non-type generic parameters instead give you a powerful tool 
> that you can use to implement all kinds of things. 
> 
> BTW, another way to have fixed-size arrays would be to extend the tuple type. 
> However, if i understand correctly, the biggest optimisation potential comes 
> from knowing the size of the array at the compile time. So we do need some 
> sort of specialisation parameter. 
> 
> Best, 
> 
> Taras
> 
>> I don't think that non-type generic arguments are enough to create 
>> fixed-size arrays. How would you fill in `struct Vector{ ... 
>> }`?
>> 
>> Seems to me that the first step would be actual language support for 
>> non-parametrizable fixed-size arrays.
>> 
>> Félix
>>> Le 5 août 2016 à 04:53:20, Taras Zakharko via 
>>> swift-evolutionmailto:swift-evolution@swift.org)>a
>>>  écrit :
>>> 
>>> 
 A few things immediately spring to mind:
 • Fixed-size arrays
 • An optimized Matrix type
 • Swifty syntax for Fourier transforms
 • A numerical integrator (or diff-eq solver!)
 • BigInt capabilities
 
 The first of these (fixed-size arrays) will probably require compiler 
 support.
>>> 
>>> Fixed-size arrays should be easy enough to implement if the Swift generics 
>>> are enhanced with support for constraints beyond type variables. E.g.
>>> 
>>> struct Vector{ … }
>>> 
>>> var x : Vector
>>> 
>>> or even
>>> 
>>> struct SparseTensor{ … }
>>> 
>>> var x: SparseTensor= 
>>> SparseTensor(withValue: 0)
>>> 
>>> I believe that something like this was mentioned in the discussion of the 
>>> Generics Manifesto. If you are interested in making Swift more suitable for 
>>> numerical operations, I’d say that the first order of business is to work 
>>> towards implementing this sort of generic constants.
>>> 
>>> Best,
>>> 
>>> Taras
>>> 
 
 The rest can already be done in a library, except I believe they will hit 
 the “generics cannot be specialized across module boundaries” slowdown, 
 and must be explicitly specialized for common numeric types to avoid it. 
 (Has this been fixed yet? Are there plans to?)
 
 Nevin
 
 
 
 On Wed, Aug 3, 2016 at 8:41 AM, Björn 
 Forstermailto:swift-evolution@swift.org)(mailto:swift-evolution@swift.org)>wrote:
> Hello Swift community,
> to make use of Swift more appealing and useful for science, engineering 
> and finance and everything else involving actually calculating things, I 
> think it would be a big step forward if Swift would ship with its own 
> math/numerics library.
> 
> Wouldn't it be great if Swift would offer functionality similar to Numpy 
> in its native math lib? It think it would be great to have a "standard" 
> annotation for vector arithmetic that the Swift community has agreed on 
> and that scientific packages can build on.
> 
> Which functionality should be covered by a Swift's math lib and where 
> should be drawn the line?
> 
> Any thoughts?
> 
> (If it is not the right time now to talk this topic, as it is not 
> mentioned in the goals for Swift 4 by Chris, I apologize for bringing 
> this up now. But I think then this should be discussed later at some 
> point not in the infinite future)
> 
> Björn
> ___
> swift-evolution mailing list
> swift-evolution@swift.org(mailto:swift-evolution@swift.org)(mailto:swift-evolution@swift.org)
> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
 
 
 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org(mailto:swift-evolution@swift.org)
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> 

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

Re: [swift-evolution] Which functionality should be covered by a native Swift math/numerics library that ships with the standard lib?

[Taras Zakharko via swift-evolution]

You could use the pointer/raw memory API to implement that. 

One reason why I dislike the idea of introducing fixed-size arrays as a 
first-class language feature is that it adds an additional construct with quite 
niche use. Non-type generic parameters instead give you a powerful tool that 
you can use to implement all kinds of things. 

BTW, another way to have fixed-size arrays would be to extend the tuple type. 
However, if i understand correctly, the biggest optimisation potential comes 
from knowing the size of the array at the compile time. So we do need some sort 
of specialisation parameter. 

Best, 

 Taras

> I don't think that non-type generic arguments are enough to create fixed-size 
> arrays. How would you fill in `struct Vector{ ... }`?
> 
> Seems to me that the first step would be actual language support for 
> non-parametrizable fixed-size arrays.
> 
> Félix
> > Le 5 août 2016 à 04:53:20, Taras Zakharko via 
> > swift-evolutionmailto:swift-evolution@swift.org)>a
> >  écrit :
> > 
> > 
> > > A few things immediately spring to mind:
> > > • Fixed-size arrays
> > > • An optimized Matrix type
> > > • Swifty syntax for Fourier transforms
> > > • A numerical integrator (or diff-eq solver!)
> > > • BigInt capabilities
> > > 
> > > The first of these (fixed-size arrays) will probably require compiler 
> > > support.
> > 
> > Fixed-size arrays should be easy enough to implement if the Swift generics 
> > are enhanced with support for constraints beyond type variables. E.g.
> > 
> > struct Vector{ … }
> > 
> > var x : Vector
> > 
> > or even
> > 
> > struct SparseTensor{ … }
> > 
> > var x: SparseTensor= 
> > SparseTensor(withValue: 0)
> > 
> > I believe that something like this was mentioned in the discussion of the 
> > Generics Manifesto. If you are interested in making Swift more suitable for 
> > numerical operations, I’d say that the first order of business is to work 
> > towards implementing this sort of generic constants.
> > 
> > Best,
> > 
> > Taras
> > 
> > > 
> > > The rest can already be done in a library, except I believe they will hit 
> > > the “generics cannot be specialized across module boundaries” slowdown, 
> > > and must be explicitly specialized for common numeric types to avoid it. 
> > > (Has this been fixed yet? Are there plans to?)
> > > 
> > > Nevin
> > > 
> > > 
> > > 
> > > On Wed, Aug 3, 2016 at 8:41 AM, Björn 
> > > Forstermailto:swift-evolution@swift.org)(mailto:swift-evolution@swift.org)>wrote:
> > > > Hello Swift community,
> > > > to make use of Swift more appealing and useful for science, engineering 
> > > > and finance and everything else involving actually calculating things, 
> > > > I think it would be a big step forward if Swift would ship with its own 
> > > > math/numerics library.
> > > > 
> > > > Wouldn't it be great if Swift would offer functionality similar to 
> > > > Numpy in its native math lib? It think it would be great to have a 
> > > > "standard" annotation for vector arithmetic that the Swift community 
> > > > has agreed on and that scientific packages can build on.
> > > > 
> > > > Which functionality should be covered by a Swift's math lib and where 
> > > > should be drawn the line?
> > > > 
> > > > Any thoughts?
> > > > 
> > > > (If it is not the right time now to talk this topic, as it is not 
> > > > mentioned in the goals for Swift 4 by Chris, I apologize for bringing 
> > > > this up now. But I think then this should be discussed later at some 
> > > > point not in the infinite future)
> > > > 
> > > > Björn
> > > > ___
> > > > swift-evolution mailing list
> > > > swift-evolution@swift.org(mailto:swift-evolution@swift.org)(mailto:swift-evolution@swift.org)
> > > > https://lists.swift.org/mailman/listinfo/swift-evolution
> > > > 
> > > 
> > > 
> > > 
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org(mailto:swift-evolution@swift.org)
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Which functionality should be covered by a native Swift math/numerics library that ships with the standard lib?

[Tino Heth via swift-evolution]

> I don't think that non-type generic arguments are enough to create fixed-size 
> arrays. How would you fill in `struct Vector { ... }`?
Fixed-size arrays could be initialized like current arrays:
You either give a value to repeat or an array-literal of the right size.
There could be a faillable initializer that takes an array of undefined size as 
well.

The data could be stored in a "normal" array, but I'd expect an implementation 
in the stdlib, so that working with raw memory would stay something that's not 
needed for most Swift developers.

> Seems to me that the first step would be actual language support for 
> non-parametrizable fixed-size arrays.
Are you referring to literals here?___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Which functionality should be covered by a native Swift math/numerics library that ships with the standard lib?

[Félix Cloutier via swift-evolution]

I don't think that non-type generic arguments are enough to create fixed-size 
arrays. How would you fill in `struct Vector { ... }`?

Seems to me that the first step would be actual language support for 
non-parametrizable fixed-size arrays.

Félix

> Le 5 août 2016 à 04:53:20, Taras Zakharko via swift-evolution 
>  a écrit :
> 
> 
> 
>> A few things immediately spring to mind:
>> • Fixed-size arrays
>> • An optimized Matrix type
>> • Swifty syntax for Fourier transforms
>> • A numerical integrator (or diff-eq solver!)
>> • BigInt capabilities
>> 
>> The first of these (fixed-size arrays) will probably require compiler 
>> support.
> 
> Fixed-size arrays should be easy enough to implement if the Swift generics 
> are enhanced with support for constraints beyond type variables. E.g.
> 
>  struct Vector { … } 
> 
>  var x : Vector
> 
> or even 
> 
> struct SparseTensor { … }
> 
> var x: SparseTensor = 
> SparseTensor(withValue: 0)
> 
> I believe that something like this was mentioned in the discussion of the 
> Generics Manifesto. If you are interested in making Swift more suitable for 
> numerical operations, I’d say that the first order of business is to work 
> towards implementing this sort of generic constants. 
> 
> Best, 
> 
> Taras
> 
>> 
>> The rest can already be done in a library, except I believe they will hit 
>> the “generics cannot be specialized across module boundaries” slowdown, and 
>> must be explicitly specialized for common numeric types to avoid it. (Has 
>> this been fixed yet? Are there plans to?)
>> 
>> Nevin
>> 
>> 
>> 
>> On Wed, Aug 3, 2016 at 8:41 AM, Björn 
>> Forstermailto:swift-evolution@swift.org)>wrote:
>>> Hello Swift community,
>>> to make use of Swift more appealing and useful for science, engineering and 
>>> finance and everything else involving actually calculating things, I think 
>>> it would be a big step forward if Swift would ship with its own 
>>> math/numerics library.
>>> 
>>> Wouldn't it be great if Swift would offer functionality similar to Numpy in 
>>> its native math lib? It think it would be great to have a "standard" 
>>> annotation for vector arithmetic that the Swift community has agreed on and 
>>> that scientific packages can build on.
>>> 
>>> Which functionality should be covered by a Swift's math lib and where 
>>> should be drawn the line?
>>> 
>>> Any thoughts?
>>> 
>>> (If it is not the right time now to talk this topic, as it is not mentioned 
>>> in the goals for Swift 4 by Chris, I apologize for bringing this up now. 
>>> But I think then this should be discussed later at some point not in the 
>>> infinite future)
>>> 
>>> Björn
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org(mailto:swift-evolution@swift.org)
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>> 
>> 
>> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] Which functionality should be covered by a native Swift math/numerics library that ships with the standard lib?

[Taras Zakharko via swift-evolution]

> A few things immediately spring to mind:
> • Fixed-size arrays
> • An optimized Matrix type
> • Swifty syntax for Fourier transforms
> • A numerical integrator (or diff-eq solver!)
> • BigInt capabilities
> 
> The first of these (fixed-size arrays) will probably require compiler support.

Fixed-size arrays should be easy enough to implement if the Swift generics are 
enhanced with support for constraints beyond type variables. E.g.

  struct Vector { … } 

  var x : Vector

or even 

 struct SparseTensor { … }

 var x: SparseTensor = 
SparseTensor(withValue: 0)

I believe that something like this was mentioned in the discussion of the 
Generics Manifesto. If you are interested in making Swift more suitable for 
numerical operations, I’d say that the first order of business is to work 
towards implementing this sort of generic constants. 

Best, 

 Taras

> 
> The rest can already be done in a library, except I believe they will hit the 
> “generics cannot be specialized across module boundaries” slowdown, and must 
> be explicitly specialized for common numeric types to avoid it. (Has this 
> been fixed yet? Are there plans to?)
> 
> Nevin
> 
> 
> 
> On Wed, Aug 3, 2016 at 8:41 AM, Björn 
> Forstermailto:swift-evolution@swift.org)>wrote:
> > Hello Swift community,
> > to make use of Swift more appealing and useful for science, engineering and 
> > finance and everything else involving actually calculating things, I think 
> > it would be a big step forward if Swift would ship with its own 
> > math/numerics library.
> > 
> > Wouldn't it be great if Swift would offer functionality similar to Numpy in 
> > its native math lib? It think it would be great to have a "standard" 
> > annotation for vector arithmetic that the Swift community has agreed on and 
> > that scientific packages can build on.
> > 
> > Which functionality should be covered by a Swift's math lib and where 
> > should be drawn the line?
> > 
> > Any thoughts?
> > 
> > (If it is not the right time now to talk this topic, as it is not mentioned 
> > in the goals for Swift 4 by Chris, I apologize for bringing this up now. 
> > But I think then this should be discussed later at some point not in the 
> > infinite future)
> > 
> > Björn
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org(mailto:swift-evolution@swift.org)
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> > 
> 
> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Which functionality should be covered by a native Swift math/numerics library that ships with the standard lib?

[Chris Lattner via swift-evolution]

> On Aug 3, 2016, at 5:41 AM, Björn Forster via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> to make use of Swift more appealing and useful for science, engineering and 
> finance and everything else involving actually calculating things, I think it 
> would be a big step forward if Swift would ship with its own math/numerics 
> library.
> 
> Wouldn't it be great if Swift would offer functionality similar to Numpy in 
> its native math lib? It think it would be great to have a "standard" 
> annotation for vector arithmetic that the Swift community has agreed on and 
> that scientific packages can build on.
> 
> Which functionality should be covered by a Swift's math lib and where should 
> be drawn the line?

Hi Björn,

This is one of many areas that we haven’t had time to really think about 
(specifically, how far the math portion of the Swift stdlib should go).  I 
think there is some general sentiment (e.g. expressed by Steve Canon) that 
Swift should eventually provide BigInt and robust decimal floating point 
support, but given the Swift 4 Stage 1 challenges in front of the standard 
library, we need to keep focused on that.  Extensions like that can be added at 
any time.

However, this isn’t something that really needs to be debated here: I’d 
strongly encourage you to start a project (e.g. on github) and try to build out 
some interesting things.  Once you have something interesting that works well, 
we can talk about whether it makes sense to incorporate some of the code or 
ideas into Swift, or whether it makes sense to be a standalone library.

-Chris

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

Re: [swift-evolution] Which functionality should be covered by a native Swift math/numerics library that ships with the standard lib?

[Muse M via swift-evolution]

If Swift team have no roadmap on those plans, any swift developers with
strong in each area could kickstart and contributing libraries in Github
repo. We will greatly benefit from those areas and AI.

On Wed, Aug 3, 2016 at 11:10 PM, Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> On Wed, Aug 3, 2016 at 9:48 AM, Nevin Brackett-Rozinsky via
> swift-evolution  wrote:
>
>> A few things immediately spring to mind:
>> • Fixed-size arrays
>> • An optimized Matrix type
>> • Swifty syntax for Fourier transforms
>> • A numerical integrator (or diff-eq solver!)
>> • BigInt capabilities
>>
>> The first of these (fixed-size arrays) will probably require compiler
>> support.
>>
>> The rest can already be done in a library, except I believe they will hit
>> the “generics cannot be specialized across module boundaries” slowdown, and
>> must be explicitly specialized for common numeric types to avoid it. (Has
>> this been fixed yet? Are there plans to?)
>>
>
> The underlying libraries provide optimized versions of matrix functions
> and Fourier transforms only for particular numeric types anyway. It'd be
> Swifty to have Matrix, but doing matrix multiplication with
> that simply isn't going to be performant.
>
>
>>
>> Nevin
>>
>>
>>
>> On Wed, Aug 3, 2016 at 8:41 AM, Björn Forster 
>> wrote:
>>
>>> Hello Swift community,
>>> to make use of Swift more appealing and useful for science, engineering
>>> and finance and everything else involving actually calculating things, I
>>> think it would be a big step forward if Swift would ship with its own
>>> math/numerics library.
>>>
>>> Wouldn't it be great if Swift would offer functionality similar to Numpy
>>> in its native math lib? It think it would be great to have a "standard"
>>> annotation for vector arithmetic that the Swift community has agreed on and
>>> that scientific packages can build on.
>>>
>>> Which functionality should be covered by a Swift's math lib and where
>>> should be drawn the line?
>>>
>>> Any thoughts?
>>>
>>> (If it is not the right time now to talk this topic, as it is not
>>> mentioned in the goals for Swift 4 by Chris, I apologize for bringing this
>>> up now. But I think then this should be discussed later at some point not
>>> in the infinite future)
>>>
>>> Björn
>>>
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Which functionality should be covered by a native Swift math/numerics library that ships with the standard lib?

[Xiaodi Wu via swift-evolution]

On Wed, Aug 3, 2016 at 9:48 AM, Nevin Brackett-Rozinsky via swift-evolution
 wrote:

> A few things immediately spring to mind:
> • Fixed-size arrays
> • An optimized Matrix type
> • Swifty syntax for Fourier transforms
> • A numerical integrator (or diff-eq solver!)
> • BigInt capabilities
>
> The first of these (fixed-size arrays) will probably require compiler
> support.
>
> The rest can already be done in a library, except I believe they will hit
> the “generics cannot be specialized across module boundaries” slowdown, and
> must be explicitly specialized for common numeric types to avoid it. (Has
> this been fixed yet? Are there plans to?)
>

The underlying libraries provide optimized versions of matrix functions and
Fourier transforms only for particular numeric types anyway. It'd be Swifty
to have Matrix, but doing matrix multiplication with that
simply isn't going to be performant.


>
> Nevin
>
>
>
> On Wed, Aug 3, 2016 at 8:41 AM, Björn Forster 
> wrote:
>
>> Hello Swift community,
>> to make use of Swift more appealing and useful for science, engineering
>> and finance and everything else involving actually calculating things, I
>> think it would be a big step forward if Swift would ship with its own
>> math/numerics library.
>>
>> Wouldn't it be great if Swift would offer functionality similar to Numpy
>> in its native math lib? It think it would be great to have a "standard"
>> annotation for vector arithmetic that the Swift community has agreed on and
>> that scientific packages can build on.
>>
>> Which functionality should be covered by a Swift's math lib and where
>> should be drawn the line?
>>
>> Any thoughts?
>>
>> (If it is not the right time now to talk this topic, as it is not
>> mentioned in the goals for Swift 4 by Chris, I apologize for bringing this
>> up now. But I think then this should be discussed later at some point not
>> in the infinite future)
>>
>> Björn
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Which functionality should be covered by a native Swift math/numerics library that ships with the standard lib?

[Nevin Brackett-Rozinsky via swift-evolution]

A few things immediately spring to mind:
• Fixed-size arrays
• An optimized Matrix type
• Swifty syntax for Fourier transforms
• A numerical integrator (or diff-eq solver!)
• BigInt capabilities

The first of these (fixed-size arrays) will probably require compiler
support.

The rest can already be done in a library, except I believe they will hit
the “generics cannot be specialized across module boundaries” slowdown, and
must be explicitly specialized for common numeric types to avoid it. (Has
this been fixed yet? Are there plans to?)

Nevin



On Wed, Aug 3, 2016 at 8:41 AM, Björn Forster 
wrote:

> Hello Swift community,
> to make use of Swift more appealing and useful for science, engineering
> and finance and everything else involving actually calculating things, I
> think it would be a big step forward if Swift would ship with its own
> math/numerics library.
>
> Wouldn't it be great if Swift would offer functionality similar to Numpy
> in its native math lib? It think it would be great to have a "standard"
> annotation for vector arithmetic that the Swift community has agreed on and
> that scientific packages can build on.
>
> Which functionality should be covered by a Swift's math lib and where
> should be drawn the line?
>
> Any thoughts?
>
> (If it is not the right time now to talk this topic, as it is not
> mentioned in the goals for Swift 4 by Chris, I apologize for bringing this
> up now. But I think then this should be discussed later at some point not
> in the infinite future)
>
> Björn
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Which functionality should be covered by a native Swift math/numerics library that ships with the standard lib?

[Tino Heth via swift-evolution]

> to make use of Swift more appealing and useful for science, engineering and 
> finance and everything else involving actually calculating things, I think it 
> would be a big step forward if Swift would ship with its own math/numerics 
> library.
There are several topics that imho would benefit from a standard implementation 
(C++ would be so much nicer with a simple "Point" type…) — math is one big 
piece, but there are many more.
None the less, it seems the core team has no time or interest in supporting 
libraries besides the bare stdlib, and the rest of the community is to 
fragmented to tackle this :-(

It's likely that there will be de-facto standards sooner or later, but it 
doesn't look like we'll have something like boost soon.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Which functionality should be covered by a native Swift math/numerics library that ships with the standard lib?

[Björn Forster via swift-evolution]

Hello Swift community,
to make use of Swift more appealing and useful for science, engineering and
finance and everything else involving actually calculating things, I think
it would be a big step forward if Swift would ship with its own
math/numerics library.

Wouldn't it be great if Swift would offer functionality similar to Numpy in
its native math lib? It think it would be great to have a "standard"
annotation for vector arithmetic that the Swift community has agreed on and
that scientific packages can build on.

Which functionality should be covered by a Swift's math lib and where
should be drawn the line?

Any thoughts?

(If it is not the right time now to talk this topic, as it is not mentioned
in the goals for Swift 4 by Chris, I apologize for bringing this up now.
But I think then this should be discussed later at some point not in the
infinite future)

Björn
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution