As stated by VOR73X, the reason in this case is that the file is a 32-bit executable on a 64-bit architecture. You can run it, but you need a compatibility layer to do so. If you have it:
mintaka:/home/lserni # file ansi
ansi: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.2.5, not stripped
mintaka:/home/lserni # uname -a
Linux mintaka 4.0.1-1-default #1 SMP Wed Apr 29 15:04:53 UTC 2015 (e3a374a) x86_64 x86_64 x86_64 GNU/Linux
mintaka:/home/lserni # ./ansi
Syntax: ansi [file|-]
...and otherwise you get 'no such file or directory'.
However, there might be other reasons to be unable to run a file that "seems" to be there (or even is).
Missing dynamic libraries would give a distinctive error (at least they do on my system, Linux OpenSuSE 13.2):
./test: error while loading shared libraries: libcap.so.2: cannot open shared object file: No such file or directory
Another possibility...
...is that the file is not named as you think it is. The file you asked for is really not there!
For example (using the same obsolete file as before)
mintaka:/home/lserni # mv ansi 'ansi '
mintaka:/home/lserni # ls -la ansi*
-rwxr-xr-x 1 root root 14268 Sep 17 23:29 ansi
The file seems to be there but its name now ends with a space, so as you would expect...
mintaka:/home/lserni # ./ansi
bash: ./ansi: No such file or directory
Of course if the file is called correctly, escaping the space...
mintaka:/home/lserni # ./ansi\
Syntax: ansi [file|-]
mintaka:/home/lserni #
Other tricks are possible (I did it to myself once by mistake and have seen some worm using this trick to hide from a casual 'ls'). For example UTF8 invisible characters.
Try
ls -la | hexdump -C
to verify that the name is indeed what it ought to be.