Just working with numbers these days i wonder if i can compile gcc with fixed point support , like if i use float in source it should implement my fixed point implementation rather than ieee floating point standards

*pssss*

Macros

*Fades away into the dark alley*

That would be horrible design. Why would you want to use *fixed* point types when the code uses *floating* point types? Why not just use a library?

One of the things I love about computers and programming is that there is always shit I’ve never heard of that people r working on. It just gives me more to learn. I wish u luck OP

@RememberMe it was a attempt to make things faster as some hardwares does hot have FPU,
Sign long long math gives enough precision for most task

Code looks like dog shit if i use library, i want basic operators to work directly

@hardfault I'm aware what fixed point is used for, but it's still a mistake to substitute floating point with that. So many concepts don't translate at all like NaN and epsilon and multiple zeros and the immense range of float/double and the different ways of handling precision issues, even if you get over the horrid design that would be crossed expectations with writing one thing and doing something else. If I write "float" I expect it to fully behave like one, including the entire floating point standard. Fixed point is a different thing for a different set of use cases, I'd prefer it marked explicitly.

You could use C++ with some operator overloading to define a fast "fixed" type and expression templates to remove intermediate objects and there you have it, "native" syntax for fixed points. As a bonus you could make the size of the fixed type and the location of the point template parameters.

@RememberMe you should look up thi s

https://youtu.be/8tOhdUXcSkw

Don’t think the three concept you mentioned have that much value .
If It’s performance gain vs NaN( as a feature )i will always choose performance gain 😅

@hardfault I work with HPC stuff - trust me it's important. What's the point of a calculation if you can't trust the result or establish a bound on precision? It's super easy to go really fast and get the wrong answer. Only in cases when you're *sure* that precision issues aren't going to be a problem (which you do by making precision bounds for every step of a calculation) can you afford to turn off this stuff. Try doing this trick with something as "simple" as normalizing a large vector - one slip and you'll get absolute garbage even though your calculation looks right.

Hurray for these guys that they found a use case where such an adhoc conversion is actually legit (porting existing code that nobody wants to rewrite - fair enough there) and where it worked without blowing up with numerical errors, but in general, if you're writing new code, please don't do this. Use a language like C++ which has more abstraction power than a pOrtAbLE aSsEmBLeR or use a library.

I'm not saying that your way isn't valid at all - I just wouldn't trust it in general.