# FAQ

# #

Frequently Asked Questions**n** of **nalgebra** stands for?#

What does the **nalgebra** is some kind of abbreviation for *n-dimensional linear algebra
library*, where `n`

is a finite strictly positive integer.

`dot`

and `add`

show up on my benchmarks!#

Trivial math functions like Please make sure:

- You compiled your project and its dependencies in release mode, i.e.,
`cargo build --release`

. - You did
**not**enable incremental compilation. This prevents some optimization that may cause a 30x slow-down! We observed this running the nphysics examples in particular.

If you did all that and small `nalgebra`

methods still show up in your
benchmarks, please fill an
issue or tell us about it on
the users forum.

### #

What is the memory layout of matrices?All matrices of **nalgebra** are stored in column-major order. This means that
any two consecutive elements of a single matrix column will be contiguous in
memory as well. For example the matrix:

is arranged in memory the same way as the array ```
[ 11, 21, 31, 12, 22, 32, 13,
23, 33 ]
```

.

### #

Some error messages are very hard to understand or are cryptic!Because **nalgebra** relies on a lot of generics, some error messages might be
hard to understand. Please, open an
issue or create a post on the
users forum to get help. We take the
quality of error messages seriously, so providing details about how you got
them can be useful to improve them in the future.

`Vector3<f32>`

to a `Vector3<f64>`

?#

How do I convert a Use the `::convert(...)`

function. For example:

Conversions with this function will work for most structures as long as it
preserves the fundamental algebraic properties objects. If some algebraic
properties may be lost during conversion, use `::try_convert(...)`

or
`::try_convert_unchecked(...)`

instead.

**nalgebra** ?#

Can I serialize/deserialize structures from Yes, serialization and deserialization are supported using
serde. Just enable the **serde-serialize** feature for
**nalgebra** on your project's `Cargo.toml`

file.

### #

Why so many types? Why not just stick with raw matrices and vectors?It is common within the computer-graphics community to work only with 4x4
matrices for transformations and 3D vectors for translations and positions.
**nalgebra** on the other hand has different types for rotations, isometries,
points, unit quaternions, etc. This wide variety of types:

- adds extra semantics so that the user constantly knows exactly what kind of algebraic object are being manipulated.
- allows them to be used safely in a generic context because their intrinsic properties are always known.
- allows optimizations, e.g., for transformation matrices inversion.

Thus, instead of working with raw matrices, higher-level types should be preferred and only the end-result of all operations should be transformed into a raw matrix to be usable by, e.g., a shader.