It’s not that other types are “needed”, but that they let you do some pretty powerful things with surprising ease. And the nice thing is that in Julia, you can ignore them. You can just compute with floats or doubles as if the type system doesn’t exist. But it’s there in case you would like, for example, to apply the differential equation solver that you just wrote to quaternion-valued functions with no extra work.
This is how I found out it worked in the differential equation solver: users were using it. The issue was unrelated (they didn't define enough boundary conditions), so it's quite cool that it was useful to someone. It turns out the quaternions have use cases in 3D rotations:
Thanks for this article, it's really well written and engaging.
But here, I cannot resist:
You can just compute with floats or doubles as if the type system doesn’t exist.
Except when you can't! I want to plot a stupid array of floats. Yet it takes 10 seconds because it is juggling useless types around. A complex type system may be a nice thing to have, if you really want it, but it is definitely not "free", and it always involves serious compromises that make other things impossible or very cumbersome. I would like an option like --type=float in the interpreter that assumed that all numbers are of that type and ran extremely fast.
I’m glad you liked the article. Obviously the 10 second or so of precompilation time is a big issue for you. I guess I have no further suggestions about that other than to suggest again to look at creating sysimages (learning how to do this is on my to-do list).
I was particularly "seduced" by the idea of using a standard ODE solver directly on quaternions. Having worked in the smoothing of 3D camera trajectories the last year, I would have definitely loved to know that at the time!
Comments
I think I have a pretty good answer to your question in this article: https://lwn.net/Articles/834571/
It’s not that other types are “needed”, but that they let you do some pretty powerful things with surprising ease. And the nice thing is that in Julia, you can ignore them. You can just compute with floats or doubles as if the type system doesn’t exist. But it’s there in case you would like, for example, to apply the differential equation solver that you just wrote to quaternion-valued functions with no extra work.
This isn't theoretical too, here's an actual user who opened an issue where their MWE was using quaternions:
https://github.com/SciML/BoundaryValueDiffEq.jl/issues/52
This is how I found out it worked in the differential equation solver: users were using it. The issue was unrelated (they didn't define enough boundary conditions), so it's quite cool that it was useful to someone. It turns out the quaternions have use cases in 3D rotations:
https://en.wikipedia.org/wiki/Gimbal_lock
which is where this all comes in. Anyways, it's always cool to learn from users what your own library supports! That's really a Julia treat.
Thanks for this article, it's really well written and engaging.
But here, I cannot resist:
Except when you can't! I want to plot a stupid array of floats. Yet it takes 10 seconds because it is juggling useless types around. A complex type system may be a nice thing to have, if you really want it, but it is definitely not "free", and it always involves serious compromises that make other things impossible or very cumbersome. I would like an option like --type=float in the interpreter that assumed that all numbers are of that type and ran extremely fast.
I’m glad you liked the article. Obviously the 10 second or so of precompilation time is a big issue for you. I guess I have no further suggestions about that other than to suggest again to look at creating sysimages (learning how to do this is on my to-do list).
I was particularly "seduced" by the idea of using a standard ODE solver directly on quaternions. Having worked in the smoothing of 3D camera trajectories the last year, I would have definitely loved to know that at the time!