TrigonometricFloatingPoint/MathFloatingPoint protocol?

Evolution Discussion
41

See, my problem with statements like this one, is that the answer “should
be supported as a third-party library” can also be interpreted as “not my
problem, go figure it out yourselves”. The idea that central entity can
only pay attention to what they want to, and the Community™ will magically
take care of the rest is one of the most pervasive, and untrue, myths about
open source. What’s worse, is that Swift has the benefit of hindsight, in
the form of many, many examples of languages that came before and fell
victim to this fallacy, and now have 15 competing “private” classes for
basic mathematical objects like *vectors*.

I agree that a core math library, for example, *could* in theory be
supported as a third-party library.

The core team has said that they're open to a core math library being part
of the Swift open source project; they just outlined that the _process_ for
doing so is best initiated with a third-party library as a starting point.

But this will never happen on its own, for reasons that I will reiterate
here:

- no one influential enough has bothered to jump start any such project

Karoly Lorentey has a wonderful, and quite mature, BigInt project: <
https://github.com/lorentey/BigInt&gt;\. Also, as I mentioned, I just started
a project for protocol-based additions to Swift's basic numeric
types. These are just two examples.

- there are no avenues to encourage members of the community to come
together and organize a project (look how this thread got derailed!)

You're welcome to join me in my endeavor to create a math library. I'd bet
Karoly feels the same way about his project.

You don’t know how happy reading that sentence just made me, i’d assumed no
one was willing to team up to build such a thing. In which case, it’s a
good idea to start an incubator organization on Github. I think David
Turnbull tried doing that 2 years ago, I’ll reach out to him if he wants to
be a part of something like this.

We should also maintain an index of promising pure swift libraries so they
are discoverable (like docs.rs does for Rust).

- there is no “soft” infrastructure in place to support such
collaboration (look at the fuss over discourse and mailing list spam!)

The GitHub environment has excellent tools to support such collaboration,
IMO. For example:

Based on my experience implementing a library, I wrote a Gist to outline
some lessons learned and suggestions for improvement. Not only did the
document find an audience, these suggestions were in turn used to inform
core team-driven revisions to the integer protocols. As a result of these
revisions, it became possible to implement some initializers that could be
useful for people writing generic numeric algorithms. Recently, I submitted
a PR to the Swift project on GitHub to implement these initializers. Now,
everyone will be able to use them. Collaboration, positive feedback loop,
win-win for all involved.

Likewise, Karoly used his experience updating BigInt for Swift 4 to inform
certain improvements to the integer protocols. He implemented these
improvements in a series of PRs. Now, as a result of these developments,
Karoly's library will be better designed *and* everyone else will benefit
from a better implementation of the integer protocols. Again,
collaboration, positive feedback loop, win-win for all involved.

Great!! can you link me to the gist?

- there are no positive feedback loops whereby a promising project can

gain market share and mature
- because there is no organization backing these projects, potential
users are reluctant to depend on these libraries, since they will logically
bet that the library is more likely to fall out of maintenance than reach
maturity.

Addressing this point is clearly impossible. When Apple wishes to commit
its own resources to the maintenance of a Swift math library,
swift-corelibs-math will appear on GitHub. Suggestions such as opening an
empty repo and letting people contribute to it would either give the
illusion of organizational backing that doesn't exist or would in fact
commit Apple to support a repo that it doesn't wish to support. I fail to
see why the former is good for anybody; in fact, it's strictly inferior to
the same repo honestly representing itself as a third-party effort. And
asking for the latter is essentially asking Apple to create a Swift math
library--which, again, is not in the cards.

My point wasn’t really to exhort Apple to create a Swift math library, just
that people are more willing to depend on a library if the library’s bus
factor is greater than 1. A lot of great Swift packages in one one guy or
girl’s github repository who later disappeared. Turnbull’s SGLOpenGL
library is a good example of this; his library no longer compiles which
motivated me to write swift-opengl
<https://github.com/kelvin13/swift-opengl&gt;\. Then again, I’m sure people
feel the same way about depending on swift-opengl today as I felt about
depending on SGLOpenGL.

There just has so be some semblance of organization. That organization
doesn’t have to come from Apple or the swift core team. A community
initiative with sufficient momentum would be just as good. (The problem of
course is that it is rare for a community initiative to arise.)

···

On Wed, Aug 2, 2017 at 7:54 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

On Wed, Aug 2, 2017 at 6:29 PM, Taylor Swift <kelvin13ma@gmail.com> wrote:

42

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 would personally place a crypto library in category b).

For basic data structures, I would say probably something in between: maybe
a few data structures are worth having a nicer syntax that typical method
calls (just as are used for arrays and it looks and feels great) but it
would be pointless IMHO to try extending that to too many of these data
structures.

···

On Wed, Aug 2, 2017 at 11:08 PM, Xiaodi Wu via swift-evolution < swift-evolution@swift.org> wrote:

On Wed, Aug 2, 2017 at 12:23 PM, Taylor Swift <kelvin13ma@gmail.com> > wrote:

On Wed, Aug 2, 2017 at 12:45 PM, Gor Gyolchanyan < >> gor.f.gyolchanyan@icloud.com> wrote:

On Aug 2, 2017, at 4:35 AM, Xiaodi Wu via swift-evolution < >>> swift-evolution@swift.org> wrote:

On Tue, Aug 1, 2017 at 7:38 PM, Taylor Swift <kelvin13ma@gmail.com> w
rote:

On Tue, Aug 1, 2017 at 5:50 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

On Tue, Aug 1, 2017 at 13:00 Taylor Swift via swift-evolution < >>>>> swift-evolution@swift.org> wrote:

On Tue, Aug 1, 2017 at 1:51 PM, Michael Ilseman via swift-evolution < >>>>>> swift-evolution@swift.org> wrote:

On Aug 1, 2017, at 10:44 AM, Tino Heth via swift-evolution < >>>>>>> swift-evolution@swift.org> wrote:

So, this has been discussed before on the list many times in the
past. The core team has stated that their preferred process for this is to
have individuals write their own libraries, get real-world adoption, then
(as consensus emerges) propose their inclusion as a core library.

