[Swift-devel] Standard Library Proposal/Discussion Page

[Tim Armstrong]

sqrt and pow may use different algorithms and provide slightly different
numerical guarantees even if they're mathematically the same.

I agree cbrt is pretty marginal, I've never used that personally.

What is the difference between a standard library and an auxiliary library
that is shipped with Swift?  If both are shipped with Swift and both are
documented in the user guide, it seems like a very minor distinction and
I'm not sure what it buys us.  Factoring the functions into appropriate
libraries and then documenting any caveats seems sufficient to me, but
maybe I'm missing something.

RE: Mike's query about stats functions.  The functions aren't necessarily
equivalent performance-wise or numerically in practice even if they are
algebraically.  E.g. sum(A) / size(A) isn't always a good way to compute
avg(A) because of rounding and overflow concerns.  I think there's a strong
argument for providing solid, numerically sound implementations of common
stats functions in Swift if they're likely to see usage.

Better support for reduces and loops would allow more to be implemented in
Swift I think too.

- Tim



On Wed, Jan 21, 2015 at 10:03 AM, Ketan Maheshwari <ketan at mcs.anl.gov>
wrote:

>
> On Wed, Jan 21, 2015 at 2:13 AM, Hategan-Marandiuc, Philip M. <
> hategan at mcs.anl.gov> wrote:
>
>> On Tue, 2015-01-20 at 21:59 -0600, Ketan Maheshwari wrote:
>> > Neat!
>> >
>> > Comments:
>> >
>> > -- Statistical functions in a standard library seem out of place to me.
>> One
>> > may ask, why just stop with statistical functions and not also include
>> > vector and matrix related functions such as cross and dot products or
>> > fancier stuff like finding eigen values, etc.
>>
>> They were in Swift/T and I thought they were useful. Dot products can be
>> done with the zip() function. Cross products can be done with two nested
>> foreach loops (although I did consider an outer join function). There
>> are way too many ways to calculate eigenvalues efficiently, and there
>> are also all kinds of weird algorithms to do so when you need only some
>> eigenvalues, either the smallest or the largest. So I don't think we
>> should get into that business.
>>
>> So I think the bottom line is that if there is something that is likely
>> helpful for a lot of users and doesn't require a lot of work, then we
>> should probably have it there.
>>
>
> I understand the utility. My point was that may be we should move these
> functions out of standard library and put in another library, say auxiliary
> or something. As Mike mentioned in his reply, it would be nice if a
> canonical set of core functions are placed and locked in the standard
> library.
>
>
>>
>> >
>> > -- sqrt and cbrt seem redundant as we already provide pow with float
>> > exponent.
>>
>> True. But it looks like most languages provide all of them anyway  (I
>> can't really think of a language that doesn't have sqrt). I guess it's
>> just nicer to write sqrt(2) than of pow(2, 0.5).
>>
>
> True for sqrt, not so much for cbrt though.
>
>
>>
>> Mihael
>>
>> >
>> > Regards,
>> > Ketan
>> >
>> > On Tue, Jan 20, 2015 at 6:56 PM, Mihael Hategan <hategan at mcs.anl.gov>
>> wrote:
>> >
>> > > Hi,
>> > >
>> > > I made a wiki page on github where we could discuss the standard
>> > > library: https://github.com/swift-lang/swift-k/wiki/StandardLibrary
>> > >
>> > > It's a draft and there are some rough edges. In particular:
>> > >
>> > > - regular expression support: substitutions can be done either
>> directly
>> > > or with a combination between a function that returns capture groups
>> and
>> > > a formatting function that replaces certain tokens with elements of an
>> > > array. One could overload the format() function to, in addition to
>> > > standard formatting specs, also support something like %s[index]. Or
>> > > have a separate formatting function that only deals with this specific
>> > > problem. I'm not sure.
>> > >
>> > > - some of the array functions may be difficult to implement as
>> > > specified, or there may be different functions that solve the problems
>> > > better. In particular when joining arrays of arrays, there is some
>> > > freedom in how to order the elements of the resulting array.
>> > >
>> > > - read and write: it may not be easy to implement a read that can
>> return
>> > > any type in T. There is some precedent in other languages that support
>> > > serialization for this.
>> > >
>> > > Anyway, I added red exclamation marks and red question marks where
>> > > things aren't quite clear.
>> > >
>> > > I'm assuming that most of us will agree on most of the things.
>> However,
>> > > if you have a wildly different proposal, it might be wise to create
>> > > another page instead of editing this one.
>> > >
>> > > Mihael
>> > >
>> > > _______________________________________________
>> > > Swift-devel mailing list
>> > > Swift-devel at ci.uchicago.edu
>> > > https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel
>> > >
>>
>>
>>
>
> _______________________________________________
> Swift-devel mailing list
> Swift-devel at ci.uchicago.edu
> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20150121/aa60e0a4/attachment.html>