[go-nuts] Re: Incorrect arithmetic answers

[cratermoon]

Floating point calculations are imprecise.

https://0.30004.com/
https://www.phys.uconn.edu/~rozman/Courses/P2200_15F/downloads/floating-point-guide-2015-10-15.pdf

s

On Monday, June 1, 2020 at 11:56:55 AM UTC-7, Saksham Saxena wrote:
>
> Hello,
>
> I was trying to implement Substring Search using a rolling hash function 
> (fairly simple implementation): https://play.golang.org/p/_fjgxPC06So
>
> This works correctly and as expected. However, if you change the const 
> `baseNumber` to 128, the program is unable to do the intermediate 
> arithmetic incorrectly (see the difference after running it). 
>
> How could this be ? I've stared at it long enough and it doesn't seem like 
> it's overflowing (or is it really ? I thought float64 had great range ?)
>
> Any ideas/comments are appreciated. 
>
> Thanks!
> Saksham
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/d071b2be-9fc1-45e4-9da8-baecb9968ea7%40googlegroups.com.

[go-nuts] Re: OAuth2 token expiry logic

[cratermoon]

Whoops, you're right. I got my Time and Duration mixed up. Your question 
still stands, though. The section on Monotonic Clocks at 
https://pkg.go.dev/time?tab=doc is a bit dense, but my best guess is that 
stripping the monotonic clock reading from the Expiry ensures that the 
comparison is made against the actual wall clock time (in the past) vs some 
unknown adjusted time, which might be earlier or later than the intended 
time and thus give incorrect results.

s


On Monday, April 20, 2020 at 7:16:30 AM UTC-7, ISE Development wrote:
>
> On Monday, 20 April 2020 15:04:54 UTC+1, crate...@gmail.com wrote:
>>
>> According to https://golang.org/pkg/time/#Duration.Round "If m <= 0, 
>> Round returns d unchanged". So now I'm really curious, why do the Round() 
>> at all?
>>
>
> But in this case, it's a time.Time value, so this applies (
> https://pkg.go.dev/time?tab=doc#Time.Round):
>
> Round returns the result of rounding t to the nearest multiple of d (since 
>> the zero time). The rounding behavior for halfway values is to round up. If 
>> d <= 0, Round returns t stripped of any monotonic clock reading but 
>> otherwise unchanged. 
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/f871298a-f06d-4e9f-ad20-ee145cdd8004%40googlegroups.com.

[go-nuts] Re: OAuth2 token expiry logic

[cratermoon]

According to https://golang.org/pkg/time/#Duration.Round "If m <= 0, Round 
returns d unchanged". So now I'm really curious, why do the Round() at all?

s

On Sunday, April 19, 2020 at 6:45:45 PM UTC-7, ise...@gmail.com wrote:
>
> Hi,
>
> I have been looking at various packages to understand how one goes about 
> implementing things in Go. I have been learning a great deal just by 
> getting my head around code written by smarter devs than I'm ever likely to 
> be ;)
>
> Whilst looking at golang/oauth2, two lines of code handling token expiry 
> led me to discover about time.Time's use of both wall and monotonic clocks. 
> I realised that either I had failed to understand something or the code was 
> wrong. I'm assuming it's the former, so hopefully somebody can explain it 
> to me...
>
> In oauth2/internal/token.go, doTokenRoudnTrip sets the Token.Expiry as 
> follows:
>
> token.Expiry = time.Now().Add(time.Duration(expires) * time.Second)
>  
> In oauth2/token.go, the Token.expired function returns this:
>
> return t.Expiry.Round(0).Add(-expiryDelta).Before(timeNow())
>
> If I have read the time package documentation correctly, the monotonic 
> clock reading is intended for time measurements. In particular, it provides 
> robust behaviour for functions such as Before().
>
> So I do not understand why the monotonic reading is stripped from the time 
> value with Round(0) before invoking Before() in the code above. As I read 
> it, the token.Expiry has a monotonic clock reading (now + duration) which 
> is then stripped when evaluated against Before(now) later on... does this 
> not make the code susceptible to issues when system time is being adjusted? 
> What is the rationale for Round(0) in this case?
>
> -- ise
>
>
>
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/a4167638-c04a-4e64-9374-67fe240135c4%40googlegroups.com.

Re: [go-nuts] Re: keep just 2 decimal places in a float64

[cratermoon]

Perhaps I'm doing something wrong or using the library outside of its 
intended purpose, but I found that this library doesn't handle Muller's 
Recurrence correctly. For those not familiar, Muller's Recurrence is 108 - 
(815-1500/z)/y

https://play.golang.org/p/sePTgjZzHeY

See 
https://latkin.org/blog/2014/11/22/mullers-recurrence-roundoff-gone-wrong/

