# Difference between revisions of "Talk:Ieee arithmetic"

Colin-adams (Talk | contribs) (→Postcondition for put: new section) |
|||

Line 19: | Line 19: | ||

* Does it mean that <e>REAL_GENERAL</e> should inherit <e>PART_COMPARABLE</e> rather than <e>COMPARABLE</e>? | * Does it mean that <e>REAL_GENERAL</e> should inherit <e>PART_COMPARABLE</e> rather than <e>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>? | * 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>? | ||

+ | |||

+ | == Postcondition for put == | ||

+ | |||

+ | the postcondition for {ARRAY}.put should read: | ||

+ | |||

+ | inserted: v = v implies (item (i) = v) | ||

+ | undefined_case: v /= V implies (item (i) /= item (1)) | ||

+ | --[[User:Colin-adams|Colin-adams]] 12:37, 4 February 2010 (UTC) |

## Revision as of 04:37, 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_GENERAL`

should inherit`PART_COMPARABLE`

rather than`COMPARABLE`

? - Do we need 2 equality queries: one that tells two objects represent the same value (it is used to ensure
`copy`

does 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`

?

## Postcondition for put

the 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:37, 4 February 2010 (UTC)