Yes it does (for some reason I was thinking that Cmp returning 0 was false but it's not it's equals :) ), I'm not sure Cmp can be implemented in that case, at least without panicing NaN == NaN should be false, the other packages like decimal & big don't seem to have an issue as NaN can't exist? Could be wrong.
On Thursday, November 29, 2018 at 1:46:48 PM UTC, Robert Engels wrote: > > Technically, a NaN in comparison with any other including NaN is false. > For Cmp this creates a problem.... > > On Nov 29, 2018, at 7:41 AM, Robert Engels <ren...@ix.netcom.com > <javascript:>> wrote: > > Ah, you want a ctor that is the int value. Ok. The Raw doesn’t do this > anyway... I could add a NewI() ctor but I’m not sure it is much that > NewF(float64(x)) given the magnitude restrictions. > > If you review the gotrader you’ll see that it uses a dot import on this. > If it was just Number you lose a lot of information. I find it makes the > structures far more readable for a common type. > > Java’s BigInteger has this exact optimization when the value fits in a > single word. Go could do this too so it is a fair performance comparison > IMO. > > On Nov 29, 2018, at 7:20 AM, Jan Mercl <0xj...@gmail.com <javascript:>> > wrote: > > On Thu, Nov 29, 2018 at 2:00 PM Robert Engels <ren...@ix.netcom.com > <javascript:>> wrote: > > > >> - To me type name 'fixed.Fixed' sounds like Javaism. Go code usually > tries to avoid such stutter: 'sort.Interface', 'big.Int' etc. > > To me that’s a limitation of Go with small packages like this that only > have a single public struct. It is based on decimal.Decimal so I’m not the > only one who thinks this.... > > I don't think we are talking about the same thing here. Go idiom is to > name types such that they are not the same as the package qualifier (modulo > case) at the caller site. So the exported type should be 'Int', or 'Float' > or 'Real' or 'Number', etc., not 'FIxed' to avoid 'fixed.Fixed' at caller > site. `var n fixed.Number` looks better to me, for example, than `var n > fixed.Fixed`. The later actually does not even communicate any hint what > the type could possibly be. > > >> - A struct with a single field could be replaced by the field itself. > OTOH, it would enable coding errors by applying arithmetic operators to it > directly, so it's maybe justified in this case if that was the intention. > > It was the intention. The Raw methods are there temporarily and will be > removed for direct serialization via a Writer. > > Then it looks strange that to construct a Fixed from int64 one has to > write 'fixed.NewF(0).FromRaw(42)'. Check the big.{Int,Float,Rat) > constructors and setters, they are much more natural to use. > > >> - I'd prefer a single constructor 'New(int64)' and methods 'SetString', > 'SetFloat' etc. > > Not possible. The caller doesn’t know the int64 value. Also, think of > how that would look in a chained math statement. Horrible. > > It _is_ possible. You've misunderstood. New(n int64) returns a Fixed that > has the _value_ of n, which of course has a different underlying int64 bit > pattern in the private Fixed field. The caller want New(42) meaning 42 and > does not casre about the internal, scaled value, that's just an > implementation detail and no business of the caller. BTW: Chained math > statements where the operators are written as function calls, above chains > of length 2 are not seen very often. Longer ones, in many cases, well, > that's what I'd call horrible. > > >> I don't consider comparing performances of 64 bit integer arithmetic > and arbitrary sized arithmetic very useful. > > Those are the alternatives to use when performing fixed place > arithmetic. In fact decimal.Decimal uses big Int... so it is included for > reference. > > The point being made here is fixed size fitting to a machine word on a 64 > bit CPU vs arbitrary sizes math libs implemented inevitably by multiple > word structs with pointers to backing storage and the necessary allocation > overhead. Apples to oranges. Not even in the same league. > > -- > > -j > > -- > 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...@googlegroups.com <javascript:>. > For more options, visit https://groups.google.com/d/optout. > > -- 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.