Btw, thus includes == when using NaN and float64. It’s strange but that’s the
way it’s defined.
> On Nov 29, 2018, at 7:46 AM, Robert Engels <reng...@ix.netcom.com> 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 <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.
--
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.
