# Floor.MovePoint Rounding?
**URL:** https://forum.dynamobim.com/t/floor-movepoint-rounding/68554
**Category:** Revit
**Created:** [September 24, 2021, 7:08pm UTC](https://forum.dynamobim.com/t/floor-movepoint-rounding/68554 "2021-09-24T19:08:41Z")
**Posts on this page:** 16
**Page:** 1
### Author:  [@aaronrumple](https://forum.dynamobim.com/u/aaronrumple)
#### Post date: [September 24, 2021, 7:08pm UTC](https://forum.dynamobim.com/t/floor-movepoint-rounding/68554/1 "2021-09-24T19:08:41Z")
It sure looks like the Floor.MovePoint code is rounding input numbers…
---
### Author:  [@aaronrumple](https://forum.dynamobim.com/u/aaronrumple)
#### Post date: [September 24, 2021, 7:13pm UTC](https://forum.dynamobim.com/t/floor-movepoint-rounding/68554/2 "2021-09-24T19:13:32Z")
Well - I’ll be.
Floor.Move.Point is rounding input. That’s not good.
Banging my head against the wall for an hour on that.
Ok - so we do it the hard way.
---
### Author:  [@Deniz\_Maral](https://forum.dynamobim.com/u/Deniz_Maral)
#### Post date: [September 24, 2021, 7:36pm UTC](https://forum.dynamobim.com/t/floor-movepoint-rounding/68554/3 "2021-09-24T19:36:22Z")
It is shown as 100 but it may not be. Use Math.Round with Digits and as Digits input 10 or more.
---
### Author:  [@aaronrumple](https://forum.dynamobim.com/u/aaronrumple)
#### Post date: [September 24, 2021, 7:45pm UTC](https://forum.dynamobim.com/t/floor-movepoint-rounding/68554/4 "2021-09-24T19:45:52Z")
No - it is screwed.
The 100 is spot on. I’ve looked at it in C# and Revi tLookup.
Here I add 0.166 to one point and move it up 0.000000000000001
Just jumps to a perfectly even 100.
Here I add 0.001 to the 100.1666 and it jumps back to 100.001
Clearly the node is truncating the 100.16666 to 100.
---
### Author:  [@aaronrumple](https://forum.dynamobim.com/u/aaronrumple)
#### Post date: [September 24, 2021, 7:50pm UTC](https://forum.dynamobim.com/t/floor-movepoint-rounding/68554/5 "2021-09-24T19:50:30Z")
Just did a test on a variety of values. It isn’t doing a round - it is just discarding the decimal. Doing a flatten. 100.916666 and add 0.001 - returns 100.001.
---
### Author:  [@Deniz\_Maral](https://forum.dynamobim.com/u/Deniz_Maral)
#### Post date: [September 24, 2021, 7:58pm UTC](https://forum.dynamobim.com/t/floor-movepoint-rounding/68554/6 "2021-09-24T19:58:46Z")
Do after Point.Z a Math.Round with digits. You haven’t done, I said.
---
### Author:  [@aaronrumple](https://forum.dynamobim.com/u/aaronrumple)
#### Post date: [September 24, 2021, 8:06pm UTC](https://forum.dynamobim.com/t/floor-movepoint-rounding/68554/7 "2021-09-24T20:06:41Z")
You said, I did.
And as you can see - it is rounding. Just like I said. If VisualStudio is telling me it is reset to 100.000000000000000 - then it is 100.
The node is hosed - it rounds.
Go try it yourself if you don’t believe me.
---
### Author:  [@Deniz\_Maral](https://forum.dynamobim.com/u/Deniz_Maral)
#### Post date: [September 24, 2021, 8:30pm UTC](https://forum.dynamobim.com/t/floor-movepoint-rounding/68554/8 "2021-09-24T20:30:48Z")
It is not about believing or not. Some nodes no like that and some don’t. In your Screenshots I could not see it.
I am using mac at home so I can’t test it. I cold do it via Python but maybe on Tuesday…
---
### Author:  [@aaronrumple](https://forum.dynamobim.com/u/aaronrumple)
#### Post date: [September 24, 2021, 8:32pm UTC](https://forum.dynamobim.com/t/floor-movepoint-rounding/68554/9 "2021-09-24T20:32:26Z")
Yes - I can to it via the API. Works fine there.
The node doesn’t do what it needs to do.
---
### Author:  [@Nick\_Boyts](https://forum.dynamobim.com/u/Nick_Boyts)
#### Post date: [September 24, 2021, 9:09pm UTC](https://forum.dynamobim.com/t/floor-movepoint-rounding/68554/10 "2021-09-24T21:09:42Z")
I can’t even get this node to move anything, let alone incorrectly, but I did notice that it’s expecting a single point and a single offset. You can see by your output structure that it’s attempting to move each point by each offset individually (55\*55=3025). Might be related, might not. Either way, I’d recommend specifying list levels to get the output you’re looking for.
---
### Author:  [@aaronrumple](https://forum.dynamobim.com/u/aaronrumple)
#### Post date: [September 25, 2021, 1:28am UTC](https://forum.dynamobim.com/t/floor-movepoint-rounding/68554/11 "2021-09-25T01:28:31Z")
No - the node takes a list just fine. You just need the same number of elements in each list. So in this instance the site surface is repeated in the list the same number of times as the number of points.
And they move just fine. But there are small inaccuracies that are introduced in the end result.
---
### Author:  [@GavinNicholls](https://forum.dynamobim.com/u/GavinNicholls)
#### Post date: [September 27, 2021, 7:37pm UTC](https://forum.dynamobim.com/t/floor-movepoint-rounding/68554/12 "2021-09-27T19:37:11Z")
Test doing it in feet and see if there is a rounding issue still. If not, it’s a unit conversion issue in the node - I’ve seen these before with custom nodes before when a small value is converted and lost in the process due to place limits. It would also be one to raise via github also if it turns out to be a bug within an ootb node.
---
### Author:  [@Nick\_Boyts](https://forum.dynamobim.com/u/Nick_Boyts)
#### Post date: [September 27, 2021, 9:39pm UTC](https://forum.dynamobim.com/t/floor-movepoint-rounding/68554/13 "2021-09-27T21:39:18Z")
The `Offset` value is with respect to the floor’s origin, not it’s current point locations. You’re not moving the points up by 0.001, you’re moving them _to_ 0.001. If your floor is drawn at a 100’ elevation, then an offset of 0.001’ would set them to 100.001’. This is why you’re seeing “rounding”. You’re using values way beyond the precision of Revit, so 0.00000000001 gets rounded to 0.
---
### Author:  [@aaronrumple](https://forum.dynamobim.com/u/aaronrumple)
#### Post date: [September 28, 2021, 5:39pm UTC](https://forum.dynamobim.com/t/floor-movepoint-rounding/68554/14 "2021-09-28T17:39:06Z")
The API offset is relative to the object. True.
But for this node - it moves the point relative to their current location. If it is at 100 and you apply an offset of 100 it will have a Z of 200, unlike the API.
You’ll see in this image I previously posted, point 54 is at 100.166. I add 0.001 to all the points and they all move to 100.001. Including point 54 which should read 100.167.
I can do the exact same thing with the API - and it works perfectly. Point 54 reads out 100.166766666667 just as it should.
Yes - if things were just off by - 0.00000000001, that would be floating point rounding. But in a file I was testing, I was seeing discrepancies of half a foot in the end result. Otherwise I wouldn’t have noticed an error. That can’t be simple floating point errors.
I’ve at this point, tried it on several floor slabs in several different files and I’m getting very inconsistent results. So I’m not sure what is going on and haven’t been able to find what the issue might be.
For now, using the API works consistently and perfectly fine on all the files and test slabs.
---
### Author:  [@Nick\_Boyts](https://forum.dynamobim.com/u/Nick_Boyts)
#### Post date: [September 28, 2021, 5:48pm UTC](https://forum.dynamobim.com/t/floor-movepoint-rounding/68554/15 "2021-09-28T17:48:01Z")
> [@aaronrumple](#):
>
> But for this node - it moves the point relative to their current location.
It moves the offset relative to the element’s local origin.
> [@aaronrumple](#):
>
> If it is at 100 and you apply an offset of 100 it will have a Z of 200, unlike the API.
That’s because your floor’s origin is at 100’. So offsetting the floor points by 100’ is still 100’ above the origin, which ends up being 200’. I don’t understand how this is different from the API though. You’re saying the API adds onto the existing elevation which would still be 200’.
> [@aaronrumple](#):
>
> You’ll see in this image I previously posted, point 54 is at 100.166. I add 0.001 to all the points and they all move to 100.001. Including point 54 which should read 100.167.
This is exactly my point. Your floor’s origin is 100’, so when you set the offset to 0.001 the new location is 100.001’. If your floor was drawn at 0’ then the new location would be 0.001’.
---
### Author:  [@aaronrumple](https://forum.dynamobim.com/u/aaronrumple)
#### Post date: [September 28, 2021, 7:57pm UTC](https://forum.dynamobim.com/t/floor-movepoint-rounding/68554/16 "2021-09-28T19:57:52Z")
I think I’ve tracked down the issue.
The node is ignoring 0. Which means you can’t reset the slab points to a flat slab with this node alone.
here’s a simple move +100. Works as expected.
Now to reset with 0.
Note points remain at 200.
Now to input 0.001.
Everything moves to 100.001 as expected.
I think this combined with other things I was doing was giving the appearance of rounding.
But the API does take a 0 just fine.
So with just the nodes, you would have to copy out the points, reset the shape, re-enable the ShapeEditor and copy the points back in. But that has resulted in some odd things as well and seems to be a issue open in GitHub #1789. (I’m in R2020 as the military is way behind in versions.)
The API take 0 as an input just fine and does what is expected.
```auto
def floorMovePoints(myFloor, myOffset):
TransactionManager.Instance.EnsureInTransaction(doc)
slabeditor = SlabShapeEditor
mySlabs = []
myCoord = []
for myFloor in mySelection:
if myFloor.SlabShapeEditor.IsEnabled:
mySlabs.append(myFloor)
vertexArray = myFloor.SlabShapeEditor.SlabShapeVertices
for vertex in vertexArray:
myCoord.append(vertex.Position)
slabeditor.ModifySubElement(myFloor.SlabShapeEditor, vertex, myOffset)
TransactionManager.Instance.TransactionTaskDone()
return mySlabs
```