Re: swift and objective-c
Re: swift and objective-c
- Subject: Re: swift and objective-c
- From: Gordon Apple <email@hidden>
- Date: Wed, 04 Jun 2014 11:37:18 -0500
- Thread-topic: swift and objective-c
Title: Re: swift and objective-c
I totally agree on this one. As someone steeped in number theory, abstract algebra, and error correction coding (Including my long ago PhD dissertation at Purdue), I agree that computer languages have always done “%” wrong. It would have been nice to fix it here, except that this freight train is unlikely to change tracks for us purists.
Operator precedence is another concern, although likely not an issue. I notice that the manual does go to great lengths to define operator precedence levels. I can only hope that these are totally compatible with those defined in K&R, Stroustroup, etc. At least, Swift does allow you to use “&&” and “||” without those ridiculous warnings we now get about expressions like “a && b || c”. After all, we don’t get warnings about “ab + c”, nor should we. I do wish they had included a logical “exclusive or” because this is part of the basis of the lowest level mathematical “ring” and “field”.
The “..” and “...” range definitions similarities are likely to be an easy source of programming errors.
On 6/3/14 7:51 PM, "email@hidden" <email@hidden> wrote:
Quotient/remainder:
- In Swift, a % b ignores the sign of b. A non-zero remainder has the same sign as a.
- Ruby does it right; A non-zero remainder has the same sign as the divisor.
Anyone who has ever tried to implement Number Theory algorithms will have learned that letting the sign of the remainder depend on the sign of the dividend means that you have to add a whole lot of defensive code around all your modular arithmetic. The _expression_ 'x % 10' should return a value in the range 0 thru 9, regardless of the sign of x. (Think about computing which of 10 buckets to put an item in. "Number Theory" need not be exotic.) Absent that guarantee, you have to write ((x % 10) + 10) % 10, or use a conditional branch and introduce pipeline stalls. And if x % 16 is to have the sign of x, the compiler cannot optimize it to (x & 15).
Historically, the IBM 704/709 computers did quotient/remainder wrong. Therefore, Fortran did it wrong. Therefore every later processor that wanted to "support Fortran" needed to do it wrong. Therefore the C standardizers caved, and said "the compiler should do it the way the hardware does", meaning in practice that C always does it wrong too. (Which, I guess, is why Swift does it wrong. When they threw out C, they didn't throw away enough.)
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden