LWE: error and float operations Background

I'm trying to make sense of the error in implementations of LWE and R-LWE.  In LWE and R-LWE error is added to vectors in lattices to make it computationally infeasible to recover any meaningful data.

It was said here that using float operations in PRNG's aren't reliable enough across different environments.

According to the accepted answer on this question though, it's possible to "trivially" generate cryptographically secure, nearly uniform distributions of floating point decimals.

Questions


Does the error used in LWE or R-LWE rely primarily on float operations?
Do float operations need to be in a finite field to be secure?
Before rounding occurs, are all numbers floating decimals?


Conjectures

My assumption is that Case 1 may be likely, but Case 2 is true.  This leads me to believe that only error terms are treated as floating point decimals as a way to maintain efficiency and security, but taking everything either modulo a number or modulo an ideal generates an integer.  So in effect, the error taken modulo a number produces a lattice point (integer), or error taken modulo an ideal produces a lattice (finite field).

Is this an accurate assessment?
Answering point 3, no.  Rounding a floating point number just leads to a floating point number.  It just has less significant digits.  So they're still represented as a significand and exponent.  This is a widely accepted format these days.  An integer is a totally different storage method that does not lead to accumulated errors.  They're 100% precise.  The uniform distribution problem is exacerbated by the gargantuan 24 orders of magnitude variance in precision of floating point numbers as:-



Further arithmetic operations on a rounded floating point number will still accrue rounding errors in difficult to predict ways.  And different languages have different types of numbers.  For example Java has different types of numbers compared to  Perl, and those are different to C /C++.  This contributes to the difficulty of  native random floating point number generators.  

It's typical to cast a number from one kind to another if you want to change type.