I agree about the stutter naming. The name should at least specify the
bitwidth of the integral and fractional parts, to follow the pattern of the
fixed width types already existing. Fixed is easy enough to infer that it
is a fixed point type, by the package. You could name the types based on
the format convention - such as the precision used in various financial
fields, and related to the currency, for example the difference between Yen
and Dollars, the former not including a fractional value at all (The
japanese are of course better at mathematics than most of the rest of the
world, their approach is better and also used in several other currencies
like the Serbian Dinar, though in Serbia they still have 2 decimal places
in the accounting despite the non-existence of fractional dinars).
Also it makes sense to me that you would embed the type inside a struct, as
these parameters would need to be available in order to provide multiple
bit width parameter types (and would be necessary, for example, in forex
trading there is a name 'pip' meaning some number of decimal places), and
I think that obviously, if one were to instead use an alias for uint64 or
whatever, that the users of the library could make the mistake of using
inbuilt math operators on it and get entirely wrong results, whereas the
struct type implicitly will compile-time refuse to play that game.
On Thursday, 29 November 2018 14:21:21 UTC+1, Jan Mercl 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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