I already opened a new mail to write my answer, but than I thought
"wait, scroll down, and look if Xiaodi did already post links" ;-)
[But where have those potential core libraries been mentioned?]

Anyways, my perception hasn't change much:
I think it would be enough if someone from Apple would say "here's
an empty github-repo called [math/statistics/algebra/crypt
o/graphic/image/audio/music/video/smtp/http…]; feel free to fork
and create pull requests" and adding some democratic mechanism for
acceptance on top of it.

What would be your compatibility and stability expectations of such
APIs? If there are any expectations, then the APIs would need careful
design and thought. The Swift project faces a lot of design bandwidth
limitations, so prioritize is always tricky.

The point of spinning off separate core library working groups would
be so that library feature requests and proposals can stop clogging up
swift-evolution. Then the swift-evolution core team could focus on the
compiler and the standard library and the community would take stewardship
of the core libraries through separate channels.

My understanding is that the server working group, and all such work
groups, will be presenting their proposals here for approval, and that all
API changes in the Swift open source project go through this list.

That sounds like it would spam the general list a lot?

On the contrary, core team members have confirmed that working proposals
such as those are the principal intended use for this list; it is *not*
meant to be a general forum for musings about Swift language design.

My rule of thumb was that any post on the mailing list that I make has
to be aimed at providing a solution to a problem, or at the very least,
seeking help in providing a solution to a problem. If the discussion has no
definitive actionable outcome, then I consider it pointless.

At the same time, people should be able to float ideas here to see how
well they would be received before investing the energy into writing up a
proposal. I certainly wouldn’t spend time drafting up an entire API spec
for a math library without first checking that this is something that the
community actually wants.

I would mostly agree with that statement, except for the word "here."
Swift Evolution clearly isn't representative of the community of Swift
users generally; there are Slack channels, Reddit groups, and other forums
which are intended to be a place for general discussion, and which would
probably get you a good sense of what users want. I definitely agree with
Gor that the "actionable outcome" rule of thumb is a pretty good guideline
for what's most effective on this mailing list.

The other point I'd make here is that I definitely think the core team is
right about encouraging any "entire API spec" for a math library to be
based on implementation experience from actually writing a math library
that has seen good adoption. Essentially, what they're saying is that any
proposed design here should have already proved itself in the field. I
assume that you are well aware of Conway's law, which afaict has good
evidence to back it up; with that in mind, the end product that emerges
from a draft spec and an empty open-source repo is unlikely to be
satisfactory, let alone optimal.

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

43

Your notation is indeed correct, even though using x on both side might
confuse some people, this is correct. But no I would not go that far, but I
think the example I just replied before which should execute also on
octave/scilab (most people in the list probably do not have a matlab
license) should show how compact this syntax is.
I often need to rewrite in C or C++ algorithms that were developed and
validated first on Matlab and it occurs very frequently that the lack of
appropriated syntax (even when using libraries with a lot of functions)
makes the code extremely longer and very much less readable for me. Of
course, each line of C/C++ is simple to understand because in such cases
they do not do much things, but you rapidly get several levels of embedded
loops to do what was written in one or two lines of Matlab code, and in the
end you often do not see the main idea anymore or it is much harder to see
it.

···

On Thu, Aug 3, 2017 at 1:17 AM, David Sweeris <davesweeris@mac.com> wrote:

Sent from my iPad
On Aug 2, 2017, at 3:43 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote:

On Wed, Aug 2, 2017 at 17:37 Nicolas Fezans <nicolas.fezans@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.

- Dave Sweeris

44

The other point I'd make here is that I definitely think the core team is right about encouraging any "entire API spec" for a math library to be based on implementation experience from actually writing a math library that has seen good adoption. Essentially, what they're saying is that any proposed design here should have already proved itself in the field.

The things that are imho the most important to have don't need to be designed anymore — we only need to agree on a specific implementation.
A quick search for "Result Swift" on github yields 80 projects. I haven't looked at all of those, but I would be very surprised if the majority isn't more or less identical:
Names might be not all exactly the same, and some features won't exist everywhere… but I don't think it is a good idea to wait another two years to see if one of the implementations won the competition.
And even if one solution emerges to be the most popular: I bet it won't be because its quality, but some sort of marketing instead.

I assume that you are well aware of Conway's law, which afaict has good evidence to back it up; with that in mind, the end product that emerges from a draft spec and an empty open-source repo is unlikely to be satisfactory, let alone optimal.

That might be true for complicated stuff — but it took me some time to come up with examples for this category…

But there are at least three(!) implementations of quaternions in Apple libraries, and for this stupid reason, you can't directly take the data from the iPhones sensors and animate an object in scene kit with it. Is this satisfactory?

Imho it's not important for those missing "standard" libraries to have state of the art implementations for all established algorithms; it's much more valuable to agree on basics that are adopted by other libraries:
- I don't expect that Swift's dictionaries are optimal, but that isn't nearly as important as the fact that they are compatible with NSDictionary — or just imagine each library had it's own implementation of Array; it would be terrible, and a giant blocker for the adoption of Swift.
- A standard library for directed graphs doesn't need to have a version of A* or Dijkstras algorithm — it would already be a big step forward to declare the basic data structure, so that my variant of A* is compatible with someone else's graph visualisation toolkit.

- Tino

45

You're welcome to join me in my endeavor to create a math library. I'd bet Karoly feels the same way about his project.

See, exactly this is the big problem we are facing here — probably not in your specific case, but in general:
It's not very appealing for most people to contribute to a small library that's rarely known, instead of starting their own project to collect github stars...

- Tino

46

I’ve noticed from this and older threads that everyone agrees on what core libraries we want, but they never actually get built. Perennial requests seem to be

- RNG and cryptography library (CryptoSwift could be a good base for this)

A new implementation of crypto is probably a very bad idea. A blessed wrapping around the platform’s preferred implementation of crypto, however, is certainly needed.

My understanding was that this is already part of the Swift server working group’s efforts, and a large part at that.

