> On 3. Aug 2017, at 00:43, Xiaodi Wu via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> 
> On Wed, Aug 2, 2017 at 17:37 Nicolas Fezans <nicolas.fez...@gmail.com 
> <mailto:nicolas.fez...@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.

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 best implemented as compiler intrinsics.

That said, I don’t think N-dimensional matrices need to be part of the standard 
library. I still think there’s plenty of space for good library 
implementations. We can’t realistically expect anybody to implement a (fast) 
cosine function from scratch, though.

I think Swift should allow you to write a standard scientific calculator 
without downloading a mathematics library. Essentially, that means basic trig, 
exponentiation and logarithms. Possibly even factorials.

- Karl

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

Reply via email to