A way to generate precise UV coordinates

Hi all. I’m quite new in 3D programming so sorry if the question will seem ‘noobie’. I’m trying to apply texture with grid painted to generated mesh. And faced with problem that calculations with float type are little confusing which leads to wrong texture positioning.
Below is UV array generation code I’m using:

//Vertices is 100 X 100 size
public static Mesh CreateSurfaceMesh(Vector3[,] Vertices)
{
  Mesh mesh = new Mesh();
  Vector2[] uv = new Vector2[Vertices.Length];
  int index = 0;
  float uvXStep = 1.0f / Vertices.GetLength(0);
  Debug.Log(uvXStep);//Shows 0.00990099 but should be 0.01
  float uvyStep = 1.0f / Vertices.GetLength(1);
  float uvx = 0;
  for (int x = 0; x < Vertices.GetLength(0); x++)
  {
    float uvy = 0;
    for (int z = 0; z < Vertices.GetLength(1); z++)
    {
      uv[index] = new Vector2(uvx, uvy);
      index++;
      uvy += uvyStep;
    }
    uvx += uvXStep;
  }
  mesh.uv = uv;
  Debug.Log(uvx);//Maximum uvx reached. Shows 0.9999998 but should be simply 1
  //The rest of code skipped...

Calculations mistake is not large texture placed slightly wrong:
What I expected to see (texture applied to standart unity plane):
1455400--78958--$563y.png
And what I actually see on my mesh:
1455400--78959--$udhh.png
As you can see, part of texture is prunned. There seems to be very trivial solution to handle this. If someone knows what is wrong with my UV generation method any help will be appreciated.
Thanks in advance.

instead of calculating an (slightly) incorrect uvstep, then repeatedly incrememnt by that incorrect value, just change line 16 to something like
uv[index] = new Vector2(x / Vertices.GetLength(0) , y / Vertices.GetLength(1) );

The final step should end up being 100/100 = 1

Thank you. Yor calculations works much better. Of corse in terms of performance dividing operations is worst than addition, but I will use it only in editor mode so it is not a problem.

If you’re worried about the division, you can perform a (1/value-you-want-to-divide-by) and cache the result, then use that to multiply against your values in the loop.

That being said, floating point can only approximate numbers which aren’t easily represented in binary. If you need super exact numbers, try to limit your numbers to the range of numbers within some sum of 2^n when possible.

Yeah I guessed it was either editor-time, or something that would only happen at start, etc (not every frame) so it’s nothing to fret over.