[swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

Wed Aug 2 17:42:58 CDT 2017

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

>
> 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 at swift.org> wrote:
>
>>
>>
>> On Wed, Aug 2, 2017 at 12:23 PM, Taylor Swift <kelvin13ma at gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Wed, Aug 2, 2017 at 12:45 PM, Gor Gyolchanyan <
>>> gor.f.gyolchanyan at icloud.com> wrote:
>>>
>>>>
>>>> On Aug 2, 2017, at 4:35 AM, Xiaodi Wu via swift-evolution <
>>>> swift-evolution at swift.org> wrote:
>>>>
>>>> On Tue, Aug 1, 2017 at 7:38 PM, Taylor Swift <kelvin13ma at gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Tue, Aug 1, 2017 at 5:50 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>>>>>
>>>>>>
>>>>>> On Tue, Aug 1, 2017 at 13:00 Taylor Swift via swift-evolution <
>>>>>> swift-evolution at swift.org> wrote:
>>>>>>
>>>>>>> On Tue, Aug 1, 2017 at 1:51 PM, Michael Ilseman via swift-evolution
>>>>>>> <swift-evolution at swift.org> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Aug 1, 2017, at 10:44 AM, Tino Heth via swift-evolution <
>>>>>>>> swift-evolution at 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 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/20170802/a4f53c4b/attachment.html>