Allow for negative Paranoid Numbers

Specifically, when constructed off a string I wasn't checking for a leading '-' sign.
That's kind of important.

Also 'e' notations will probably have to be included at some point.

I am really bad at this...
Doomed to failure

BLasdfuywetraefrdg
Some quadtree stuff: bugfix + mutation
Merge branch 'master' of git.ucc.asn.au:ipdf/code
Initial support for scripting actions.
Lazy + CPU/GPU rendering toggle in script.
Add loadsvg script command, fix ParanoidNumber size limiting*

Need to write some scripts and performance test them now I guess?
Maybe add commands for scripts to output information for plotting.
Script should still work after loadsvg is used

This is why I always use "<= 0" not "== 0"...
Although if loops were unsigned that still wouldn't help.
More debugscript things, sanity fading fast
Define for Transformations on Path only, also fixed segfault due to GraphicsBuffer

The "invalidated" is used to recycle memory in the GraphicsBuffer,
but that can only be done if there is actually enough memory.

This was causing a segfault if the document was initially empty and had things added to it.
Can now remove the hack in main.cpp where documents started with a {0,0,0,0} RECT in them.

We can now (ab)use the Path for transformations.
The idea was that Arbitrary precision stuff might be faster if we only care about the bounds of the paths.

Unfortunately the way Real was used everywhere will make it a bit difficult to actually use this.
We need Beziers and their bounds to be stored with floats, but the Path bounds to be stored with GMPrat or some other arbitrary type.

It probably won't help that much, but evaluating those Beziers with GMPrat really slows down the CPU renderer.
It's also a giant hack because I still use BezierRenderer for GPU rendering but I now use PathRenderer for CPU rendering of Beziers.

Le sigh.

We can now store Bezier bounds relative to Path bounds and apply transformations only to the Path bounds.
Use Gmprat for Path bounds with TRANSFORM_BEZIERS_TO_PATH

So, the bounds of Paths are stored with Gmprat
The Bezier's are all stored relative to the Path, as floats

The transformations are only applied to the Path Gmprat bounds.

This seems to work rather well.

In other news, the DeCasteljau algorithm in the CPU
renderer had no upper limit, which is why it was slowing down so much.

The CPU renderer tends to suffer from SIGFPE-itis when using floats,
because when you do a cast there is a SIGFPE if the resultant type can't represent the operand.
This occurs in a few places that don't actually affect the rendering...
Critics are panning the quadtree's panning.

(It's broken)
Merge branch 'master' of git.ucc.asn.au:ipdf/code

Conflicts:
	src/bezier.cpp
	src/view.h
Totally FITH everything

I'm trying to get it so that Path and View can use a different number
representation to Bezier.

It's not going well.
Keeping it Real, add Gmprat::Str, Gmprat::Log10

Fixed* all those horrible compile errors.
View can now use VReal and Path can now use PReal
	and at the moment they are Gmprat unless the quadtree is enabled.

For Gmprat::Log10 there are problems.

Using: log(a/b) = log(a) - log(b)
       log(a*b) = log(a) + log(b)

Unfortunately mpz_div_ui quickly becomes a massive performance issue.
Even when well within the range of IEEE singles.

Need to rewrite Gmprat::Log10 but may as well commit since it works* slowly at least.
Gmprat logarithms now O(1) not O(N)

... Where the "1" is determined log(3), don't get too excited

So we can finally actually print values outside DBL_MIN->DBL_MAX
Now to go through and remove all the cast to doubles...
Turtles all the way down

Also fix up DebugScript's performance data
I can actually plot things!

Still haven't actually plotted things, but in theory I can.
Panning for gold, with the Quadtree!

Sulix celebrates the panning in the quadtree finally working*
with the worst pun yet!

* The segfault doesn't count.
Merge branch 'master' of git.ucc.asn.au:ipdf/code
Compile with float/double again.