[Accepted with Modifications] SE-0246: Generic Math Functions

John_McCall · 2019-03-28T23:21:57.755Z

I shouldn't have mentioned logE; I think it unfortunately led people to think that we were considering new names for log. The review is closed.

Karl · 2019-03-29T04:19:13.149Z

Maybe we should have an evolution sub-forum for 'indicative votes', indicating what the community does/does not like (despite the link, it's a serious suggestion, if we think it would result in better proposals for review).

I think this proposal should have gone through another round. Even if it was just a formality with everybody saying "+1".

I wonder as well about how easy it is for the core team to collate the feedback when some of it is for revision A and some refer to issues with revision B which may have been partially addressed in revision C. If I was presented with that kind of feedback, I'm not sure how I would combine it to figure out the overall community sentiment for revision D. It's just more difficult for everybody if the target is moving and shape-shifting.

xwu · 2019-03-29T12:03:27.846Z

Karl:

Maybe we should have an evolution sub-forum for 'indicative votes' , indicating what the community does/does not like (despite the link, it's a serious suggestion, if we think it would result in better proposals for review).

I think this proposal should have gone through another round. Even if it was just a formality with everybody saying "+1".

We should have respect for everyone's contributions, proceeding with the starting point that everyone has limited time, and any feedback given once should be sufficient to make that point of view heard and should be taken to apply to all iterations of the proposal.

That said I don't think this community is even close to being representative of Swift users in general; therefore, it's always important to keep in mind that this process is not a vote, and "+1" comments are not encouraged. As a community we do not approve or reject proposals: we review them and our comments are considered in the core team's decision.

jawbroken · 2019-04-01T02:07:40.183Z

These seem directly at odds with each other:

Karl:

It is also disrespectful to community members. We do not have infinite time to evaluate and re-evaluate proposals.

Karl:

I think this proposal should have gone through another round. Even if it was just a formality with everybody saying "+1".

The proposal already went through a pitch phase. Additional concerns were raised during the review phase. I'm having trouble working out how you would have preferred them to be addressed.

I also find these accusations of bias somewhat rude, and I'm not sure they are well-founded. Do you have examples of non-Apple authors being treated differently here? This isn't the first time (very) minor changes have been made to a proposal during review, and the review period was extended to give everyone more time to respond.

dcdemars · 2019-04-01T02:13:13.812Z

Just to amplify the precedence argument for "log", the following languages use "log" to mean natural logarithm:

Fortran
C
Matlab (scripting language)
Python
Mathematica (actually "Log")

Of course there are many other examples (Ada, anyone?) but I think most of the mathematical and engineering oriented code written since, well, the invention of high level languages has probably been written in one of the languages listed above.

I think it is unlikely that defining "log" as natural logarithm will cause much confusion.

Letan · 2019-04-01T11:41:32.875Z

Right. But this is only true for people that have been programming and are new to Swift. This is not true for people who are new to programming and new to Swift.

My argument for confusion, although it's more like an argument against a subtle bug, is that: People who confuse log for something like log10 will have a subtle bug in their code that's hard to debug because it's a semantic error.

I understand that there's a lot of history in programming languages and there will certainly be a lot of annoyance from people who aren't new to programming.

But I see this as a net gain. Some people, possibly more, getting annoyed because log has been renamed, versus newcomers, spending time trying to find a very subtle bug because the function they know from a textbook is something else in the language.

But all this said it looks like the decision is made. And I can't say that I'm unhappy with the overall result of the proposal. Thanks, @scanon I can finally remove all of my import Darwin's

yxckjhasdkjh · 2019-04-01T12:05:14.379Z

Letan:

My argument for confusion, although it's more like an argument against a subtle bug, is that: People who confuse log for something like log10 will have a subtle bug in their code that's hard to debug because it's a semantic error.

That's why you write tests; using the wrong base for a logarithm doesn't give you "weird edge case bugs", it just breaks the behaviour altogether, so you'd very likely catch that. Also, I would assume that the people that aren't aware that there are multiple bases for logarithms, probably also aren't the people that would know what a logarithm is in the first place and are therefore unlikely to reach for one.

And the "textbook argument" could really go either way, because computer scientists will generally use "log base 2", physicists might use "log base 10" and mathematicians generally "log base e".

Letan · 2019-04-01T12:49:19.394Z

yxckjhasdkjh:

That's why you write tests

Not if you're trying stuff out, writing a simple little script or even just playing around.

yxckjhasdkjh:

using the wrong base for a logarithm doesn't give you "weird edge case bugs", it just breaks the behaviour altogether, so you'd very likely catch that

When it's used in a larger context it's harder to find because it does give you a 'valid' result which may be subtly different from what you expect.

yxckjhasdkjh:

Also, I would assume that the people that aren't aware that there are multiple bases for logarithms, probably also aren't the people that would know what a logarithm is in the first place and are therefore unlikely to reach for one

I'm saying that log is commonly used to refer to a different base to different people. I've only seen log used as log2 for complexity, everything else has used log to refer to log10 for example.

I was simply arguing to remove this ambiguity for everyone by making it explicit which log a person is referring to. I don't even care that much we call log ln instead, just so long that it's not ambiguous.

rex-remind · 2019-04-04T02:10:51.301Z

I apologize for being late to this, but I'd very much appreciate more detail on how this affects source compatibility. Given that these new functions are gated to Swift 5.1 and Darwin functions are deprecated, does this mean I will be required to include @available wherever I use math functions in iOS for the next 3-4 years just to support iOS 12.2 for that period?

scanon · 2019-04-04T02:49:43.428Z

rex-remind:

Given that these new functions are gated to Swift 5.1 and Darwin functions are deprecated, does this mean I will be required to include @available wherever I use math functions in iOS for the next 3-4 years just to support iOS 12.2 for that period?

No.

First off, deprecated is not the same as removed or obsoleted, so you will not have to move away from using the Darwin functions yet anyway.

More importantly, part of dropping the Math module is that these functions will not be gated to 5.1. They are (with one exception) unconditionally available. You can just use them. If you have imported the Platform module (or more likely Foundation), you will end up with the definitions there in some cases, but your sources will work without needing to do any @available hacks.

The only exception to that is sqrt, because the generic constraint for the free function changes from FloatingPoint to ElementaryFunctions. For concrete uses this will not matter; if you are using swift < 5.1, you get the old one, if it's >= 5.1 you get the new one. Code that is generic on FloatingPoint and compiles with swift >= 5.1 will either need to switch to being generic on Real (which you probably want to do anyway) or use .squareRoot() or .sqrt() instead. This is an annoyance, but hopefully an extremely minor one.

At some point (maybe 5.1, maybe later, this is still being discussed somewhat), we will start obsoleting existing math functions in the Darwin module. When this happens, if you are using fully-qualified names like Darwin.acos(x), you will need to use the new stdlib names (Swift.acos(x) or acos(x)), but again, very few users should hopefully find themselves in this situation. Or if we get the ability to reexport specific interfaces from another module, we may never need to do this.

xwu · 2019-04-04T03:04:29.765Z

scanon:

The only exception to that is sqrt , because the generic constraint for the free function changes from FloatingPoint to Real .

Huh. ~~Why did we make this change?~~ Ah, you mean ElementaryFunctions.

Coeur · 2019-04-15T18:15:50.235Z

Talking about naming, I would have preferred squareRoot over sqrt. With an IDE like Xcode, tapping s-q-r-t would still allow auto-completion to the readable form of squareRoot.

With those old C names like sqrt, you can't tell if it's a mutable or non-mutable function, and you wouldn't know how to name the counterpart. Are we going to have a formSqrt for instance as a mutable version of the same function?

scanon · 2019-04-15T18:39:39.456Z

Coeur:

With those old C names like sqrt , you can't tell if it's a mutable or non-mutable function, and you wouldn't know how to name the counterpart. Are we going to have a formSqrt for instance as a mutable version of the same function?

For free functions, there are no mutating variants, so this isn't an issue. For the implementation hooks (statics), there is again no way to have a mutating version. I.e., these new operations appear either as sqrt(x) or Float.sqrt(x). There's no way either of those can be mutating, so no confusion is possible.

Even the existing method x.formSquareRoot( ) was probably ill-considered because it doesn't offer any efficiency wins, but everyone was quite gung-ho about testing out the edges of the naming conventions at that point. It's a vestigial curiosity now that we might deprecate at some future point.

Bjoern · 2019-09-24T07:02:00.771Z

Hi all,
is there any update what happened to the SE-0246: Generic Math Functions proposal?

scanon · 2019-09-24T18:22:24.366Z

Yes. There are some issues that were exposed with type checker performance and source stability that caused us to move it out of 5.1. Specifically:

we cannot easily eliminate the existing concrete functions in the Glibc/Darwin/etc modules because of source and binary stability concerns. These have the same names as many of the new functions, which causes some type checker regressions. Most of these regressions are small, but there are some bad cases that we haven't have time to address yet.
there's a type checker bug involving overload resolution; static member functions are always preferred to free functions, which means that existing code like:
```
extension Double {
  func foo() -> Double {
    log10(self)
  }
}
```
would fail to compile (because the static log10 cannot be used without calling it as Double.log10, but is still preferred in name lookup, so the type checker doesn't find the existing free function). This is a bug, but we can't land the change until it is fixed, and we didn't have time to do so for 5.1.

Once we get the necessary type checker improvements to unblock these changes, I'll re-propose them.

Ben_Cohen · 2019-11-07T21:38:16.380Z

Core Team Update on SE-0246

Hi everyone – this proposal remains accepted, but is currently not implemented in the Swift standard library due to potential source-breaking changes that require improvements to the typechecker to avoid, as described above by @scanon

In the mean-time, users looking for this functionality can consider using the recently released Swift Numerics package, which contains the same code within its Real module.

Bjoern · 2021-05-08T14:24:21.856Z

Hi all,
is SE-0246 on the plate to be released in Swift 5.5?

scanon · 2021-05-08T16:46:59.069Z

No, we will run it through evolution again before landing it in the standard library (also we haven’t resolved all the typechecker difficulties yet). Please use Swift numerics for these APIs.

slyvek · 2021-08-16T07:59:56.241Z

Hi

Im my opinion the SE-0246 is one of the most important part of the Swift that is still not added to the standard library. Can anybody estimate when it may be published?

YOCKOW · 2021-08-16T08:54:41.070Z

Nothing seems to have been changed since this post.

FYI...

A quote from Addressing unimplemented evolution proposals:

Addressing unimplemented evolution proposals

SE-0220 and SE-0246 are both unimplemented due to their impact on type checker performance. These could be reproposed once the type checker issues are addressed. Note that the full implementation of SE-0246 is available via the Numerics package .

A quote from swift-numerics/Sources/RealModule/README.md:

SE-0246 proposed an API for "basic math functions" that would make operations like sine and logarithm available in generic contexts. It was accepted, but because of limitations in the compiler, the API could not be added to the standard library in a source-stable manner. RealModule provides that API as a separate module so that you can use it right away to get access to the improved API for these operations in your projects.