so for the next 5 minutes I can answer every rounding related question for IEEE 754 floating points.
-
so for the next 5 minutes I can answer every rounding related question for IEEE 754 floating points.
Be fast before I forget all of it again.
I had to fix some annoying integer to fp16 rounding mode mess ups, sooo.. yeah....
-
so for the next 5 minutes I can answer every rounding related question for IEEE 754 floating points.
Be fast before I forget all of it again.
@karolherbst Why is round-to-odd not a standardized rounding mode? Separately, why is rounding on operations specified as a mutable environment instead of as a parameter?
-
@karolherbst Why is round-to-odd not a standardized rounding mode? Separately, why is rounding on operations specified as a mutable environment instead of as a parameter?
@pthariensflame sorry, I saw your message too late, I already forgor
-
@pthariensflame sorry, I saw your message too late, I already forgor
@karolherbst That's okay, so did the IEE754 committee themselves.
-
@pthariensflame sorry, I saw your message too late, I already forgor
@pthariensflame but I might be able to answer anyway:
1. no idea, the spec doesn't say
2. the spec only defines rounding modes, not how implementations make those available. So in the spec it's actually defined as functions with "roundTowardZero", etc... in the name.
-
@pthariensflame but I might be able to answer anyway:
1. no idea, the spec doesn't say
2. the spec only defines rounding modes, not how implementations make those available. So in the spec it's actually defined as functions with "roundTowardZero", etc... in the name.
@pthariensflame OpenCL C actually does it explicitly, e.g.: "convert_half_rtn(uint)`
-
@pthariensflame OpenCL C actually does it explicitly, e.g.: "convert_half_rtn(uint)`
@karolherbst Yeah, for the explicit rounding operations themselves. I meant more during the arithmetic operations, which don't take a rounding mode parameter in the spec and instead are treated by Chapter 4 of the spec as "rounding direction attributes" and recommended to be dynamically updatable.
-
@karolherbst Yeah, for the explicit rounding operations themselves. I meant more during the arithmetic operations, which don't take a rounding mode parameter in the spec and instead are treated by Chapter 4 of the spec as "rounding direction attributes" and recommended to be dynamically updatable.
@pthariensflame ah yes, I have no idea what you are talking about 🙃 excuse me, my ice-cream is calling for me.
-
@pthariensflame ah yes, I have no idea what you are talking about 🙃 excuse me, my ice-cream is calling for me.
@karolherbst Fair; may the ice cream be tasty and the container not get too soggy. ^.^
-
so for the next 5 minutes I can answer every rounding related question for IEEE 754 floating points.
Be fast before I forget all of it again.
-
@acidiclight that's alright. The reason it causes headaches is that when brains were originally designed after CPUs, it was at the time where CPUs didn't contain FPU units, therefore we aren't capable of comprehending floats.
I hope that helps.
-
undefined oblomov@sociale.network shared this topic
-
@karolherbst Yeah, for the explicit rounding operations themselves. I meant more during the arithmetic operations, which don't take a rounding mode parameter in the spec and instead are treated by Chapter 4 of the spec as "rounding direction attributes" and recommended to be dynamically updatable.
@pthariensflame
the reason for the attribute is simplicity (no extra parameter), which maximizes usability since you don't need to specify the rounding mode every time. Since in most cases the rounding choice is the same in a block of code, this makes the code simpler to write. Imagine if instead of being able to do a + b for floats you'd have to do plus(a, b, rounding_mode, exception_handling_mode). For every instance of every operation 8-D