That’s right, and this is definitely better handled by them: https://swift.org/server-apis/

···

On Aug 1, 2017, at 10:39 AM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
On Tue, Aug 1, 2017 at 12:21 Michael Ilseman via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Aug 1, 2017, at 8:14 AM, Taylor Swift via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

- Generic Math library/Vector library

This is pretty compelling.

- Basic data structures (Tree, Balanced Tree, Heap, Queue, SkipList, graphs, etc)

Which flavor/implementation of tree, balanced tree, heap, graphs are desirable here? The desirability of many of these structures is often dependent on which of many competing tradeoffs were made. Implementation details can dramatically shape the general applicability of a data structure.

For example, it might make sense to adopt something similar to GitHub - attaswift/BTree: Fast sorted collections for Swift using in-memory B-trees as a general underlying representation for some kinds of higher level collections (or the mechanisms to easily adapt them).

- Modern DateTime library

Foundation provides many of these, though I’m sure there are always opportunities for improvement. Do you see a specific need that cannot be addressed with improvements to corelibs-foundation? There’s a large amount of domain expertise in Foundation and they are pretty active on the mailing lists.

- Modern String processing toolkit

This is a huge gap in Swift’s current offerings, and I’m personally invested in improving the situation here. At the risk of hijacking this thread, do you have a good bullet list of the kinds of facilities you imagine useful? More specifically (and to keep the discussion scoped), are there any tools beyond something like good language support for regular expression matching and substitutions?

- 2D Graphics library (similar to cairo)
- Windowing/UI library

By this, do you mean cross-platform pure Swift rethinks? This is certainly interesting, but a pure Swift rethink is likely a lower priority than exposing bindings for existing cross-platform approaches (e.g. you mentinoed cairo). Like crypto, it might make sense to establish blessed wrappers/apinotes/overlays on top of tried-and-true open source offerings.

I think David Turnbull tried to get something like this started years back but it fizzled out pretty quick, probably because the Swift foss community was much smaller back then. Time to try again?

On Tue, Aug 1, 2017 at 8:29 AM, Georgios Moschovitis <george.moschovitis@icloud.com <mailto:george.moschovitis@icloud.com>> wrote:
> That's what's happened with the Server APIs Project
> https://swift.org/server-apis/
>
> I would like to see more of this, and math/BigNum seems like a good candidate.
>
> Another is a modern date/time package, standing on the shoulders of
> The Java Community Process(SM) Program - JSRs: Java Specification Requests - detail JSR# 310 <The Java Community Process(SM) Program - JSRs: Java Specification Requests - detail JSR# 310; and similar.

+ 1

I would also love to see standard implementation of Graph data structures, at least some common protocols.
Dunno why this versatile data structure is not included in standard libraries (similar to Map/Dictionary), Set, etc.

-g.

_______________________________________________
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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

47

I would, just not right now. There are more important issues to the larger community that need to be addressed before we (it might just be me :joy:) can start worrying about how to turn the equations from a math textbook into value swift code.

- Dave Sweeris

···

On Aug 2, 2017, at 4:29 PM, Nicolas Fezans <nicolas.fezans@gmail.com> wrote:

Your notation is indeed correct, even though using x on both side might confuse some people, this is correct. But no I would not go that far,

48

See, my problem with statements like this one, is that the answer
“should be supported as a third-party library” can also be interpreted as
“not my problem, go figure it out yourselves”. The idea that central entity
can only pay attention to what they want to, and the Community™ will
magically take care of the rest is one of the most pervasive, and untrue,
myths about open source. What’s worse, is that Swift has the benefit of
hindsight, in the form of many, many examples of languages that came before
and fell victim to this fallacy, and now have 15 competing “private”
classes for basic mathematical objects like *vectors*.

I agree that a core math library, for example, *could* in theory be
supported as a third-party library.

The core team has said that they're open to a core math library being
part of the Swift open source project; they just outlined that the
_process_ for doing so is best initiated with a third-party library as a
starting point.

But this will never happen on its own, for reasons that I will reiterate
here:

- no one influential enough has bothered to jump start any such project

Karoly Lorentey has a wonderful, and quite mature, BigInt project: <
https://github.com/lorentey/BigInt&gt;\. Also, as I mentioned, I just
started a project for protocol-based additions to Swift's basic numeric
types. These are just two examples.

- there are no avenues to encourage members of the community to come
together and organize a project (look how this thread got derailed!)

You're welcome to join me in my endeavor to create a math library. I'd
bet Karoly feels the same way about his project.

You don’t know how happy reading that sentence just made me, i’d assumed
no one was willing to team up to build such a thing. In which case, it’s a
good idea to start an incubator organization on Github. I think David
Turnbull tried doing that 2 years ago, I’ll reach out to him if he wants to
be a part of something like this.

We should also maintain an index of promising pure swift libraries so they
are discoverable (like docs.rs does for Rust).

I believe there has been mention on this list that the core team would like
to revisit this idea at some point.

- there is no “soft” infrastructure in place to support such
collaboration (look at the fuss over discourse and mailing list spam!)

The GitHub environment has excellent tools to support such collaboration,
IMO. For example:

Based on my experience implementing a library, I wrote a Gist to outline
some lessons learned and suggestions for improvement. Not only did the
document find an audience, these suggestions were in turn used to inform
core team-driven revisions to the integer protocols. As a result of these
revisions, it became possible to implement some initializers that could be
useful for people writing generic numeric algorithms. Recently, I submitted
a PR to the Swift project on GitHub to implement these initializers. Now,
everyone will be able to use them. Collaboration, positive feedback loop,
win-win for all involved.

Likewise, Karoly used his experience updating BigInt for Swift 4 to
inform certain improvements to the integer protocols. He implemented these
improvements in a series of PRs. Now, as a result of these developments,
Karoly's library will be better designed *and* everyone else will benefit
from a better implementation of the integer protocols. Again,
collaboration, positive feedback loop, win-win for all involved.

Great!! can you link me to the gist?

- there are no positive feedback loops whereby a promising project can

