[Swift-devel] Standard Library Proposal/Discussion Page

[Tim Armstrong]

RE: log/ln/log10

I think this is pretty varied.  I've seen contexts where log() meant either
log_e, log_2, or log_10.

The completely unambiguous way would be to have ln(x), log(x, base) and
optionally log10(x)

On Wed, Jan 21, 2015 at 12:17 PM, Tim Armstrong <tim.g.armstrong at gmail.com>
wrote:

> 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/9bb0837f/attachment.html>