Doesn't that kinda depend on what you're doing? Like, if you want to check if two numbers are equal to 1 part in 1000, that'd be x ≈ y ± 0.001%, right?
(It's entirely possible I'm completely misconstruing the meaning of "to 1 part in 1000".)
Your post raises a second issue: percentages are confusing. ;) 1 part in 1000 is 0.1%.
The reason it's a problem is that the default value of the tolerance is a key feature of @scanon's PR. Even equipped with the best logic to tell if two numbers are approximately the same, most people fail to find a reasonable value of tolerance. By promoting a scale that works best for tolerances that are many orders of magnitude larger than a usually adequate value, we would be encouraging users to ignore the best advice that we have available to us.
1 Like
That's not necessarily the case. I'm not saying that's a good solution, but C has a solution for impossible to type characters that doesn't involve the OS: C Programming/C trigraph - Wikibooks, open books for an open world
Those are just for strings, though, right? Not for identifiers or operators?
No, those are for everything. C++ finally got rid of them, but C is still stuck with them.
1 Like
As a side note, I have a proposal I keep meaning to write up about making it easy to express unicode characters in Swift, for exactly things like this.
The basic idea (inspired by LaTeX) is to just spell out the name between single quotes. Good IDEs (like Xcode) could then show it as that character (with a subtle visual treatment similar to literals). Mousing over would show the name. e.g. 'union' would show as ∪.
For those who like pure text editors, they would still be able to see/use the text version.
We could have it where you associate the names as part of the operator definition:
infix operator 'name' "\u{222A}"
which would also potentially allow text operators in general (when surrounded by single quotes):
infix operator 'and'
let c = a 'and' b
5 Likes
I chuckled.
What makes you think XCode would add such a feature? Everything about XCode development is secret and the track record for adding useful things (e.g. SPM support) isn't exactly stellar.
More broadly, this doesn't need to be in any language standard. There are vim plugins that turn common Haskell operators into unicode representations and similar things probably exist for other editors/IDEs too.
This is a great idea, though I have a slightly different take on how it could work. Rather than providing your own name for each symbol, have standard names built in to the compiler. (These could just be the standard Unicode names.) For example, when you type
a 'element of' b
it would be exactly the same as typing
a ∈ b
Or typing
a 'not an element of' b
would be the same as typing
a ∉ b
This solves the typing problem — if your keyboard doesn’t provide a particular symbol directly, you can type the name of the symbol instead.
Initially this feature could include just the mathematical operators, but I see it possibly being expanded to other symbols. You could even allow combining symbols. For example
'a + grave accent'
would be an alternate way of typing
à
I think at this point it's worth forking non-ascii letter discussion into another thread.
7 Likes
Did that new pitch ever get posted? I've tried finding it to no avail.
Has been on the back burner; I'm going to add it to Swift Numerics first, and then people can get some experience with it before we pitch it for the stdlib again.
6 Likes
I like it, hope to add it to stdlib evolution.
Just happened to read this (just lately getting into reading the evo forums) - on the off chance this is still something...
Given the title of the proposal - I'd suggest a more writable/legible name for such a function would be better expressed as approximates(_, within: *) (or some comparable tolerance label) rather than isAlmostEqual(to: *, tolerance: *). Aside from the excessive camel casing it avoids, any kind of "loose" evaluation of equality (while very needful), IMO, shouldn't really be described as "is" - and the tolerance is in fact the most important part of the identity of approximation, even when it's elided, and should be an adjective rather than treated as a third party to the a like b nature of things.
let a: Double = ...
let b: Double = ...
a.approximates(b)
a.approximates(b, within: 0.5)
// vs
a.isAlmostEqual(to: b)
a.isAlmostEqual(to: b, tolerance: 0.5)
6 Likes
Double(1.66).isAlmostEqual(to: 1.5, tolerance: 0.1) // returns true
Current implementation returns true for this comparison. Is it correct?
Yes. 1.66 minus 1.5 is less than 10% of 1.66.
3 Likes