gain market share and mature
- because there is no organization backing these projects, potential
users are reluctant to depend on these libraries, since they will logically
bet that the library is more likely to fall out of maintenance than reach
maturity.

Addressing this point is clearly impossible. When Apple wishes to commit
its own resources to the maintenance of a Swift math library,
swift-corelibs-math will appear on GitHub. Suggestions such as opening an
empty repo and letting people contribute to it would either give the
illusion of organizational backing that doesn't exist or would in fact
commit Apple to support a repo that it doesn't wish to support. I fail to
see why the former is good for anybody; in fact, it's strictly inferior to
the same repo honestly representing itself as a third-party effort. And
asking for the latter is essentially asking Apple to create a Swift math
library--which, again, is not in the cards.

My point wasn’t really to exhort Apple to create a Swift math library,
just that people are more willing to depend on a library if the library’s
bus factor is greater than 1. A lot of great Swift packages in one one guy
or girl’s github repository who later disappeared. Turnbull’s SGLOpenGL
library is a good example of this; his library no longer compiles which
motivated me to write swift-opengl
<https://github.com/kelvin13/swift-opengl&gt;\. Then again, I’m sure people
feel the same way about depending on swift-opengl today as I felt about
depending on SGLOpenGL.

There just has so be some semblance of organization. That organization
doesn’t have to come from Apple or the swift core team. A community
initiative with sufficient momentum would be just as good. (The problem of
course is that it is rare for a community initiative to arise.)

Well, hang on now. There are plenty of products put out by even major
organizations that are unceremoniously and abruptly cut. There are plenty
of projects worked on by one or a few major people that are long-lived.
Projects that have longevity have some sort of financially sensible model
for their continued existence. Three, thirty, or even 300 unpaid people
working on an open-source project won't make it much more reliable (in the
eyes of others) than one unpaid person, and again I disagree that the
veneer of an organization is superior to presenting the status of the
project honestly. (Example--what is commonly thought to be a bigger threat
to Firefox's continued health: the possibility that there will be a
shortfall in unpaid contributors, or the possibility that there will be a
shortfall in funding?)

Rounding up all the goodwill on this list will not do you any good if your
goal is to convince users that a certain project will be maintained into
the future--because it won't rustle up a single dime. Whether or not you
explicitly equate these in your mind, "backing" == money, and if you want
this point addressed, you're claiming that someone somewhere should be
spending money on a Swift math library. I'm personally committed to making
sure that my code will work for the foreseeable future, but I fully accept
that there's simply no way for me to convince a sufficient number of people
of this fact without a credible showing of funding. In that sense, a
community initiative with "momentum" is decidedly not going to be a
just-as-good alternative to a core library.

···

On Wed, Aug 2, 2017 at 7:29 PM, Taylor Swift <kelvin13ma@gmail.com> wrote:

On Wed, Aug 2, 2017 at 7:54 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

On Wed, Aug 2, 2017 at 6:29 PM, Taylor Swift <kelvin13ma@gmail.com> >> wrote:

49

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.

···

On Wed, Aug 2, 2017 at 17:37 Nicolas Fezans <nicolas.fezans@gmail.com> wrote:

I would personally place a crypto library in category b).

For basic data structures, I would say probably something in between:
maybe a few data structures are worth having a nicer syntax that typical
method calls (just as are used for arrays and it looks and feels great)
but it would be pointless IMHO to try extending that to too many of these
data structures.

On Wed, Aug 2, 2017 at 11:08 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote:

On Wed, Aug 2, 2017 at 12:23 PM, Taylor Swift <kelvin13ma@gmail.com> >> wrote:

On Wed, Aug 2, 2017 at 12:45 PM, Gor Gyolchanyan < >>> gor.f.gyolchanyan@icloud.com> wrote:

On Aug 2, 2017, at 4:35 AM, Xiaodi Wu via swift-evolution < >>>> swift-evolution@swift.org> wrote:

On Tue, Aug 1, 2017 at 7:38 PM, Taylor Swift <kelvin13ma@gmail.com> >>>> wrote:

On Tue, Aug 1, 2017 at 5:50 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

On Tue, Aug 1, 2017 at 13:00 Taylor Swift via swift-evolution < >>>>>> swift-evolution@swift.org> wrote:

On Tue, Aug 1, 2017 at 1:51 PM, Michael Ilseman via swift-evolution >>>>>>> <swift-evolution@swift.org> wrote:

On Aug 1, 2017, at 10:44 AM, Tino Heth via swift-evolution < >>>>>>>> swift-evolution@swift.org> wrote:

So, this has been discussed before on the list many times in the
past. The core team has stated that their preferred process for this is to
have individuals write their own libraries, get real-world adoption, then
(as consensus emerges) propose their inclusion as a core library.

I already opened a new mail to write my answer, but than I thought
"wait, scroll down, and look if Xiaodi did already post links" ;-)
[But where have those potential core libraries been mentioned?]

Anyways, my perception hasn't change much:
I think it would be enough if someone from Apple would say "here's
an empty github-repo called
[math/statistics/algebra/crypto/graphic/image/audio/music/video/smtp/http…];
feel free to fork and create pull requests" and adding some democratic
mechanism for acceptance on top of it.

What would be your compatibility and stability expectations of such
APIs? If there are any expectations, then the APIs would need careful
design and thought. The Swift project faces a lot of design bandwidth
limitations, so prioritize is always tricky.

The point of spinning off separate core library working groups would
be so that library feature requests and proposals can stop clogging up
swift-evolution. Then the swift-evolution core team could focus on the
compiler and the standard library and the community would take stewardship
of the core libraries through separate channels.

My understanding is that the server working group, and all such work
groups, will be presenting their proposals here for approval, and that all
API changes in the Swift open source project go through this list.

That sounds like it would spam the general list a lot?

On the contrary, core team members have confirmed that working
proposals such as those are the principal intended use for this list; it is
*not* meant to be a general forum for musings about Swift language design.

My rule of thumb was that any post on the mailing list that I make has
to be aimed at providing a solution to a problem, or at the very least,
seeking help in providing a solution to a problem. If the discussion has no
definitive actionable outcome, then I consider it pointless.

At the same time, people should be able to float ideas here to see how
well they would be received before investing the energy into writing up a
proposal. I certainly wouldn’t spend time drafting up an entire API spec
for a math library without first checking that this is something that the
community actually wants.

I would mostly agree with that statement, except for the word "here."
Swift Evolution clearly isn't representative of the community of Swift
users generally; there are Slack channels, Reddit groups, and other forums
which are intended to be a place for general discussion, and which would
probably get you a good sense of what users want. I definitely agree with
Gor that the "actionable outcome" rule of thumb is a pretty good guideline
for what's most effective on this mailing list.

The other point I'd make here is that I definitely think the core team is
right about encouraging any "entire API spec" for a math library to be
based on implementation experience from actually writing a math library
that has seen good adoption. Essentially, what they're saying is that any
proposed design here should have already proved itself in the field. I
assume that you are well aware of Conway's law, which afaict has good
evidence to back it up; with that in mind, the end product that emerges
from a draft spec and an empty open-source repo is unlikely to be
satisfactory, let alone optimal.

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

50

You’re on very shaky ground here. It is not at all obvious that sin(A) should be the “elementwise” sine that you suggest, and not the matrix sine (defined by plugging A into the power series for sine, which is globally convergent). Depending on what branch of science/math you come from, one of these is “obviously” the right answer, but I assure you that it’s very much not obvious.

Yes, we want libraries to build this sort of thing to exist.

No, it’s not clear what the “right” way to expose some of these operations in the language/library are.

It is better to be verbose but correct than to be terse and cause bugs.

– Steve

···

On Aug 2, 2017, at 6:37 PM, Nicolas Fezans via swift-evolution <swift-evolution@swift.org> wrote:

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).

51

I agree. People tend to ignore the social factors present here and assume
that developers act perfectly rationally, then wonder why Swift library
support is so horrifically fragmented.

···

On Thu, Aug 3, 2017 at 3:21 AM, Tino Heth <2th@gmx.de> wrote:

You're welcome to join me in my endeavor to create a math library. I'd bet
Karoly feels the same way about his project.

See, exactly this is the big problem we are facing here — probably not in
your specific case, but in general:
It's not very appealing for most people to contribute to a small library
that's rarely known, instead of starting their own project to collect
github stars...

- Tino

52

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.

- Dave Sweeris

···

Sent from my iPad

On Aug 2, 2017, at 3:43 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

On Wed, Aug 2, 2017 at 17:37 Nicolas Fezans <nicolas.fezans@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.

53

See, my problem with statements like this one, is that the answer “should
be supported as a third-party library” can also be interpreted as “not my
problem, go figure it out yourselves”. The idea that central entity can
only pay attention to what they want to, and the Community™ will magically
take care of the rest is one of the most pervasive, and untrue, myths about
open source. What’s worse, is that Swift has the benefit of hindsight, in
the form of many, many examples of languages that came before and fell
victim to this fallacy, and now have 15 competing “private” classes for
basic mathematical objects like *vectors*.

I agree that a core math library, for example, *could* in theory be
supported as a third-party library. But this will never happen on its own,
for reasons that I will reiterate here:

- no one influential enough has bothered to jump start any such project
- there are no avenues to encourage members of the community to come
together and organize a project (look how this thread got derailed!)
- there is no “soft” infrastructure in place to support such collaboration
(look at the fuss over discourse and mailing list spam!)
- there are no positive feedback loops whereby a promising project can gain
market share and mature
- because there is no organization backing these projects, potential users
are reluctant to depend on these libraries, since they will logically bet
that the library is more likely to fall out of maintenance than reach
maturity.
- everyone works on their own in-house “half-assed” implementation, and
people are not encouraged to come together and pool resources so instead
there is a lot of duplicated work

···

On Wed, Aug 2, 2017 at 6:42 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

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.

54

Well that there is a rather defeatist attitude. If you are correct that
Apple-funded development is the only way to get core libraries built (and
maintained), and Apple has expressed they have no intention of doing so,
then we are all pretty much f****d.

···

On Wed, Aug 2, 2017 at 9:18 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

On Wed, Aug 2, 2017 at 7:29 PM, Taylor Swift <kelvin13ma@gmail.com> wrote:

On Wed, Aug 2, 2017 at 7:54 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

On Wed, Aug 2, 2017 at 6:29 PM, Taylor Swift <kelvin13ma@gmail.com> >>> wrote:

See, my problem with statements like this one, is that the answer
“should be supported as a third-party library” can also be interpreted as
“not my problem, go figure it out yourselves”. The idea that central entity
can only pay attention to what they want to, and the Community™ will
magically take care of the rest is one of the most pervasive, and untrue,
myths about open source. What’s worse, is that Swift has the benefit of
hindsight, in the form of many, many examples of languages that came before
and fell victim to this fallacy, and now have 15 competing “private”
classes for basic mathematical objects like *vectors*.

I agree that a core math library, for example, *could* in theory be
supported as a third-party library.

The core team has said that they're open to a core math library being
part of the Swift open source project; they just outlined that the
_process_ for doing so is best initiated with a third-party library as a
starting point.

But this will never happen on its own, for reasons that I will
reiterate here:

- no one influential enough has bothered to jump start any such project

Karoly Lorentey has a wonderful, and quite mature, BigInt project: <
https://github.com/lorentey/BigInt&gt;\. Also, as I mentioned, I just
started a project for protocol-based additions to Swift's basic numeric
types. These are just two examples.

- there are no avenues to encourage members of the community to come
together and organize a project (look how this thread got derailed!)

You're welcome to join me in my endeavor to create a math library. I'd
bet Karoly feels the same way about his project.

You don’t know how happy reading that sentence just made me, i’d assumed
no one was willing to team up to build such a thing. In which case, it’s a
good idea to start an incubator organization on Github. I think David
Turnbull tried doing that 2 years ago, I’ll reach out to him if he wants to
be a part of something like this.

We should also maintain an index of promising pure swift libraries so
they are discoverable (like docs.rs does for Rust).

I believe there has been mention on this list that the core team would
like to revisit this idea at some point.

- there is no “soft” infrastructure in place to support such
collaboration (look at the fuss over discourse and mailing list spam!)

The GitHub environment has excellent tools to support such
collaboration, IMO. For example:

Based on my experience implementing a library, I wrote a Gist to outline
some lessons learned and suggestions for improvement. Not only did the
document find an audience, these suggestions were in turn used to inform
core team-driven revisions to the integer protocols. As a result of these
revisions, it became possible to implement some initializers that could be
useful for people writing generic numeric algorithms. Recently, I submitted
a PR to the Swift project on GitHub to implement these initializers. Now,
everyone will be able to use them. Collaboration, positive feedback loop,
win-win for all involved.

Likewise, Karoly used his experience updating BigInt for Swift 4 to
inform certain improvements to the integer protocols. He implemented these
improvements in a series of PRs. Now, as a result of these developments,
Karoly's library will be better designed *and* everyone else will benefit
from a better implementation of the integer protocols. Again,
collaboration, positive feedback loop, win-win for all involved.

Great!! can you link me to the gist?

Notes on the user experience of new integer protocols · GitHub

- there are no positive feedback loops whereby a promising project can

gain market share and mature
- because there is no organization backing these projects, potential
users are reluctant to depend on these libraries, since they will logically
bet that the library is more likely to fall out of maintenance than reach
maturity.

Addressing this point is clearly impossible. When Apple wishes to commit
its own resources to the maintenance of a Swift math library,
swift-corelibs-math will appear on GitHub. Suggestions such as opening an
empty repo and letting people contribute to it would either give the
illusion of organizational backing that doesn't exist or would in fact
commit Apple to support a repo that it doesn't wish to support. I fail to
see why the former is good for anybody; in fact, it's strictly inferior to
the same repo honestly representing itself as a third-party effort. And
asking for the latter is essentially asking Apple to create a Swift math
library--which, again, is not in the cards.

My point wasn’t really to exhort Apple to create a Swift math library,
just that people are more willing to depend on a library if the library’s
bus factor is greater than 1. A lot of great Swift packages in one one guy
or girl’s github repository who later disappeared. Turnbull’s SGLOpenGL
library is a good example of this; his library no longer compiles which
motivated me to write swift-opengl
<https://github.com/kelvin13/swift-opengl&gt;\. Then again, I’m sure people
feel the same way about depending on swift-opengl today as I felt about
depending on SGLOpenGL.

There just has so be some semblance of organization. That organization
doesn’t have to come from Apple or the swift core team. A community
initiative with sufficient momentum would be just as good. (The problem of
course is that it is rare for a community initiative to arise.)

Well, hang on now. There are plenty of products put out by even major
organizations that are unceremoniously and abruptly cut. There are plenty
of projects worked on by one or a few major people that are long-lived.
Projects that have longevity have some sort of financially sensible model
for their continued existence. Three, thirty, or even 300 unpaid people
working on an open-source project won't make it much more reliable (in the
eyes of others) than one unpaid person, and again I disagree that the
veneer of an organization is superior to presenting the status of the
project honestly. (Example--what is commonly thought to be a bigger threat
to Firefox's continued health: the possibility that there will be a
shortfall in unpaid contributors, or the possibility that there will be a
shortfall in funding?)

Rounding up all the goodwill on this list will not do you any good if your
goal is to convince users that a certain project will be maintained into
the future--because it won't rustle up a single dime. Whether or not you
explicitly equate these in your mind, "backing" == money, and if you want
this point addressed, you're claiming that someone somewhere should be
spending money on a Swift math library. I'm personally committed to making
sure that my code will work for the foreseeable future, but I fully accept
that there's simply no way for me to convince a sufficient number of people
of this fact without a credible showing of funding. In that sense, a
community initiative with "momentum" is decidedly not going to be a
just-as-good alternative to a core library.

55

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

···

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.fezans@gmail.com <mailto:nicolas.fezans@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.

56

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.

Thinking again about it, I guess this requirement is less often required
than I originally had in mind. Things like subselections (slicing) and
concatenation operations might need an adequate syntax:

[A B; C D; ...]

would build a new matrix in Julia and also in Matlab based on the scalar or
matrix elements A B C D... and will often be combined several times in the
same command (here ... is a continuation symbol)

A =[ -0.2122 -0.1220 -0.3183 1.1845 -1.3455 1.9629; ...

             zeros(1,3) -0.3183 2.4862 2.6483; ...

      0.1311 -0.1229 -0.2264 -0.3743 2.0005 0.0996];

B =[ [-0.2122 -0.1220 -0.3183; zeros(1,3) ; 0.1311 -0.1229 -0.2264]
[1.1845 -1.3455 1.9629; -0.3183 2.4862 2.6483; -0.3743 2.0005
0.0996] ];

or write something like this to replace some elements of B, with ones +
some of the elements of A ( here 1:2 is a bit like 1...2 in Swift, expect
that you can write 1:end-1 to get all but the last one or making the union
of the several ranges as you concatenate vectors.

B(1:2,2:3) = ones(2,2) + A(2:3,1:2)' ;

···

On Thu, Aug 3, 2017 at 12:42 AM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

On Wed, Aug 2, 2017 at 17:37 Nicolas Fezans <nicolas.fezans@gmail.com> > wrote:

I would personally place a crypto library in category b).

For basic data structures, I would say probably something in between:
maybe a few data structures are worth having a nicer syntax that typical
method calls (just as are used for arrays and it looks and feels great)
but it would be pointless IMHO to try extending that to too many of these
data structures.

On Wed, Aug 2, 2017 at 11:08 PM, Xiaodi Wu via swift-evolution < >> swift-evolution@swift.org> wrote:

On Wed, Aug 2, 2017 at 12:23 PM, Taylor Swift <kelvin13ma@gmail.com> >>> wrote:

On Wed, Aug 2, 2017 at 12:45 PM, Gor Gyolchanyan < >>>> gor.f.gyolchanyan@icloud.com> wrote:

