Code is preferred to be inside ticks (`), so that it won't be edited by other forum settings. i.e. sin(_:)
4 Likes
That's what I meant. What's stopping us from having Builtin.sin? It's not necessary that it defers to the Clibc or Darwin implementation, it's probably better off just using the native instructions for it (at least on x86)
Perhaps it's because I don't quite understand the semantic difference between "the platform" (Foundation) and the standard library (Swift.*), but not having basic trig, pow and root functions in the standard library is crazy to me. They're such elementary things, and they don't even have a consistent interface across platforms. You have to define so many wrapper functions/protocols just to get generic trig on floating numbers, which could so naturally be fit into the system as a TrigonometricFloatingPoint, as Kelvin was suggesting.
What other high level language omits such basic features (trig, pow, random come to mind) from its STL?
Nooo, they were a roundabout way to make people useCodeHightlighting(_:)
1 Like
Yes, please turn emoji back on.
1 Like
you 
can still use emojis the normal way
thx b
No thanks. Like code tags and markdown in general, inline emoji rendering is far more convenient than having to separately style segments or use a separate keyboard. Besides which, your complained about behavior was due to not using said tags in the first place, not an issue with inline emoji. There's no need to turn it off.
1 Like
i thought that too but apparently no one uses the x86 instructions because the software implementation is faster
&& yeah it’s crazy 
they 
do 
render 
inline
Really? 
Hi,
You might find looking into SceneKit framework (layer over OpenGL and Metal) macOS, iOS, TVOS, interesting (albeit only for Apple apps)
(see link below)
Because this is a very extensive and excellent 3D and 2D framework, there's a lot of trigonometry/ vector logic in there. Also there are many useful Swift extensions written for this framework: e.g for SCNVector3, quaternions etc.
I doubt it, when seeing this, that one still want to implement special types like Angle?
It's also very fast!
As @taylorswift highlighted from my earlier post, the legacy x87 transcendental function instructions should really not be used any longer. They are significantly slower than modern software implementations using SSE/AVX/FMA/etc and use only a 66-bit accurate value of π, which leads to unacceptable (relative) errors even for quite small inputs, and unacceptable absolute errors for large inputs.
Intel Underestimates Error Bounds by 1.3 quintillion | Random ASCII – tech blog of Bruce Dawson has a pretty good writeup on the accuracy issues if you're curious.
haven’t used GLKit (linux user here) so i don’t know it that well but i’d hardly hold it up as an example of a good Swift API
func GLKMatrix4Make(_ m00: Float,
_ m01: Float,
_ m02: Float,
_ m03: Float,
_ m10: Float,
_ m11: Float,
_ m12: Float,
_ m13: Float,
_ m20: Float,
_ m21: Float,
_ m22: Float,
_ m23: Float,
_ m30: Float,
_ m31: Float,
_ m32: Float,
_ m33: Float) -> GLKMatrix4
granted everything in the graphics world is 32-bit Float but more type-safety is always welcome. GL APIs are notorious for dumb argument placement bugs since all the functions take 2745892 arguments and we don’t get the help of Swift’s argument labels.
also there are cases where your gamedev algorithms and libraries could also be useful for scientific stuff (like i recently wrote a spherical voronoi tesselator), and having generic F:_SwiftFloatingPoint instead of Float helps a lot.
To be fair, you can make it a bit better by laying it out a grid:
func GLKMatrix4Make(
_ m00: Float, _ m01: Float, _ m02: Float, _ m03: Float,
_ m10: Float, _ m11: Float, _ m12: Float, _ m13: Float,
_ m20: Float, _ m21: Float, _ m22: Float, _ m23: Float,
_ m30: Float, _ m31: Float, _ m32: Float, _ m33: Float
) -> GLKMatrix4
That's GLKit; Ted was referencing SceneKit (which could also be more Swifty, but also has a bunch of other nice "constructors"):
SCNMatrix4MakeRotation(angle: CGFloat, x: CGFloat, y: CGFloat, z: CGFloat) -> SCNMatrix4
SCNMatrix4MakeScale(sx: CGFloat, sy: CGFloat, sz: CGFloat) -> SCNMatrix4
SCNMatrix4MakeTranslation(tx: CGFloat, ty: CGFloat, tz: CGFloat) -> SCNMatrix4
the day i can write column vectors in source code…
i figured he was talking about GLKit because SceneKit looked way too high level to be implementing basic math types
I would really like to see a standard math library for Swift (including Angle) overseen by Evolution. While I generally agree with the strategy of looking for good third party libraries to pull in, I think core math is an exception to that both because of its centrality and the level of technical expertise needed to get things right.
I have a bit of a radical proposal... instead of waiting for that sub-library to be created, let’s start adding core math to the standard library now... and then split it into multiple frameworks later.
The addition of that code will force the issue much sooner. I fear we will be waiting forever for basic things like standard trig functions otherwise.