Why should I use floats for internal representation then? say instead of increasing 4 per tick, I increased 4.5, it would be truncated to 4 always, and if rounded, to 5 always, so I can't really see why would you want use floating point values.

I'm using ints for everything (using SDL so I cannot use floats no matter what).
Also, the changing factor is frames per second (sometimes framerate drops by 1 so it oscillates between 59-60) and not the amount of pixels moved every second. 240 p/s is an approximation too, I would say 220 - 250 would be a decent range for the pixels moved every second by the sprite to be a good gameplay.

I tried logging the time (before regulating the FPS) in milliseconds for each frame, and it gives a steady range of 0 to 1 ms.
After regulating FPS, the time is ~16 ms , which gives about 60 FPS. As far as I've observed there are no frames being skipped.
The motion blurred texture idea sounds cool, but I'm sure there is a more straightforward solution to the problem.

The pixel data and game logic is both refreshed and handled respectively at 60Hz , and the sprite is moved by using arrow keys:
if I move the sprite 1 pixel a tick (60 ticks in 1 second, 1 tick = 0.016~ s, so 1 tick = 16 ms), it is smooth, however the sprite only moves 60 p/s, which is slow for the gameplay. If I move it, say 4 pixels per tick (4 pixels every 16 ms), it is certainly fast for gameplay, as it moves 240 p/s, however the animation is not smooth, and looks like the sprite is teleporting small distances (basically, the animation is choppy).
I feel like I cannot achieve a smooth and fast animation and have to make a trade off. Is there a solution to this problem? I've heard about frame independent sprite movement but I don't understand it fully.