On Aug 2, 2017, at 4:35 AM, Xiaodi Wu via swift-evolution < >>>>> swift-evolution@swift.org> wrote:

On Tue, Aug 1, 2017 at 7:38 PM, Taylor Swift <kelvin13ma@gmail.com> w
rote:

On Tue, Aug 1, 2017 at 5:50 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote
:

On Tue, Aug 1, 2017 at 13:00 Taylor Swift via swift-evolution < >>>>>>> swift-evolution@swift.org> wrote:

On Tue, Aug 1, 2017 at 1:51 PM, Michael Ilseman via swift-evolution >>>>>>>> <swift-evolution@swift.org> wrote:

On Aug 1, 2017, at 10:44 AM, Tino Heth via swift-evolution < >>>>>>>>> swift-evolution@swift.org> wrote:

So, this has been discussed before on the list many times in the
past. The core team has stated that their preferred process for this is to
have individuals write their own libraries, get real-world adoption, then
(as consensus emerges) propose their inclusion as a core library.

I already opened a new mail to write my answer, but than I thought
"wait, scroll down, and look if Xiaodi did already post links" ;-)
[But where have those potential core libraries been mentioned?]

Anyways, my perception hasn't change much:
I think it would be enough if someone from Apple would say "here's
an empty github-repo called [math/statistics/algebra/
crypto/graphic/image/audio/music/video/smtp/http…]; feel free to
fork and create pull requests" and adding some democratic mechanism for
acceptance on top of it.

What would be your compatibility and stability expectations of
such APIs? If there are any expectations, then the APIs would need careful
design and thought. The Swift project faces a lot of design bandwidth
limitations, so prioritize is always tricky.

The point of spinning off separate core library working groups
would be so that library feature requests and proposals can stop clogging
up swift-evolution. Then the swift-evolution core team could focus on the
compiler and the standard library and the community would take stewardship
of the core libraries through separate channels.

My understanding is that the server working group, and all such work
groups, will be presenting their proposals here for approval, and that all
API changes in the Swift open source project go through this list.

That sounds like it would spam the general list a lot?

On the contrary, core team members have confirmed that working
proposals such as those are the principal intended use for this list; it is
*not* meant to be a general forum for musings about Swift language design.

My rule of thumb was that any post on the mailing list that I make has
to be aimed at providing a solution to a problem, or at the very least,
seeking help in providing a solution to a problem. If the discussion has no
definitive actionable outcome, then I consider it pointless.

At the same time, people should be able to float ideas here to see how
well they would be received before investing the energy into writing up a
proposal. I certainly wouldn’t spend time drafting up an entire API spec
for a math library without first checking that this is something that the
community actually wants.

I would mostly agree with that statement, except for the word "here."
Swift Evolution clearly isn't representative of the community of Swift
users generally; there are Slack channels, Reddit groups, and other forums
which are intended to be a place for general discussion, and which would
probably get you a good sense of what users want. I definitely agree with
Gor that the "actionable outcome" rule of thumb is a pretty good guideline
for what's most effective on this mailing list.

The other point I'd make here is that I definitely think the core team
is right about encouraging any "entire API spec" for a math library to be
based on implementation experience from actually writing a math library
that has seen good adoption. Essentially, what they're saying is that any
proposed design here should have already proved itself in the field. I
assume that you are well aware of Conway's law, which afaict has good
evidence to back it up; with that in mind, the end product that emerges
from a draft spec and an empty open-source repo is unlikely to be
satisfactory, let alone optimal.

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

57

I don’t think we should be designing interfaces based off of what pure
mathematicians write. Scientists aren’t the only people who use sin(x).
It’s better to go with the “common sense” behavior than the esoteric
academic notation. And for the record, I think Matrix.map(sin(_:)) is the
best and most clear interface for elementwise sin.

···

On Thu, Aug 3, 2017 at 7:00 AM, Stephen Canon via swift-evolution < swift-evolution@swift.org> wrote:

On Aug 2, 2017, at 6:37 PM, Nicolas Fezans via swift-evolution < > swift-evolution@swift.org> wrote:

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).

You’re on very shaky ground here. It is not at all obvious that sin(A)
should be the “elementwise” sine that you suggest, and not the matrix sine
(defined by plugging A into the power series for sine, which is globally
convergent). Depending on what branch of science/math you come from, one of
these is “obviously” the right answer, but I assure you that it’s very much
not obvious.

Yes, we want libraries to build this sort of thing to exist.

No, it’s not clear what the “right” way to expose some of these operations
in the language/library are.

It is better to be verbose but correct than to be terse and cause bugs.

– Steve

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

58

That's not what I'm saying at all. I'm responding to your contention that
no library without "backing" will see wide adoption: if, as you say, you
would like to have a math library with sufficient "backing," then realize
that you're arguing for someone to devote financial resources to the
problem. Your proposed solution of getting together a bunch of unpaid
people does not address your identified problem.

···

On Wed, Aug 2, 2017 at 21:07 Taylor Swift <kelvin13ma@gmail.com> wrote:

On Wed, Aug 2, 2017 at 9:18 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

On Wed, Aug 2, 2017 at 7:29 PM, Taylor Swift <kelvin13ma@gmail.com> >> wrote:

On Wed, Aug 2, 2017 at 7:54 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

On Wed, Aug 2, 2017 at 6:29 PM, Taylor Swift <kelvin13ma@gmail.com> >>>> wrote:

See, my problem with statements like this one, is that the answer
“should be supported as a third-party library” can also be interpreted as
“not my problem, go figure it out yourselves”. The idea that central entity
can only pay attention to what they want to, and the Community™ will
magically take care of the rest is one of the most pervasive, and untrue,
myths about open source. What’s worse, is that Swift has the benefit of
hindsight, in the form of many, many examples of languages that came before
and fell victim to this fallacy, and now have 15 competing “private”
classes for basic mathematical objects like *vectors*.

I agree that a core math library, for example, *could* in theory be
supported as a third-party library.

