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> wrote:
>
> On Thu, Nov 29, 2018 at 2:00 PM Robert Engels <reng...@ix.netcom.com> 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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
