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)
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<MySpecialInt>, but doing matrix multiplication with that
simply isn't going to be performant.
···
On Wed, Aug 3, 2016 at 9:48 AM, Nevin Brackett-Rozinsky via swift-evolution <swift-evolution@swift.org> wrote:
Nevin
On Wed, Aug 3, 2016 at 8:41 AM, Björn Forster <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)
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 <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)
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.
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
···
On Aug 3, 2016, at 5:41 AM, Björn Forster via swift-evolution <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?
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 <swift-evolution@swift.org> 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<MySpecialInt>, 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 <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)
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)
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.
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 Forster<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)
> https://lists.swift.org/mailman/listinfo/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
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.
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 Forster<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)
I don't think that non-type generic arguments are enough to create fixed-size arrays. How would you fill in `struct Vector<T, count: Int> { ... }`?
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.
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<T, count: Int>{ ... }`?
Seems to me that the first step would be actual language support for non-parametrizable fixed-size arrays.
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.
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<T, count: Int>{ ... }`?
Seems to me that the first step would be actual language support for non-parametrizable fixed-size arrays.
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.
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 Forster<swift-evolution@swift.org(mailto: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