The core team has said that they're open to a core math library being
part of the Swift open source project; they just outlined that the
_process_ for doing so is best initiated with a third-party library as a
starting point.

But this will never happen on its own, for reasons that I will
reiterate here:

- no one influential enough has bothered to jump start any such
project

Karoly Lorentey has a wonderful, and quite mature, BigInt project: <
https://github.com/lorentey/BigInt&gt;\. Also, as I mentioned, I just
started a project for protocol-based additions to Swift's basic numeric
types. These are just two examples.

- there are no avenues to encourage members of the community to come
together and organize a project (look how this thread got derailed!)

You're welcome to join me in my endeavor to create a math library. I'd
bet Karoly feels the same way about his project.

You don’t know how happy reading that sentence just made me, i’d assumed
no one was willing to team up to build such a thing. In which case, it’s a
good idea to start an incubator organization on Github. I think David
Turnbull tried doing that 2 years ago, I’ll reach out to him if he wants to
be a part of something like this.

We should also maintain an index of promising pure swift libraries so
they are discoverable (like docs.rs does for Rust).

I believe there has been mention on this list that the core team would
like to revisit this idea at some point.

- there is no “soft” infrastructure in place to support such
collaboration (look at the fuss over discourse and mailing list spam!)

The GitHub environment has excellent tools to support such
collaboration, IMO. For example:

Based on my experience implementing a library, I wrote a Gist to
outline some lessons learned and suggestions for improvement. Not only did
the document find an audience, these suggestions were in turn used to
inform core team-driven revisions to the integer protocols. As a result of
these revisions, it became possible to implement some initializers that
could be useful for people writing generic numeric algorithms. Recently, I
submitted a PR to the Swift project on GitHub to implement these
initializers. Now, everyone will be able to use them. Collaboration,
positive feedback loop, win-win for all involved.

Likewise, Karoly used his experience updating BigInt for Swift 4 to
inform certain improvements to the integer protocols. He implemented these
improvements in a series of PRs. Now, as a result of these developments,
Karoly's library will be better designed *and* everyone else will benefit
from a better implementation of the integer protocols. Again,
collaboration, positive feedback loop, win-win for all involved.

Great!! can you link me to the gist?

Notes on the user experience of new integer protocols · GitHub

- there are no positive feedback loops whereby a promising project can

gain market share and mature
- because there is no organization backing these projects, potential
users are reluctant to depend on these libraries, since they will logically
bet that the library is more likely to fall out of maintenance than reach
maturity.

Addressing this point is clearly impossible. When Apple wishes to
commit its own resources to the maintenance of a Swift math library,
swift-corelibs-math will appear on GitHub. Suggestions such as opening an
empty repo and letting people contribute to it would either give the
illusion of organizational backing that doesn't exist or would in fact
commit Apple to support a repo that it doesn't wish to support. I fail to
see why the former is good for anybody; in fact, it's strictly inferior to
the same repo honestly representing itself as a third-party effort. And
asking for the latter is essentially asking Apple to create a Swift math
library--which, again, is not in the cards.

My point wasn’t really to exhort Apple to create a Swift math library,
just that people are more willing to depend on a library if the library’s
bus factor is greater than 1. A lot of great Swift packages in one one guy
or girl’s github repository who later disappeared. Turnbull’s SGLOpenGL
library is a good example of this; his library no longer compiles which
motivated me to write swift-opengl
<https://github.com/kelvin13/swift-opengl&gt;\. Then again, I’m sure people
feel the same way about depending on swift-opengl today as I felt about
depending on SGLOpenGL.

There just has so be some semblance of organization. That organization
doesn’t have to come from Apple or the swift core team. A community
initiative with sufficient momentum would be just as good. (The problem of
course is that it is rare for a community initiative to arise.)

Well, hang on now. There are plenty of products put out by even major
organizations that are unceremoniously and abruptly cut. There are plenty
of projects worked on by one or a few major people that are long-lived.
Projects that have longevity have some sort of financially sensible model
for their continued existence. Three, thirty, or even 300 unpaid people
working on an open-source project won't make it much more reliable (in the
eyes of others) than one unpaid person, and again I disagree that the
veneer of an organization is superior to presenting the status of the
project honestly. (Example--what is commonly thought to be a bigger threat
to Firefox's continued health: the possibility that there will be a
shortfall in unpaid contributors, or the possibility that there will be a
shortfall in funding?)

Rounding up all the goodwill on this list will not do you any good if
your goal is to convince users that a certain project will be maintained
into the future--because it won't rustle up a single dime. Whether or not
you explicitly equate these in your mind, "backing" == money, and if you
want this point addressed, you're claiming that someone somewhere should be
spending money on a Swift math library. I'm personally committed to making
sure that my code will work for the foreseeable future, but I fully accept
that there's simply no way for me to convince a sufficient number of people
of this fact without a credible showing of funding. In that sense, a
community initiative with "momentum" is decidedly not going to be a
just-as-good alternative to a core library.

Well that there is a rather defeatist attitude. If you are correct that
Apple-funded development is the only way to get core libraries built (and
maintained), and Apple has expressed they have no intention of doing so,
then we are all pretty much f****d.

59

sin/cos/etc are implemented in software, not hardware. x86 does have the FSIN/FCOS instructions, but (almost) no one actually uses them to implement the sin( ) and cos( ) functions; they are a legacy curiosity, both too slow and too inaccurate for serious use today. There are no analogous instructions on ARM or PPC.

– Steve

···

On Aug 2, 2017, at 7:03 PM, Karl Wagner via swift-evolution <swift-evolution@swift.org> wrote:

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.

60

Well that there is a rather defeatist attitude. If you are correct that Apple-funded development is the only way to get core libraries built (and maintained), and Apple has expressed they have no intention of doing so, then we are all pretty much f****d.

I don't think Apple-funded development is the only way — it's just that the alternative takes much more time.
But ihmo the funding don't has to be large:
I wonder what would happen if Ted picked a random Swift developer, and gave him the maintainer credentials for an empty Result<T>-repo on the official github page of Swift...