[swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

Wed Aug 2 18:07:26 CDT 2017

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

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

>>
>> 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> w
>>>>> rote:
>>>>>
>>>>>>
>>>>>>
>>>>>> 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/20170803/c552467a/attachment.html>