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

[Félix Cloutier]

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 <taras.zakharko at uzh.ch> 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<T, count: Int>{ ... }`?
>> 
>> 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<swift-evolution at swift.org(mailto:swift-evolution at 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<T, count: Int>{ … }
>>> 
>>> var x : Vector<Float, count=16>
>>> 
>>> or even
>>> 
>>> struct SparseTensor<T, dimensions : [Int]>{ … }
>>> 
>>> var x: SparseTensor<Float, dimensions = [100, 100, 100, 100]>= 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 Forster<swift-evolution at swift.org(mailto:swift-evolution at swift.org)(mailto:swift-evolution at 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 at swift.org(mailto:swift-evolution at swift.org)(mailto:swift-evolution at swift.org)
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>> 
>>>> 
>>>> 
>>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org(mailto:swift-evolution at swift.org)
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160806/6d5ffbc3/attachment.html>