

Google's MathFu: a x-platform geometry math library for C++ - dsr12
http://google.github.io/mathfu/

======
scoopr
Fascinating! They happen to depend on my vectorial[0] lib. Got a pull request
earlier from google, so I had an inkling that something was up.

[0] [https://github.com/scoopr/vectorial](https://github.com/scoopr/vectorial)

------
vowelless
From their github page:
[https://github.com/google/mathfu](https://github.com/google/mathfu)

What is the implication of this? I am not an Android developer; is this
tracking common?

 _For applications on Google Play that integrate this tool, usage is tracked.
This tracking is done automatically using the embedded version string
(kMathFuFunVersionString), and helps us continue to optimize it. Aside from
consuming a few extra bytes in your application binary, it shouldn 't affect
your application at all. We use this information to let us know if MathFu is
useful and if we should continue to invest in it. Since this is open source,
you are free to remove the version string but we would appreciate if you would
leave it in._

~~~
blt
It means that by compiling their code into your binary, your binary will
contain a string that shows which version of the library you used. Anyone will
be able to find it by searching your binary file for the raw bytes.

Since the code is open-source, you can always remove the string yourself.

This isn't scary. It's not phoning home to a web server or anything. If the
library was dynamically linked as a .so/DLL instead of header-only, you'd be
able to find the same information by looking at the ELF/EXE file header.

------
chuckcode
Would be great to offer some performance benchmarks to see if this outperforms
similar linear algebra packages like eigen [1] which looks to have all the
features they are offering and is headers only c++ library.

[1] [http://eigen.tuxfamily.org](http://eigen.tuxfamily.org)

~~~
santaclaus
Also, Blaze [1], although I recall a bit of consternation on the Eigen mailing
list due to some bogus benchmarks the Blaze folks were reporting
(intentionally selecting poor options for Eigen in their comparisons) [2].

(edited to link to Eigen discussion -- Blaze was reporting MKL's performance
as their own, despite Eigen supporting the same option to fall through to MKL)

[1] [https://code.google.com/p/blaze-lib/](https://code.google.com/p/blaze-
lib/) [2]
[http://comments.gmane.org/gmane.comp.lib.eigen/3423](http://comments.gmane.org/gmane.comp.lib.eigen/3423)

~~~
chuckcode
Thanks for the link, haven't tried Blaze yet. Their benchmarks do look a
little suspicious, especially as Armadillo will auto detect and link to MKL if
installed.

------
peaton
Taking a course on OpenGL Graphics programming in university right now. We use
GLM. It seems pretty good. If I'm not mistaken this is a (potential)
replacement for GLM? If anyone knows GLM well could they discuss the
differences between the two libraries? Is this worth investing time into?

~~~
maccard
Only downside I found with GLM is it is dog slow when built without
optimisations, making debugging painful, and as it is a header only library
you can't compile an optimised version for debugging purposes. I'm not aware
of any libraries that solve this problem though, while still remaining as fast
when fully optimised. I did consider trying to create a custom recompiled
header built with full optimisations but I never got around to investigating
it as an option...

~~~
jzwinck
Try this [1]:

    
    
        #pragma GCC push_options
        #pragma GCC optimize("O2")
        #include <something>
        #pragma GCC pop_options
    

[1] [https://gcc.gnu.org/onlinedocs/gcc/Function-Specific-
Option-...](https://gcc.gnu.org/onlinedocs/gcc/Function-Specific-Option-
Pragmas.html#Function-Specific-Option-Pragmas)

~~~
maccard
I'm working with Visual Studio :) But this would have been awesome, as I think
it compiled with MinGW.

------
sjolsen
Is there a particular reason everything is implemented as member functions? I
feel like typing things like

    
    
        mathfu::Vector <float, 3>::CrossProduct (u, v)
    

instead of

    
    
        cross_product (u, v)
    

would get really old really fast.

------
tdicola
Awesome, this looks really handy for game development. Love that it's cross
platform with Intel and ARM SIMD extensions too! Has anyone used it and have
feedback on how well it works?

------
aktau
For some simpler vector stuff that's only C (and basically mostly SSE), I tend
to use a personal fork of this for my toy games:
[https://github.com/rikusalminen/threedee-
simd](https://github.com/rikusalminen/threedee-simd)

The simplicity is what gets to me:

vcross(v1, v2) * v3 (with gcc/clangs vector extensions)

Great codegen too.

------
blt
good, simple, basically identical to the code I've written myself when messing
around with 3d stuff. nice to see a library that solves one problem well and
doesn't carry around a lot of extra baggage.

------
grandmaster789
Pretty nice, although the library is a bit small for my tastes. No planes, no
intersections... interesting, but I'd like to see a more complete feature set.

------
csirac2
Interesting project, but - and I hate to be that jerk - what possible reason
was there to write it as "x-platform"?

~~~
Someone
I think it might be cultural. In the USA they write 'crossing' as 'Xing' (and
use way too much text in traffic signals, with "PED XING" as one of the
weirdest examples)

~~~
musername
While at the same time the x in x-mas means the greek letter Chi that
represents the ch-sound. just to get ahead of any confusion and to bring this
thread around full O.

------
pagade
No C++11 features? Especially move constructor and assignment operator.

~~~
corysama
I'm pretty sure these are all POD value types. There are no internal pointers,
nothing for a move constructor to shortcut and nothing special that an
assignment operator needs to do besides the default.

~~~
pagade
That makes sense. Thanks.

