i think it’s much simpler : double = deeper zoom into that mandelbrot.
big planet: all spheres (assuming the planet is modeled as a sphere) are equivalent to the unit sphere. So not an example…size doesn’t matter.
deep zoom on the m-set: I totally forgot about this totally common game runtime example, but there’s no complex number support in the library.
In theory you are right. But in the context of IEEE 754 where we have discretized floating point values, you are not. 
Here, the equivalency breaks.
A planet - even with a 2D-parameterization of space (longitude-latitude, two angles) - is exactly equivalent to mandelbrot, with all the same problems involved. And that problem is: with any fixed-length (in number of bits, that is) numerical representation like IEEE 754, there is no and cannot be any parameterization of the surface of a sphere (any sphere) that lets you reach every point on the sphere. You can only advance on the sphere surface in discretized steps.
As you said rightly, size does not matter, but precision does!
So, simply put: you cannot increase the size of your planet indefinitely (or normalize it back again to unit size indefinitely) while still keeping the same unit of length say 1mm and still want 1mm resolution of small notches and rocks and hills on your planet.
So, because magnitude does not matter, it all depends on the order of magnitude you choose as your basic unit of length. Of course, if you choose 1 meter instead of 1 mm you can scale down the sphere by another factor of 1,000 while still retaining the desired precision (namely now 1 meter).
EDIT: Plus: I did not make this up as a contrived text-book example. It exists in real-world. A big world, by the way
Swinging wildly off topic here
Is this math library for OpenGL rendering or for pure mathematics? Aim for one or the other, or get either a poor fit for both or an overcomplicated library with loads of overloading.
Cas
Yes, you are right about the library. It shouldn’t be overweighted.
I for myself do not envision any rendering-related stuff in there.
No dependencies to JOGL or LWJGL or routines to build yourself a voxel game more easily. 
Just basic linear algebra in the style of javax.vecmath (i.e. allocation-free and with some little method overload conveniences).
The library is however suited for being integrated into a graphical application, because every such application needs linear algebra all over the place, be it just for a container for three-dimensional vectors.
You guys are hitting the nail on the head. It’s impossible to zoom forever on a chaotic map…it’s a problem of precision. It’s easy to zoom forever on noise…it’s a problem of scale.
Essentially yes
And to be exact here, it depends a bit what you mean by noise and how the noise value is correlated to space.
If your noise is a function of a parameterization of space (e.g. position on the sphere; or position on any manifold, like a simple plane) then you have precision problems there, too, as you “zoom in.”
Like I said above, with fixed-length numbers (32-bit or 64-bit or any bitness) there is no way to reach every (mathematically every) point - in terms of your chosen parameterization - on a manifold/surface.
Therefore, as you zoom-in more and more into your function (like mandelbrot) you reach the point where one ulp is the size of a pixel, at which point you see the discretization.
i always use 4x4 double matrices on the cpu - hides matrix drift in a place which is never reached. one annoying problem solved.
The library is intended to be just pure mathematics, albeit with a focus on the kind of maths used in 2D/3D rendering. I’ve intentionally avoided any dependency on another library including JOGL or LWJGL, the only concession I’ve made to OpenGL is to have the matrices column-major. I believe a library should have a very specific purpose, as you said nobody likes having to dig through a huge sprawling library which most people only need 10% of.
I’ve also started including some handy shortcuts for common calculations like transformation (model) matrices, perspective and projection matrices etc. This is less an intention to start producing higher level methods than simply to provide the fastest possible route from A to B for the most common kind of calculations where even a small speed increase can offer noticable improvements.
I do intend at some point to produce a library containing more “gamey” elements like a camera class and so on, but that will be completely separate.
@ KaiHH: Again no, it doesn’t really matter what definition of noise you choice. The problem is independent of scale. In fact that’s pretty much whole the point. To keep it simple take any isotropic noise in 2D. Apply any random composed transform (rotation, scaling, translation) of the plane and all results are self-similar.
Moving to the simplest example would be 1D fbm. You can zoom for an infinite amount of time with little precision and a little bit of memory. Infinite here means uncountable…the machine running the simulation will die long before the simulation breaks.
Oh and because an infinite 2D plane can be mapped to a unit 3-sphere does not imply that mappings of the 3-sphere are equivalent to the m-set.
And all of this is very far from commonly needed in a game runtime.
We are beginning to run in circles, it seems…
I will go ahead and first write a tutorial on IEEE 754, then we can continue discussing, but in another thread.
Sorry, Neoptolemus, for spamming your thread!
Hehe no problem. I am following the thread but I have to admit that I have gaps in my knowledge as far as this stuff goes, I’m entirely self taught in the maths, OpenGL and even programming full-stop, so it’s interesting to track the debate and then research what you’ve been discussing
Hello there,
it’s been almost four months now since the last post here on JGO about JOML.
So, what has changed since then?
During June, Neoptolemus took some time off and I decided to work towards JOML becoming really broadly usable and well documented.
Literally about 90% of the time was spent writing JavaDocs and Wiki documentation instead of “code,” which is not surprising for such a small and simple library.
However JOML did get alot of additions in functionality too during the last month and is now comparable to the math classes of XNA, Unity, libGDX and javax.vecmath/gwt-vecmath, with both essential and convenient stuff in it, but still with the goal of keeping it feel very “lightweight.”
The design (including semantics and naming conventions of methods) has been very strict to comply with the “principle of least astonishment” in order for JOML to be very similar to existing math libraries and how OpenGL and the OpenGL Utility Library handles math, also considering what is generally possible with Java on the syntax level.
You can read all about the design choices on JOML’s GitHub Wiki page.
If you have any suggestions/enhancements/bugs, we will be happy to hear about them on JOML’s GitHub Issues section.
Last but not least, we hope, that JOML is useful for some of you. For us, it already is.
Cheers,
the JOML team, Neoptolemus and Kai
Probably to allow switching to a different instance in the middle of a long method chain, just in case you want to do that.
I found an usage here: https://github.com/JOML-CI/JOML#method-chaining-and-context-switching :point:
EDIT: was too slow 
public Vector3f with(Vector3f v) {
return v;
}
Day and day I’m more and more confident about the fact that people are dumber and dumber, presenting themselves as wiser and wiser. Congratulations, you did epic shit. Literally.
While a ‘with’ indicates the need of a ‘;’ for me I can see the use.
A neat little library. I like it.
-ClaasJG
p.s. no need to insult anybody!
You can see the use of a method that returns a the only paramater that is passed to it? Congratulations to you!
But honestly, go home and take your medicines.
And to be not without an explanation, let me tell you what is wrong with your head. In the Java language we have a notion of referring to a variable:
Foo foo = new Foo();
Baz baz = new Baz();
foo.doThis();
foo.doThat().doWhatever(baz);
baz.doElse();
baz.beBaz();
Now the world is simple and easy. But some moron came in with a magnificient “with” method that takes an object and returns it so now we write:
Foo foo = new Foo();
Baz baz = new Baz();
foo.doThis();
foo.doThat().doWhatever(baz).with(baz).doElse().with(baz).beBaz();
Great, now you’ve fucked up the language. The readability is null, the idea of simply referring to a variable like a sane person is on it’s knees.
But really - I don’t know why I even bother - live in the shit you made for ever and ever. I’m glad I don’t have to read or change or to exist with your code, because else I would get a cancer.
Bye.