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.
