Rounding to integer types

[Angelo Bulfone]

Hello,

While I'm thankful for the 2022 standard explicitly saying after every single operation that the result must round according to the provided algorithm, the part on conversions from posits to other types is a notable exception. The float part explicitly says to use "the float rounding mode in use," which suggests using the native floating point operations, but the integer part only seems to specify the behavior of overflow and NaRs. It doesn't say how the value is supposed to be rounded when its a non-integer value. While nearestInt(), ceil(), and floor() let one produce integer posits with nearest-ties-to-even, towards +∞, and towards -∞ respectively, how should the default integer type conversions behave? Would it use nearest-ties-to-even like most operations, toward 0 like LLVM's floats, toward nearest-ties-to-max-magnitude like is usually first taught in schools, or something else?

[John Gustafson]

I understand the omission you are pointing out. Does anyone on this thread happen to know what IEEE 754 says should happen if you try to "convert" a number like 1.5 to an integer? Does it produce a NaN, or round, or say the behavior is not determinate? 

I suppose we did not consider nonsensical conversions, but they do need to be described and deterministic. Like, what if a programmer asks that the complex number 3 + 4i be "converted" to real? What should it do? It's just not a conversion. The programmer must specify more about what is wanted, like ignore the imaginary part, or take the magnitude, or whatever.

I have found about six small errors or omissions in the current (2022) version of the Standard. It might be time for a revision. 

Thanks,

John

On Oct 20, 2023, at 1:17 PM, Angelo Bulfone <mbul...@gmail.com> wrote:

Hello,

While I'm thankful for the 2022 standard explicitly saying after every single operation that the result must round according to the provided algorithm, the part on conversions from posits to other types is a notable exception. The float part explicitly says to use "the float rounding mode in use," which suggests using the native floating point operations, but the integer part only seems to specify the behavior of overflow and NaRs. It doesn't say how the value is supposed to be rounded when its a non-integer value. While nearestInt(), ceil(), and floor() let one produce integer posits with nearest-ties-to-even, towards +∞, and towards -∞ respectively, how should the default integer type conversions behave? Would it use nearest-ties-to-even like most operations, toward 0 like LLVM's floats, toward nearest-ties-to-max-magnitude like is usually first taught in schools, or something else?

--
You received this message because you are subscribed to the Google Groups "Unum Computing" group.
To unsubscribe from this group and stop receiving emails from it, send an email to unum-computin...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/unum-computing/5604d5fe-a5e7-4553-9ae0-881450f37803n%40googlegroups.com.

[Nathan Waivio]

"how should the default integer type conversions behave?"

I'm thinking defining conversions to integers may be outside the scope of the Posit Standard and is probably defined by the language spec of the programing language you are using.

Nathan.

[John Gustafson]

I think that's a great solution, thanks. Maybe others will weigh in.

John

To view this discussion on the web visit https://groups.google.com/d/msgid/unum-computing/6bf30fdc-2741-4786-857b-5da57e732bc6n%40googlegroups.com.

[MitchAlsup]

On Friday, October 20, 2023 at 8:07:32 PM UTC-5 johngustafson wrote:

I understand the omission you are pointing out. Does anyone on this thread happen to know what IEEE 754 says should happen if you try to "convert" a number like 1.5 to an integer? Does it produce a NaN, or round, or say the behavior is not determinate? 

IEEE 754-2019 states that the functions:: {nearestInt, floor, ceil, and a few more} must exist and that applicable languages have shortcut "names" to access IEEE 754-specified behavior; and that these names and defaults be adequately described in accompanying documentation. This effectively "passes the buck" to the compiler front end and run time library people.

As far as converting infinities to integer, maximum-positive (+Infinity) and maximum negatives (-infinity) are desired.

As far as converting a NaN (or NaR) to integer; signless zero (0) seems most appropriate.

