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 <reng...@ix.netcom.com> 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> 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.
--
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.
