Hi, I was investigating the possibility of develop...

# getting-started

[Ilya]

Hi, I was investigating the possibility of developing a custom numeric type in kotlin that would follow my precision needs, as well as have NaN support

In the process I found that I cannot implement the comparison operators `<`/`>`/`<=`/`>=` the way I want, so that they adhere to IEEE 754
Since each one of those four operators desugars to a call of compareTo, no matter what I return from it, I’ll not be able to have all four of the operators return false when given a NaN argument

For the builtin types of Float and Double the compiler performs some special-casing as described here. But what can be done from the side of a language user, when having the need to implement such behavior?

[CLOVIS]

As far as I know, it is not possible to do this on the end-user side

[CLOVIS]

cc @MiguelDecimal128, I remember you had the same problem, what did you do in the end?

[CLOVIS]

Personally for KtMongo's Decimal128 implementation, I went with prioritizing the sort order, meaning that NaN always compares as smaller than any other value.

[Ilya]

Ahh, thank you very much for the confirmation and the pointers

[MiguelDecimal128]

Ilya,
I am implementing IEEE754-2019 decimal128 for kotlin multiplatform.

> I found that I cannot implement the comparison operators ``/``/`=`/`=` the way I want, so that they adhere to IEEE 754
This is true.
I have decided to follow two different models.
An easy model that behaves like Java Double ... not IEEE compliant but easy-to-use and approachable. I believe this will address the needs of 95% of the community.
My more complex model is 100% IEEE-compliant ... and is harder to use.

I would be eager to discuss this with you further.

Miguel

[MiguelDecimal128]

To answer your specific question regarding comparison operators ...

Under my java-compliant easy model, the comparison operators work fine.
Under the ieee-compliant model they do not work, but I will provide alternate infix comparison operators LT LE EQ NE GT GE named in the spirit of FORTRAN

[Ilya]

I see, thank you very much for the detailed answer
Custom infix operators seems like a pretty good idea

[MiguelDecimal128]

that would follow my precision needs, as well as have NaN support

I am interested ... what are your need regarding precision?

[Ilya]

It seems to be quite similar to what you’re doing, financial usage with values relating to a large variety of currencies

[MiguelDecimal128]

Are you interested in working together?

[Ilya]

Unfortunately that won't be possible since I'm working commercially on my project

[MiguelDecimal128]

I understand that you may not be able to contribute.
When I release com.decimal128.Decimal under the MIT license, would the company be able to use it ?

[Ilya]

No, due to implementation specifics that I am unable to disclose