{I use the word signless in case there are 1's complement or sign magnitude machines thinking about doing a posit implementation.}

The default conversion:: 

     i = f;

would be nearestInt() in C, and FORTRAM and would be dependent on the multiple-type-inheritance resolution of other languages like C++, Java, Ada,...

I suppose we did not consider nonsensical conversions, but they do need to be described and deterministic. Like, what if a programmer asks that the complex number 3 + 4i be "converted" to real? What should it do?

Languages {(such as FORTRAN) which have real-complex arithmetic specifications}, specify that the conversion of a complex number to an integer use the complex absolute value intrinsic. So, in this case one would get int(SQRT(3.0^2+4.0^2)) = 5

It's just not a conversion. The programmer must specify more about what is wanted, like ignore the imaginary part, or take the magnitude, or whatever.

So, these kind of specifications are best left to the languages. Then, what Posit/unum must define is the existence of conversions {nearestint(), floor(), ceil(); and possibly:: intnearestzero(), intfarthestfromzero() } and like 754-2019, specify that implementations must specify the mappings of float to integer into these intrinsics.

[MitchAlsup]

On Saturday, October 21, 2023 at 11:22:46 AM UTC-5 Nathan Waivio wrote:

"how should the default integer type conversions behave?"

I'm thinking defining conversions to integers may be outside the scope of the Posit Standard and is probably defined by the language spec of the programing language you are using.

Nathan.

Yes, but posit/unum standard needs to specify the intrinsic primitives so languages have well defined mappings to them. 

[Andrew Marlow]

Hello, I'd like to weigh in with a C++ perspective, please. I do think it is a matter of what language defines. In IEEE floating point C and C++ define assignment to integers to result in truncation. This is, IMHO, a bit nasty and static code analysers warn you when this is going on. Compilers typically don't. Most of the time the programmer does not want truncation and will be unaware when they have accidently coded like this unless they use a static code analyser. I think that C and C++ implementations of posits should consider this and be no worse than what happens with IEEE. This means a worse case scenario of truncation. IMO a warning or even a compilation error would be better but that would be a significant difference between IEEE floating points and posits.

Finally, I think it muddies the waters slightly to mention copying a complex number to an integer. In C++ that results in a compilation error. This is because the standards committee took the view that the coder needs to be explicit about what they want to happen. If they want the modulus they should use int n = std::abs(z). If they want the real part they should use double d = std::real(z).

To view this discussion on the web visit https://groups.google.com/d/msgid/unum-computing/EB4E8045-2BFC-4F36-9EF9-2548C0F3B486%40earthlink.net.

--

Regards,

Andrew Marlow
http://www.andrewpetermarlow.co.uk

[John Gustafson]

Mitch,

It sounds like you might not have seen the Posit™ Standard (2022). For your convenience, I've attached it here. The requisite definitions are in Section 5.2 where floor, ceiling, and nearestInt are specified.

If x holds a posit with value 1.5 that is assigned to an integer variable n, implying a conversion, some languages might opt to declare an error and halt, while others might say in the language standard that, for instance, nearestInt is to be used. This means there should be at least a footnote indicating it is outside the scope of the arithmetic standard to choose, but any language that supports posit arithmetic must state what the behavior will be and it must be deterministic.

John

[MitchAlsup]

Thank you for a copy of the posit standard.

I notice {nearestInt, floor, and ceil} but not {Intnearestzero and intfartestfromzero}.

The 3 specified are adequate, but specifying all 5 satisfies everyone.

[Angelo Bulfone]

From what I've gathered, for the library I've been working on recently, I probably won't have a generic "to_int" method, but instead have different methods for converting to integers with each rounding mode. In general though, it should be possible to simulate the other forms with just the floor(), ceil(), and nearestInt() functions given in the standard, followed by the conversion, so even if the rounding is unspecified, it should still be possible for a user to get the rounding mode they want (assuming it's up, down, or nearest-ties-to-even).

[John Gustafson]

We expect to add more functions to the Posit Standard eventually, to match what you get in a typical C math library. You can always do that without creating backward incompatibility. I'd like to see Bessel functions, gamma function, erf and erfc, for example. For the first version, we were aiming for "as simple as possible, but no simpler".

It's awfully easy to construct one-liner real-to-integer functions that round toward zero or round away from zero. Heck, you can even get rid of ceil(x) by just using –floor(–x), right?

John

--
You received this message because you are subscribed to the Google Groups "Unum Computing" group.
To unsubscribe from this group and stop receiving emails from it, send an email to unum-computin...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/unum-computing/99aabdf8-e102-4594-a0cb-534a3eaa950fn%40googlegroups.com.

[Angelo Bulfone]

resisting urge to request pi function over gamma function

--

Angelo