BenchmarkAddFixed-8 2000000000 0.83 ns/op 0 B/op 0 allocs/op
BenchmarkAddDecimal-8 3000000 457 ns/op 400 B/op 10 allocs/op
BenchmarkAddBigInt-8 100000000 19.2 ns/op 0 B/op 0 allocs/op
BenchmarkAddBigFloat-8 20000000 110 ns/op 48 B/op 1 allocs/op
BenchmarkMulFixed-8 100000000 12.4 ns/op 0 B/op 0 allocs/op
BenchmarkMulDecimal-8 20000000 94.2 ns/op 80 B/op 2 allocs/op
BenchmarkMulBigInt-8 100000000 22.0 ns/op 0 B/op 0 allocs/op
BenchmarkMulBigFloat-8 30000000 50.0 ns/op 0 B/op 0 allocs/op
BenchmarkDivFixed-8 100000000 19.3 ns/op 0 B/op 0 allocs/op
BenchmarkDivDecimal-8 1000000 1152 ns/op 928 B/op 22 allocs/op
BenchmarkDivBigInt-8 20000000 68.4 ns/op 48 B/op 1 allocs/op
BenchmarkDivBigFloat-8 10000000 151 ns/op 64 B/op 2 allocs/op
BenchmarkCmpFixed-8 2000000000 0.28 ns/op 0 B/op 0 allocs/op
BenchmarkCmpDecimal-8 100000000 10.8 ns/op 0 B/op 0 allocs/op
BenchmarkCmpBigInt-8 200000000 8.37 ns/op 0 B/op 0 allocs/op
BenchmarkCmpBigFloat-8 200000000 7.74 ns/op 0 B/op 0 allocs/op
BenchmarkStringFixed-8 20000000 99.0 ns/op 16 B/op 1 allocs/op
BenchmarkStringDecimal-8 5000000 326 ns/op 144 B/op 5 allocs/op
BenchmarkStringBigInt-8 10000000 209 ns/op 80 B/op 3 allocs/op
BenchmarkStringBigFloat-8 3000000 571 ns/op 272 B/op 8 allocs/op
-j
- To me type name 'fixed.Fixed' sounds like Javaism. Go code usually tries to avoid such stutter: 'sort.Interface', 'big.Int' etc.
- 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.
- I'd prefer a single constructor 'New(int64)' and methods 'SetString', 'SetFloat' etc.
> The benchmarks: (Decimal is the shopspring library, big Int/Float are the stdlib)I don't consider comparing performances of 64 bit integer arithmetic and arbitrary sized arithmetic very useful.
---j
-j
-j
--
-j
-j
--
-j
Now given that dot imports are generally considered a bad idea in Go
--
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.
For more options, visit https://groups.google.com/d/optout.
-j
-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.
For more options, visit https://groups.google.com/d/optout.
--
Any of these is fine to me, but having a variety of them is testament to the addition of image format support at different times by different hands and it would seem sad if Go17 was still this way. Instead, now that examples exist for each style, why not pick one of them (any one!) and convert the others to the same scheme. I know itr would be arbitrary breakage now, but that's paying forward for technical debt. When 1M Go developers becomes 10M, we'll have at 9M happy campers who never realized it was "wild" (disharmonious, unmutual) in the old days.
On Thu, Nov 29, 2018 at 2:00 PM Robert Engels <ren...@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