On Sunday, January 26, 2020 at 8:46:16 AM UTC-8, Robert Engels wrote:
>
> Which is exactly what github.com/robaho/fixed and many others do!
>
> On Jan 26, 2020, at 10:34 AM, Michael Jones  > wrote:
>
> 
> ...thus the virtue of scaled integers. scaling by 100 makes cents whole, 
> scaling by 1*100 gives four decimal places beyond that. There is 
> nothing bad about floating point despite the reputation, it's just not the 
> number system from algebra; nor is binary floating point the same as 
> decimal floating point. The problems all start with false presumptions.
>
> On Sun, Jan 26, 2020 at 8:20 AM Robert Engels  > wrote:
>
>> Just an FYI, often that is not correct. Many financial systems require 
>> fractional pennies due to the volume of transactions. Think about taxing 
>> stock exchanges the pennies add up quickly at any tax rate, so they use 
>> fractional pennies to reduce the size of the error bucket. 
>>
>> On Jan 26, 2020, at 8:50 AM, Pat Farrell > 
>> wrote:
>>
>> 
>> never use floating point if you are trying to represent money, say 
>> dollars and cents or decimal values of the euro.
>> Store the money as integer number of pennies.
>>
>> -- 
>> 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 golan...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/cc852ce3-6f88-40fd-8b19-877c76deec10%40googlegroups.com
>>  
>> 
>> .
>>
>> -- 
>> 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 golan...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/AF9827F5-C849-4F4E-8229-005D6C9A0E03%40ix.netcom.com
>>  
>> 
>> .
>>
>
>
> -- 
>
> *Michael T. jonesmichae...@gmail.com *
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/46cadc14-9c8e-4c3a-9c6b-d0af7b621061%40googlegroups.com.

[go-nuts] Re: keep just 2 decimal places in a float64

[cratermoon]

Floating point math has many 
pitfalls.  https://play.golang.org/p/LK0lla8hM9w See also 
https://0.30004.com/

s

On Saturday, January 25, 2020 at 7:14:15 PM UTC-8, Jason E. Aten wrote:
>
>
> https://play.golang.org/p/87bDubJxjHO
>
> I'd like to truncate a float64 to just 2 decimal places (in base 10), but 
> math.Trunc is not helping me here... ideally I put 0.29 in and I get 0.29 
> out.
> Suggestions?  Playground examples appreciated.
>
> package main
>
> import (
> "fmt"
> "math"
> )
>
> // truncate off everything after the last two decimals, no rounding.
> func decimal2(x float64) float64 {
> return math.Trunc(x*100) / 100
> }
>
> func main() {
> x := 0.29
> y := decimal2(x)
> fmt.Printf("x=%v -> y = %v", x, y) // prints x=0.29  ->  y=0.28
> }
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/d3250e2a-e72d-40e5-987c-b9f5012dd3cc%40googlegroups.com.

[go-nuts] Re: Inconsistent rounding with float printf ?

[cratermoon]

https://play.golang.org/p/j5HKxitS-Z6

See  https://0.30004.com/

On Friday, December 6, 2019 at 1:25:01 AM UTC-8, Christophe Meessen wrote:
>
> I have noticed that printf performs an apparently inconsistent rounding of 
> floating point values.
>
> I divide a big number by 1000 and printf the resulting value with "%.1f".
> Here is the code: https://play.golang.org/p/e7dD3c6IHq2
>
> I would expect the rounding rule to be "round away from zero" as defined 
> here: https://math.stackexchange.com/a/2252888/33796
> In this case 0.5 is rounded to 1 (or 0.05 to 0.1) and -0.5 to -1 (or -0.05 
> to -0.1). 
>
> Here is what I see with golang 1.13.4:
>
> 999000/1000 = 999.0
> 999050/1000 = 999.0 // expected 999.1
> 999100/1000 = 999.1
> 999150/1000 = 999.1 // expected 999.2
> 999200/1000 = 999.2
> 999250/1000 = 999.2 // expected 999.3
> 999300/1000 = 999.3
> 999350/1000 = 999.4 
> 999400/1000 = 999.4
> 999450/1000 = 999.5 
> 999500/1000 = 999.5
> 999550/1000 = 999.5 // expected 999.6
> 999600/1000 = 999.6
> 999650/1000 = 999.6 // expected 999.7
> 999700/1000 = 999.7
> 999750/1000 = 999.8 
> 999800/1000 = 999.8
> 999850/1000 = 999.9 
> 00/1000 = 999.9
> 50/1000 = 1000.0 
> -50/1000 = -1000.0 
> -00/1000 = -999.9
> -999850/1000 = -999.9  
> -999800/1000 = -999.8
> -999750/1000 = -999.8
> -999700/1000 = -999.7
> -999650/1000 = -999.6 // expected -999.7
> -999600/1000 = -999.6
> -999550/1000 = -999.5 // expected -999.6
> -999500/1000 = -999.5
> -999450/1000 = -999.5
> -999400/1000 = -999.4
> -999350/1000 = -999.4
> -999300/1000 = -999.3
> -999250/1000 = -999.2 // expected -999.3
> -999200/1000 = -999.2
> -999150/1000 = -999.1 // expected -999.2
> -999100/1000 = -999.1
> -999050/1000 = -999.0 // expected -999.1
>
>
> Is this actual rounding the result of a rule or is it pseudo random ? 
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/138f55d2-e7a6-4f12-85fd-d14bc42699f7%40googlegroups.com.