summary: converting to int from NaN results in arch dependent values.
use case: i'm using ints (scaled) for a type where this is the real underlying meaning. but to avoid rounding issues in intermediate comp, i convert to float for these, and then back. this seemed fine. but.... for a particular use i increased the resolution of my scaled int from int32 to int64. and the arm code broke! (the amd64 didn't) what i find is this; int32(NaN) returns math.MinInt32 on both amd64 and armv7(32bit) int64(NaN) returns math.MinInt64 on amd64 but ZERO on armv7(32bit) i see that NaN isn't really defined as an int, so any returned value isn't 'incorrect', but shouldn't the value returned be consistent across architectures? these end-of-range values play fine with my algorithm but 0 doesn't. i've fixed by special-casing NaN values. (may end up using a build flag.) extra info: int32(NaN) and int64(NaN) both return 0 on armv5 -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/4a5912d8-62bb-4ba3-bf47-7d00dc0fc9c8o%40googlegroups.com.
