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.
