Anything more complicated than real number processing?

[munair]

Since 2021 I've been working off and on developing the SharpBASIC compiler. In my experience one of the most complicated aspects I've come across is real number computation and especially conversion. Real numbers just don't really fit in the world of binaries and integers and there are many options to adjust FPU behavior. Libraries have been developed such as Dragon4 and Grisu to improve precision, but at the cost of performance. But even without high precision it takes a lot of time figuring out how to get a routine working correctly that performs a seemingly simple task of converting a single precision number to string, especially if it should support even basic E-notation. Sure, there's printf and other C dependencies. But I refuse to make SharpBASIC dependent on C libs. I suppose Pascal lovers feel the same way.

Also interesting is how compilers have their own procedure conventions. C adds parameters on the stack backwards and accesses them forward. Pascal (from what I know) adds parameters forward and accesses them backwards (like SharpBASIC). But Pascal cleans up the stack inside, while C and SharpBASIC let the caller handle that. For this purpose SharpBASIC introduced two keywords to specifically reference C procedures (cdecl) and Pascal procedures (pdecl).

And so the journey continues.

[Thaddy]

No, just take a degree. 

Many things in life do require it.
If you don't know why it does not work, figure it out......

That is also the science part.

If you know what science means, you also know that you have to be curious.
That's a Boolean.

[munair]

No, just take a degree. 

Simply taking a degree doesn't solve it. When I said figuring out how to get a routine working correctly, I meant that programming FPU isn't straight forward. There are rounding modes which you need to switch at specific stages. There are stack limitations. What is the state of the FPU, etc. It doesn't necessarily take a degree, but it takes TIME.

[Thaddy]

OK, Take three....

[MathMan]

Hello munair,

I'm not sure, if I fully understood your plea - but if you are looking for standalone prooven correct conversions between binary and decimal float then take a look at 'Ryu'. As a bonus it is superbly fast.

On a personal note, I would at least consider conversion to/from hexadecimal representation too.

If you are also looking for correctly rounded (all rounding modes) elementary functions then take a look at the 'CORE-MATH' project.

Regards,
MathMan

[munair]

Hello munair,

I'm not sure, if I fully understood your plea - but if you are looking for standalone prooven correct conversions between binary and decimal float then take a look at 'Ryu'. As a bonus it is superbly fast.
On a personal note, I would at least consider conversion to/from hexadecimal representation too.
If you are also looking for correctly rounded (all rounding modes) elementary functions then take a look at the 'CORE-MATH' project.

Regards,
MathMan

Thanks for the suggestions MathMan. I'm actually trying to build an independent runtime library with basic functionality, but importing libraries with different calling conventions will be supported. Conversion too/from BIN, HEX and OCT is implemented, at least for integers.

[munair]

If you know what science means, you also know that you have to be curious.
That's a Boolean.

If I wouldn't be curious, I would never have started the project in the first place.

[440bx]

In my experience one of the most complicated aspects I've come across is real number computation and especially conversion.

Yes, dealing with floating point numbers is a whole lot more involved than dealing with integers.  There is a lot to it and, it's really complex.

I'll have to check @MathMan's suggestion out too.    Thank you @MathMan.