Difference between revisions of "Talk:Ieee arithmetic"
(→Postcondition for put) |
|||
| Line 20: | Line 20: | ||
* Do we need 2 equality queries: one that tells two objects represent the same value (it is used to ensure <e>copy</e> does what is expected, and it is used to implement <e>~</e>) and the other one that tells that the numbers are equal in terms of ordering relation of <e>(PART_)COMPARABLE</e>? | * Do we need 2 equality queries: one that tells two objects represent the same value (it is used to ensure <e>copy</e> does what is expected, and it is used to implement <e>~</e>) and the other one that tells that the numbers are equal in terms of ordering relation of <e>(PART_)COMPARABLE</e>? | ||
| − | --[[User:Colin-adams|Colin-adams]] 12:37, 4 February 2010 (UTC): '''Postcondition for {ARRAY}.put''' should read: | + | '''--[[User:Colin-adams|Colin-adams]] 12:37, 4 February 2010 (UTC)''': '''Postcondition for {ARRAY}.put''' should read: |
<e> | <e> | ||
inserted: v = v implies (item (i) = v) | inserted: v = v implies (item (i) = v) | ||
| Line 26: | Line 26: | ||
</e> | </e> | ||
| − | + | '''--[[User:Colin-adams|Colin-adams]] 12:42, 4 February 2010 (UTC)''': I have previously suggested separating the notion of numerical equality and object equality. Eric said that we use = for three different notions, i think, but I don't remember what these were. Certainly PART_COMPARABLE is better than COMPARABLE for IEEE math types. I'm not sure if that is sufficient or not. | |
| − | + | ||
| − | I have previously suggested separating the notion of numerical equality and object equality. Eric said that we use = for three different notions, i think, but I don't remember what these were. | + | |
| − | + | ||
| − | Certainly PART_COMPARABLE is better than COMPARABLE for IEEE math types. I'm not sure if that is sufficient or not. | + | |
| − | + | ||
Revision as of 11:47, 4 February 2010
Most probably C compilers inline functions, but just to be sure, I'd convert them into the macros:
#define to_raw_bits(d) *((EIF_NATURAL_64*)&(d)) #define eif_is_nan_bits(value) ((value & ~RTU64C(0x8000000000000000)) > RTU64C(0x7ff0000000000000)) #define eif_is_nan(v) ((*((EIF_NATURAL_64 *)&(v)) & ~RTU64C(0x8000000000000000)) > RTU64C(0x7ff0000000000000))
Does it affect the benchmarks?
- --manus 17:59, 3 February 2010 (UTC) Actually it does not on Windows for sure, I've verified that it was inlined. But you are right that those could be simply defined as macros.
- --manus 20:25, 3 February 2010 (UTC) I've done again some of the benchmarks and on windows at least, some of them are slower when I use a macro. I'm no sure why I haven't looked at the generated assembly code.
--Colin-adams 14:48, 3 February 2010 (UTC) Not IEEE arithmetic, nor maths, NaN = NaN is never true. And placing NaNs in a sort order isn't write either - REAL_32/64 are not totally ordered types.
- --manus 17:57, 3 February 2010 (UTC) How do you solve the problem of assertions then in ARRAY.put for example?
--Alexander Kogtenkov 20:01, 3 February 2010 (UTC)
- Does it mean that
REAL_GENERALshould inheritPART_COMPARABLErather thanCOMPARABLE? - Do we need 2 equality queries: one that tells two objects represent the same value (it is used to ensure
copydoes what is expected, and it is used to implement~) and the other one that tells that the numbers are equal in terms of ordering relation of(PART_)COMPARABLE?
--Colin-adams 12:37, 4 February 2010 (UTC): Postcondition for {ARRAY}.put should read:
inserted: v = v implies (item (i) = v) undefined_case: v /= V implies (item (i) /= item (1))
--Colin-adams 12:42, 4 February 2010 (UTC): I have previously suggested separating the notion of numerical equality and object equality. Eric said that we use = for three different notions, i think, but I don't remember what these were. Certainly PART_COMPARABLE is better than COMPARABLE for IEEE math types. I'm not sure if that is sufficient or not.
