Re: [go-nuts] [ANN] fixed point math library

m! Yes, using pure integer values for currency is generally the best way to deal with it. The Bitcoin standard is that 1 BTC = 10,000,000 'satoshis'. Many rightly point out that this is a stupidly small precision, but for the time being is ok. I personally would expand this, and just use a

Re: [go-nuts] [ANN] fixed point math library

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 t

Re: [go-nuts] [ANN] fixed point math library

Please stay polite, and please follow the code of conduct (https://golang.org/conduct). Thanks. Ian -- 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+

Re: [go-nuts] [ANN] fixed point math library

I need to do a thorough summary, but as an example of things that could usefully change (perhaps) for improved coherence and excellence in Go2 through naming and simple rewrites, consider the image package. 1. The name of the package (fine always it seem, but in some cases maybe a change would hel

Re: [go-nuts] [ANN] fixed point math library

I disagree with a few of those, but the simplest example is image. There still needs to be an image.Image interface for methods common to all image types. Then sub packages for raster and vector (others?) There are too many different image types so you end up a multitude of packages and since p

Re: [go-nuts] [ANN] fixed point math library

I'll also add that personally I saw a lot of "change this" commentary with rather little "thank you." That was not in the best spirit of what (at at least I think) it should be. It's always good to act on ideas, build solutions, and share results. It would be great if everyone always started with t

Re: [go-nuts] [ANN] fixed point math library

A hash function is a mathematical construction. A raster image is a type of graphical representation. A time instant is a single point in a duration. All of these are clear as can be. I'll give you "context frame". It is a bit wonky. A better phrase is out there somewhere. Scope, environment, etc

Re: [go-nuts] [ANN] fixed point math library

I can see why you're feeling that. My sense is that what causes flare-ups is when people (universally rather than just here) get the feeling that the discussion is becoming personal rather than technical. Go is lots of people's work / tool / job / fun / etc., so passions may be strong, but I've nev

Re: [go-nuts] [ANN] fixed point math library

Sorry, more than few is too many. Few is more appropriate. And before this goes farther. It was a thread I started to announce a project some might find useful or interesting. It was hijacked by the powers and turned into something else. It wasn’t the point, nor what I wanted. > On Dec 1, 2

Re: [go-nuts] [ANN] fixed point math library

This is a problem with it seems more than a few in this community. Someone makes a criticism of an idea, backs it up, and is treated in a childish manner because it doesn’t go along with dominate opinions of the controllers of the group think. Not good IMO. > On Dec 1, 2018, at 7:48 AM, Jan Me

Re: [go-nuts] [ANN] fixed point math library

On Sat, Dec 1, 2018 at 9:47 AM Dan Kortschak wrote: > Very nice. Indeed . -- -j -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiv

Re: [go-nuts] [ANN] fixed point math library

And let’s keep going, the sha256 package handles sha256 and sha224 ? Huh? And the NewX return hash.Hash rather than the concrete type - which would be fine except for the implicit Marshall interfaces. If they returned the concrete type I could have my own interface HashWithMarshall it could be a

Re: [go-nuts] [ANN] fixed point math library

And while we’re at it, take a closer look at the hash package https://golang.org/pkg/hash/#Hash Especially the example and the doc surrounding it. Why doesn’t Hash “extend” the binary marshall interfaces? Why the need to cast if the documentation says it does? There are a lot of low hanging f

Re: [go-nuts] [ANN] fixed point math library

hash.Function? Then you need print.Function. So soon enough there will be a 1000 interfaces named Function that have nothing to do with hashing or printing because everything can be decomposed that way. context.Frame? Now you’re just being silly. You might as well use context.Instance or even

Re: [go-nuts] [ANN] fixed point math library

Very nice. On Sat, 2018-12-01 at 00:16 -0800, Anthony Martin wrote: > Nigel Tao once said: > > > > Well, there's already context.Context, hash.Hash, image.Image and > > time.Time in the standard library. > All of which are not great. Better names are context.Frame, > hash.Function, raster.Image,

Re: [go-nuts] [ANN] fixed point math library

Which reminds me...these kinds of name changes deserve a thread/list in the Go2 proposals On Sat, Dec 1, 2018 at 12:17 AM Anthony Martin wrote: > Nigel Tao once said: > > Well, there's already context.Context, hash.Hash, image.Image and > > time.Time in the standard library. > > All of which ar

Re: [go-nuts] [ANN] fixed point math library

Nigel Tao once said: > Well, there's already context.Context, hash.Hash, image.Image and > time.Time in the standard library. All of which are not great. Better names are context.Frame, hash.Function, raster.Image, and time.Instant. Anthony -- You received this message because you are subscr

Re: [go-nuts] [ANN] fixed point math library

This is quite clever but you really don’t want to have to define types for all of the currencies in use where most people deal with one or few at most. Worse, new currencies may come into existence at any time. And consider securities such as stocks, bonds etc. which have some similar operations bu

Re: [go-nuts] [ANN] fixed point math library

Quoting Bakul Shah (2018-11-29 22:13:45) > I doubt go2 will get generics flexible enough for this! It can actually already pull much of this off, and you don't even need the contracts part of the draft. E.g: // Type 'Money' represents a monetary value. The Currency type parameter // is unused at

Re: [go-nuts] [ANN] fixed point math library

Yes, a real currency type would contain a Fixed. Most likely adding a symbol, code, etc. > On Nov 29, 2018, at 9:13 PM, Bakul Shah wrote: > > FWIW, in some code I am writing, I considered using > fixed point decimal numbers but ended up defining a > *currency* type which is an int64 for value

Re: [go-nuts] [ANN] fixed point math library

FWIW, in some code I am writing, I considered using fixed point decimal numbers but ended up defining a *currency* type which is an int64 for value + a separate unit + currency kind. Even if I use a unit of millicent, this will allow handling amounts close to $100 Trillion. I don't expect this lim

Re: [go-nuts] [ANN] fixed point math library

On Fri, Nov 30, 2018 at 12:26 AM Nigel Tao wrote: On Thu, Nov 29, 2018 at 9:20 PM Jan Mercl <0xj...@gmail.com> wrote: > Well, there's already context.Context, hash.Hash, image.Image and > time.Time in the standard library. Perhaps, in a parallel universe, we > could have settled on the testing.T

Re: [go-nuts] [ANN] fixed point math library

On Thu, 2018-11-29 at 17:07 -0600, robert engels wrote: > The dot imports are useful, and others feel the same https://github.c > om/golang/lint/issues/179 > . When you make statements > like,  > > > > > Now given that dot imports are generally considere

Re: [go-nuts] [ANN] fixed point math library

On Thu, Nov 29, 2018 at 9:20 PM Jan Mercl <0xj...@gmail.com> wrote: > - To me type name 'fixed.Fixed' sounds like Javaism. Well, there's already context.Context, hash.Hash, image.Image and time.Time in the standard library. Perhaps, in a parallel universe, we could have settled on the testing.T na

Re: [go-nuts] [ANN] fixed point math library

On Fri, Nov 30, 2018 at 12:07 AM robert engels wrote: > The dot imports are useful, and others feel the same https://github.com/golang/lint/issues/179. Not all others do feel the same. Actually, most others do not. From Go Code Review Comments

Re: [go-nuts] [ANN] fixed point math library

The dot imports are useful, and others feel the same https://github.com/golang/lint/issues/179 . When you make statements like, > Now given that dot imports are generally considered a bad idea in Go It feels a lot like the “cut off the sides of the ro

Re: [go-nuts] [ANN] fixed point math library

fixed.Number reduces stutter and is more informative. This was Jan's point. In general dot imports are a bad idea when maintaining large code bases since it requires more work to figure out what is actually providing the X that has been added to the . imports pool. It also a prevents the protectio

Re: [go-nuts] [ANN] fixed point math library

Right and since fixed.Fixed can be reduced to Fixed with no loss of information, it is a great lossless compression - more than 50 %. Thanks for playing ! > On Nov 29, 2018, at 4:11 PM, Daniel Kortschak wrote: > > That is correct. The number of physical bits used to represent the > informatio

Re: [go-nuts] [ANN] fixed point math library

I believe Jan is talking about bits in the information-theoretic sense. I.e, asking "how much do I know?", not "how much space does this take up?" Quoting robert engels (2018-11-29 17:10:51) >Would you elaborate? I've read the discussion multiple times, and can't >see what other bits you t

Re: [go-nuts] [ANN] fixed point math library

That is correct. The number of physical bits used to represent the information is reduced. The number of bits of information remains the same except in the case of lossy compression. If this were not true, I could propose the following compression protocol: count the number of 1 bits in the uncomp

Re: [go-nuts] [ANN] fixed point math library

Would you elaborate? I’ve read the discussion multiple times, and can’t see what other bits you think he is referring to. > On Nov 29, 2018, at 3:07 PM, Jan Mercl <0xj...@gmail.com> wrote: > > > On Thu, Nov 29, 2018 at 10:02 PM robert engels > wrote: > > > I’m pr

Re: [go-nuts] [ANN] fixed point math library

On Thu, Nov 29, 2018 at 10:02 PM robert engels wrote: > I’m pretty sure that is not correct, see https://www.maximumcompression.com > > Most lossless text compression is > 85 %, and if you use lossy compression (images, audio) it can be 100:1 Dan was talking about quite different bits. -- -j

Re: [go-nuts] [ANN] fixed point math library

I’m pretty sure that is not correct, see https://www.maximumcompression.com Most lossless text compression is > 85 %, and if you use lossy compression (images, audio) it can be 100:1 > On Nov 29, 2018, at 2:39 PM, Daniel Kortschak wrote: > > In the majori

Re: [go-nuts] [ANN] fixed point math library

In the majority of cases compression does not reduce the number of bits of information (appreciably). On Thu, 2018-11-29 at 08:35 -0600, Robert Engels wrote: > And since you like lingo, more bits of information is not always a > good thing. That’s why we have compression, and lossless compression

Re: [go-nuts] [ANN] fixed point math library

That being said, I am not sure why I can use the qualified package name when I have a dot import. This would be helpful for method collision like New() > On Nov 29, 2018, at 8:35 AM, Robert Engels wrote: > > I am not referring to variable declarations I am referring to > > X := SomeFunc() > >

Re: [go-nuts] [ANN] fixed point math library

I am not referring to variable declarations I am referring to X := SomeFunc() Far worse for understanding than having common or ubiquitous structs as dot imports. That way they become “part of the language” Static imports were added to Java long ago and if Java guys can figure it out I think y

Re: [go-nuts] [ANN] fixed point math library

On Thu, Nov 29, 2018 at 3:07 PM Robert Engels wrote: > Wait, you support type inference and not dot imports... I think you should revisit this opinion... I believe it's the other way around. Seeing T alone has n bits of information. Seeing foo.T carries more bits of information. So Seeing x :=

Re: [go-nuts] [ANN] fixed point math library

Wait, you support type inference and not dot imports... I think you should revisit this opinion... also, dot imports are very versatile when changing the implementation without changing a lot of LOC. I think the string method is certainly more useful when dealing with external systems or files

Re: [go-nuts] [ANN] fixed point math library

Yes it does (for some reason I was thinking that Cmp returning 0 was false but it's not it's equals :) ), I'm not sure Cmp can be implemented in that case, at least without panicing NaN == NaN should be false, the other packages like decimal & big don't seem to have an issue as NaN can't exist?

Re: [go-nuts] [ANN] fixed point math library

On Thu, Nov 29, 2018 at 2:41 PM Robert Engels 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. The OP says: "For those interesting in financial

Re: [go-nuts] [ANN] fixed point math library

Yeah I posted that before rereading your initial reply to Jan, I can accept the argument of not exposing the underlying type directly (to avoid using standard int operators on Fixed values), however the raw accessors circumvent that since you could always use them to modify a value through a po

Re: [go-nuts] [ANN] fixed point math library

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 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

Re: [go-nuts] [ANN] fixed point math library

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 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 i

Re: [go-nuts] [ANN] fixed point math library

You don’t want fp public for value safety. The Raw methods are going away in favor of direct read and write. > On Nov 29, 2018, at 7:32 AM, Jamie Clarkson wrote: > > Also I fail to see the point of the ToRaw/fromRaw when you could just make FP > public. > >> On Thursday, November 29, 2018 at

Re: [go-nuts] [ANN] fixed point math library

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

Re: [go-nuts] [ANN] fixed point math library

Scratch that, just seen your original reply to Jan about them being temporary. On Thursday, November 29, 2018 at 1:32:10 PM UTC, Jamie Clarkson wrote: > > Also I fail to see the point of the ToRaw/fromRaw when you could just make > FP public. > > On Thursday, November 29, 2018 at 1:28:40 PM UTC,

Re: [go-nuts] [ANN] fixed point math library

Also I fail to see the point of the ToRaw/fromRaw when you could just make FP public. On Thursday, November 29, 2018 at 1:28:40 PM UTC, Jamie Clarkson wrote: > > I think the logic should be that if either operand is NaN the comparison > should be false to match floats (currently it looks like f

Re: [go-nuts] [ANN] fixed point math library

I think the logic should be that if either operand is NaN the comparison should be false to match floats (currently it looks like f < NaN and NaN < f give incorrect results), you might have some reason for that though. A few other random thoughts: - Not all methods/funcs are documented (whic

Re: [go-nuts] [ANN] fixed point math library

On Thu, Nov 29, 2018 at 2:15 PM Robert Engels wrote: > Also, the most important reason against the setters - a Fixed is immutable. Great, then just let the setter return a value. x := fixed.New(0).SetString(foo) Similarly like big.Float.SetString

Re: [go-nuts] [ANN] fixed point math library

On Thu, Nov 29, 2018 at 2:00 PM Robert Engels 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

Re: [go-nuts] [ANN] fixed point math library

Also, the most important reason against the setters - a Fixed is immutable. > On Nov 29, 2018, at 7:00 AM, Robert Engels wrote: > > Thanks for the feedback. My comments below. > >> - To me type name 'fixed.Fixed' sounds like Javaism. Go code usually tries >> to avoid such stutter: 'sort.Inte

Re: [go-nuts] [ANN] fixed point math library

NaN cannot be returned in an int so not possible. > On Nov 29, 2018, at 4:41 AM, messju mohr wrote: > > Hello, > > this looks like a really nice and useful library! :) > > Just one thing: At first glance i saw that fixed.Cmp() returns 0 when both > operands are NaN. > I think it would be mor

Re: [go-nuts] [ANN] fixed point math library

Thanks for the feedback. My comments below. > - 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

Re: [go-nuts] [ANN] fixed point math library

Hello, this looks like a really nice and useful library! :) Just one thing: At first glance i saw that fixed.Cmp() returns 0 when both operands are NaN. I think it would be more consistent if fixed.Cmp() would return NaN if any of it's operands are NaN. just my 2ct messju On Thu, Nov 29, 201

Re: [go-nuts] [ANN] fixed point math library

On Thu, Nov 29, 2018 at 7:47 AM robert engels wrote: > For those interesting in financial apps, I have released ‘fixed' at https://github.com/robaho/fixed a high performance fixed-point math library primarily designed for to work with currencies. - To me type name 'fixed.Fixed' sounds like Javai

[go-nuts] [ANN] fixed point math library

For those interesting in financial apps, I have released ‘fixed' at https://github.com/robaho/fixed a high performance fixed-point math library primarily designed for to work with currencies. The benchmarks: (Decimal is the shopspring library, big Int/Float are