- Touched up documentation for Math library

- finished matrix implementation
 - added custom assert implementation

PLANNING.md

@@ -9,7 +9,7 @@
  3.  [C++ Language](#c-language-library-lang)
  4.  [Math Library](#math-library-math)
  5.  [Memory Library](#memory-library-memory)
- 6.  [Containers Library](#containers-containers)
+ 6.  [Containers Library](#containers-library-containers)
  7.  [Format Processing](#format-processing-fproc)
  8.  [Core](#core-core)
      1. [Tick](#tick)
@@ -33,9 +33,11 @@ This file serves as a general planning document for engine structure, systems, p
 Implementations of core engine systems should strive to be `O(1)` in implementations, 
 both in terms of runtime and memory performance. This is obviously not a realistic goal, 
 so rather than the goal requiring the entire engine to be `O(1)`, we should more specifically look
-at achieving `O(1)` performance on hot paths.
+at achieving `O(1)` performance on hot paths. I distinctly use 'strive' and 'goal' as different concepts, where designs
+should *strive* to accommodate function implementations for `O(1)`, however the specifics of the implementation might not always
+be able to achieve that, so the end *goal* is that hot paths should be `O(1)`.
 
-Functions should be highly verbose, and in debug mode any bugprone or erroneous behaviour should throw
+Functions should be highly verbose and any bugprone or erroneous behaviour should throw
 assertions. **DO NOT USE EXCEPTIONS**.
 
 System implementations should be independent of architecture or platforms. i.e. the code of the graphics system should 
@@ -48,7 +50,7 @@ This principle should extend to the submodules of the engine.
 
 It is also best to avoid objects having behaviour that is not defined by the system they are in. There are some exceptions
 in extensions or mods and should be given configurability and programmability within those systems and their stages.
-This however can be acheived using events at different stages of those engines that are on-demand.
+This however can be achieved using events at different stages of those engines that are on-demand.
 
 
 
@@ -81,8 +83,8 @@ Implement math functions according to the [OpenGL 4.6 Shading Language Specifica
 the Specification.
 
 Additional extensions should be implemented to provide standard definitions for functions predominantly related
-to Linear Algebra, Mathematical Analysis, and Discrete Analysis. Additional extensions will be implemented on a
-as-needed basis.
+to Linear Algebra, Mathematical Analysis, and more specifically Discrete Analysis. Additional extensions will be 
+implemented on an as-needed basis.
 
 
 
@@ -219,9 +221,9 @@ in their operation order:
 
 ## Application Layer (`app`)
 
-This is the core windowing system of fennec. The implementation will initially be an SDL3 wrapper.
-Custom implementation may be further down the roadmap, however this is extremely complicated and there are better
-implementations than I could write.
+This is the core windowing system of fennec. The implementation will initially be an SDL3 wrapper.  
+Custom implementation may be further down the roadmap, however this is extremely complicated and there are better  
+implementations than I could write alone.
 
 
 
@@ -249,8 +251,8 @@ Object Structure. The mesh is implicit data.
 
 ### Structures (`gfx2d`)
 
-For the 2d rendering framework, Materials need to be rendered independently because we have
-no size constraints for images. This disallows us from using a meta-shader like in
+For the 2d rendering framework, Materials need to be rendered independently because we have  
+no size constraints for images. This disallows us from using a meta-shader like in  
 the 3d rendering framework.
 
 ```c++
@@ -285,8 +287,8 @@ struct Object
      - Adjust Buffer Size using the counts
      - Insert using another atomic buffer
 
- - Translucent objects will be sorted. We can cheat by using a z-index instead of a z-coordinate.
-   This will allow us to sort objects as they are created. We can still bulk render each z-index,
+ - Translucent objects will be sorted. We can cheat by using a z-index instead of a z-coordinate.  
+   This will allow us to sort objects as they are created. We can still bulk render each z-index,  
    with meshes and objects being grouped by material.
 
 
@@ -304,14 +306,14 @@ Links:
 - https://pixelandpoly.com/ior.html
 - https://developer.download.nvidia.com/SDK/10/opengl/screenshots/samples/dual_depth_peeling.html
 
-**DirectX will never have official support.** 
+**DirectX will never have official support.**
 If you would like to make a fork, have at it, but know that I will hold a deep disdain for you.
 
-The graphics pipeline will have a buffer with a list of objects and their rendering data.
+The graphics pipeline will have a buffer with a list of objects and their rendering data.  
 This will be referred to as the Object Buffer. There will be two, for both the Deferred and Forward Passes.
 
-The buffers will be optimized by scene prediction. 
-This involves tracking the meshes and textures directly and indirectly used by a scene.
+The buffers will be optimized by scene prediction.  
+This involves tracking the meshes and textures directly and indirectly used by a scene.  
 A callback function in the graphics system for scene loading can do this.