Scratch that, just seen your original reply to Jan about them being temporary.
On Thursday, November 29, 2018 at 1:32:10 PM UTC, Jamie Clarkson wrote: > > Also I fail to see the point of the ToRaw/fromRaw when you could just make > FP public. > > On Thursday, November 29, 2018 at 1:28:40 PM UTC, Jamie Clarkson wrote: >> >> I think the logic should be that if either operand is NaN the comparison >> should be false to match floats (currently it looks like f < NaN and NaN < >> f give incorrect results), you might have some reason for that though. >> >> A few other random thoughts: >> >> - Not all methods/funcs are documented (which might clear up the above). >> - It might be nice to have a clamped set for a floating value out of >> range (rather than just return a NaN). >> - Can't see a way to create from an integer (other than convert to float) >> - Personally I'd rather not see a NewS() which can silently fail with no >> info, I'd prefer to rename NewSErr to Parse and remove NewS. >> >> Other than that, pretty cool. >> >> Cheers, >> >> Jamie >> >> On Thursday, November 29, 2018 at 1:01:39 PM UTC, Robert Engels wrote: >>> >>> NaN cannot be returned in an int so not possible. >>> >>> > On Nov 29, 2018, at 4:41 AM, messju mohr <li...@lammfellpuschen.de> >>> wrote: >>> > >>> > Hello, >>> > >>> > this looks like a really nice and useful library! :) >>> > >>> > Just one thing: At first glance i saw that fixed.Cmp() returns 0 when >>> both operands are NaN. >>> > I think it would be more consistent if fixed.Cmp() would return NaN if >>> any of it's operands are NaN. >>> > >>> > just my 2ct >>> > messju >>> > >>> > >>> >>> -- 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. For more options, visit https://groups.google.com/d/optout.
