date:20180429

Re: [go-nuts] float accuracy when calculating Fibonacci numbers

2018-04-29 Thread Yuval Lifshitz

It seems like go and C++ are doing something different regarding floating 
point arithmetic, but I cannot say one is better than the other. It is just 
the that C++ consistently overshoots (hence truncation work), and go 
consistently undershoots (this is why rounding is needed). For example, in 
C++:

F(59) = 956722026041.002

And in go, it is:

F(59) = 956722026040.999878


And for example:

On Monday, 30 April 2018 02:13:49 UTC+3, Michael Jones wrote:
>
> Not sure what you mean with "by design." The design here is the IEEE 
> Standard for Floating-Point Arithmetic (IEEE 754). It is authoritative for 
> Intel, AMD, IBM, Sun, etc.
>
> Typical (universal?) C and C++ implementations map 'float' to 32-bit IEEE 
> 754 binary floating point and 'double' to the related 64-bit version. Go 
> uses this same hardware in the same (universal?) way, through the types 
> "float32" and "float64."
>
> Truncation of floating point types to integer, or the floor() function, 
> discards any fractional part. Such that:
> int(e) => 2
> int(pi) => 3
>
> Rounding up to the nearest integer with int(v+0.5) and floor(v+0.5) is a 
> different operation:
> round(e) => 3
> round(pi) => 3
>
> Your C program truncates and your Go program rounds. They are not the same 
> program. They compute different things, which is why the results are 
> different.
>
> In a de Moivre coding of Fibonacci evaluation using rounding as above, 
> Knuth showed that the pow((1-sqrt(5))/2,n) term--the second summand--may be 
> dropped.
>
> For 64-bit floating point the F(75) value is the most that you can 
> generate this way.
>
> Using other methods you can (and more quickly) generate values up to 
> F(92), which is the greatest Fibonacci value (7540113804746346429) 
> representable as a 64-bit unsigned integer.
>
> For completeness, there is also the Ceiling function:
> ceil(e) => 3
> ceil(pi) => 4
>
> hope this helps.
>
>
> On Sun, Apr 29, 2018 at 12:36 PM Yuval Lifshitz  > wrote:
>
>> in C/C++ (at least on my system) "float" 4 has 4 bytes (32bits) and 
>> double has 8 bytes (64bits). according to this: 
>> https://golang.org/pkg/math/ its is the same thing with go.
>>
>> On Sunday, 29 April 2018 22:27:23 UTC+3, Louki Sumirniy wrote:
>>>
>>> I could be wrong but float64 is 'float' and 'double float' is float128. 
>>> I dunno, I have not tinkered with these imprecise math types. That's just, 
>>> essentially, what they were back in the olden days, like 20 years ago. 64 
>>> bit was basic float, 128 was double. I have been out of the loop for way 
>>> too long on these things (and I am not a fan of floats anyway, give me some 
>>> fixed precision pls).
>>>
>>> On Sunday, 29 April 2018 10:08:15 UTC+3, Yuval Lifshitz wrote:

 (1) I understand the issue of limited precision, this is why I did not 
 try anything above F(59) But my concern was not the difference between 
 algebra and the go implementation it was the different results I got with 
 the C/C++ implementation (gcc 7.3.1):

 #include 

 const double sqrt_5 = sqrt(5.0);
 const double phi = (1.0 + sqrt_5)/2.0;
 const double psi = -1.0/phi;

 // find the nth fibonacci number based on Binet's formula
 // see here: 
 https://en.wikipedia.org/wiki/Fibonacci_number#Closed-form_expression
 unsigned long long fibonacci(unsigned n)
 {
 return (unsigned long long)((pow(phi, n) - pow(psi, n))/sqrt_5);
 }


 (2) Thanks for the fix, work well for the go implementation. However, 
 if i try to apply it on the C++ one (where there is no rounding), it makes 
 some of the tests fails. So, I guess that without rounding, the psi part 
 is 
 needed

 (3) Is there a way to print the map ordered (didn't see that in your 
 snippet)?

 (4) Wanted to compare "double" in C++ to "float64" in go. As they 
 should consume same amount of memory, have similar algorithms etc. but 
 good 
 to know about the "big" package in go

 (5) Thanks for the reference. interesting read

 On Saturday, 28 April 2018 00:57:42 UTC+3, Michael Jones wrote:
>
> Yuval,
>
> There are fundamental issues here.
>
> 1. That equation (de Moivre, Binet) is from the algebra of ideal 
> numbers. Numbers of infinite precision. Not the realm of computer 
> arithmetic. It works fine with double precision (go: float64, c/c++: 
> double) up to F(75) but must fail for F(76) due to the limited precision 
> of 
> 64-bit floating point and has nothing to do with language.
>
> F(76) = 3416454622906707 but the best we can do in 64 bits is 
> 3416454622906706 even with a Pow() function good to +/-1 least 
> significant 
> bit.
>
> 2. Another difference between algebra and computer arithmetic 
> (well...actually about the floor function) is that one of your two power 
> terms is not needed. Psi < 1 so Psi^N is pretty small, so small, that it

[go-nuts] Re: Failure to build syzkaller in a build chroot

2018-04-29 Thread 'Dmitry Vyukov' via golang-nuts

Hi Ted,

I don't know what's the problem with Go toolchain, maybe Ian's
hypothesis is true. But we use cross-compilation for arm64 and arm
from Debian Rodete distors and it's working. I cross-compiled executor
for arm with arm-linux-gnueabihf-gcc just few days ago. People also
recommend Linaro-provided toolchains for arm/arm64:

https://www.linaro.org/downloads/
https://releases.linaro.org/components/toolchain/binaries/latest/aarch64-linux-gnu/





On Mon, Apr 30, 2018 at 4:12 AM, Theodore Y. Ts'o  wrote:
> Hi, I'm having trouble building syzkaller (which is primarily written
> in Go) in a Debian schroot for amd64 using qemu emulation.  That is,
> I'm using a chroot filled with arm64 binaries, running them on an
> x86_64 system using a setup such as described in [1].  The specific
> chroot I am using can be set up using the setup-buildchroot[2] which
> is part of the xfstests-bld repository.
>
> [1] https://wiki.debian.org/QemuUserEmulation
> [2] https://github.com/tytso/xfstests-bld/blob/master/setup-buildchroot
>
> The goal of this exercise is to create an android-xfstests[3] test
> appliance using a x86_64 based build machine (because good luck
> finding a performant armhf or arm64 build system) which includes
> syzkaller.
>
> [3] https://thunk.org/android-xfstests
>
> When I run make in a Debian stretch-arm64 chroot, while trying to
> build syzkaller, I get the following failure messages.  (See
> attached).  Running make and gcc and binutils using arm64 to run the
> arm64 binaries work just fine; I assume this is some kind of
> go-specific runtime issue?
>
> Any help or suggestions would be greatly appreciated.
>
> Thanks!!
>
> - Ted
>
>  
> {/usr/projects/xfstests-bld/build-arm64/go/src/github.com/google/syzkaller}
> 1008% make
> GOOS=linux GOARCH=arm64 go install ./syz-manager
> # github.com/google/syzkaller/sys/targets
> runtime: failed to create new OS thread (have 2 already; errno=22)
> fatal error: newosproc
>
> runtime stack:
> runtime.throw(0x5fdfda, 0x9)
> /usr/lib/go-1.8/src/runtime/panic.go:596 +0x70
> runtime.newosproc(0x14420010400, 0x1442004)
> /usr/lib/go-1.8/src/runtime/os_linux.go:163 +0x168
> runtime.newm(0x618cb0, 0x0)
> /usr/lib/go-1.8/src/runtime/proc.go:1628 +0x110
> runtime.main.func1()
> /usr/lib/go-1.8/src/runtime/proc.go:126 +0x28
> runtime.systemstack(0x909800)
> /usr/lib/go-1.8/src/runtime/asm_arm64.s:241 +0x90
> runtime.mstart()
> /usr/lib/go-1.8/src/runtime/proc.go:1132
>
> goroutine 1 [running]:
> runtime.systemstack_switch()
> /usr/lib/go-1.8/src/runtime/asm_arm64.s:190 +0x8 fp=0x1442002e780 
> sp=0x1442002e770
> runtime.main()
> /usr/lib/go-1.8/src/runtime/proc.go:127 +0x58 fp=0x1442002e7d0 
> sp=0x1442002e780
> runtime.goexit()
> /usr/lib/go-1.8/src/runtime/asm_arm64.s:981 +0x4 fp=0x1442002e7d0 
> sp=0x1442002e7d0
> # github.com/google/syzkaller/pkg/ifuzz
> runtime: failed to create new OS thread (have 2 already; errno=22)
> fatal error: newosproc
>
> runtime stack:
> runtime.throw(0x5fdfda, 0x9)
> /usr/lib/go-1.8/src/runtime/panic.go:596 +0x70
> runtime.newosproc(0x14420010400, 0x1442004)
> /usr/lib/go-1.8/src/runtime/os_linux.go:163 +0x168
> runtime.newm(0x618cb0, 0x0)
> /usr/lib/go-1.8/src/runtime/proc.go:1628 +0x110
> runtime.main.func1()
> /usr/lib/go-1.8/src/runtime/proc.go:126 +0x28
> runtime.systemstack(0x909800)
> /usr/lib/go-1.8/src/runtime/asm_arm64.s:241 +0x90
> runtime.mstart()
> /usr/lib/go-1.8/src/runtime/proc.go:1132
>
> goroutine 1 [running]:
> runtime.systemstack_switch()
> /usr/lib/go-1.8/src/runtime/asm_arm64.s:190 +0x8 fp=0x1442002e780 
> sp=0x1442002e770
> runtime.main()
> /usr/lib/go-1.8/src/runtime/proc.go:127 +0x58 fp=0x1442002e7d0 
> sp=0x1442002e780
> runtime.goexit()
> /usr/lib/go-1.8/src/runtime/asm_arm64.s:981 +0x4 fp=0x1442002e7d0 
> sp=0x1442002e7d0
> # github.com/google/syzkaller/vendor/golang.org/x/net/context
> runtime: failed to create new OS thread (have 2 already; errno=22)
> fatal error: newosproc
>
> runtime stack:
> runtime.throw(0x5fdfda, 0x9)
> /usr/lib/go-1.8/src/runtime/panic.go:596 +0x70
> runtime.newosproc(0x14420010400, 0x14420042000)
> /usr/lib/go-1.8/src/runtime/os_linux.go:163 +0x168
> runtime.newm(0x618cb0, 0x0)
> /usr/lib/go-1.8/src/runtime/proc.go:1628 +0x110
> runtime.main.func1()
> /usr/lib/go-1.8/src/runtime/proc.go:126 +0x28
> runtime.systemstack(0x909800)
> /usr/lib/go-1.8/src/runtime/asm_arm64.s:241 +0x90
> runtime.mstart()
> /usr/lib/go-1.8/src/runtime/proc.go:1132
>
> goroutine 1 [running]:
> runtime.systemstack_switch()
> /usr/lib/go-1.8/src/runtime/asm_arm64.s:190 +0x8 fp=0x14420030780 
> sp=0x14420030770
> runtime.main()
> /usr/lib/go-1.8/src/runtime/proc.go:127 +0x58 fp=0x144200307d0 
> sp=0x14420030780
> runtime.goexit()
> /usr

[go-nuts] Goroutines memory leak

2018-04-29 Thread Tamás Gulácsi

Where do you Close the dialer? Why aren't you reusing the httpClient?

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

Re: [go-nuts] Failure to build syzkaller in a build chroot

2018-04-29 Thread Ian Lance Taylor

On Sun, Apr 29, 2018 at 7:12 PM, Theodore Y. Ts'o  wrote:
>
> Hi, I'm having trouble building syzkaller (which is primarily written
> in Go) in a Debian schroot for amd64 using qemu emulation.  That is,
> I'm using a chroot filled with arm64 binaries, running them on an
> x86_64 system using a setup such as described in [1].  The specific
> chroot I am using can be set up using the setup-buildchroot[2] which
> is part of the xfstests-bld repository.
>
> [1] https://wiki.debian.org/QemuUserEmulation
> [2] https://github.com/tytso/xfstests-bld/blob/master/setup-buildchroot
>
> The goal of this exercise is to create an android-xfstests[3] test
> appliance using a x86_64 based build machine (because good luck
> finding a performant armhf or arm64 build system) which includes
> syzkaller.
>
> [3] https://thunk.org/android-xfstests
>
> When I run make in a Debian stretch-arm64 chroot, while trying to
> build syzkaller, I get the following failure messages.  (See
> attached).  Running make and gcc and binutils using arm64 to run the
> arm64 binaries work just fine; I assume this is some kind of
> go-specific runtime issue?
>
> Any help or suggestions would be greatly appreciated.

I have no idea why this is failing.

Have you tried using the current Go release, 1.10.1?

The error means that the `clone` system call returned EINVAL.

I'm a little confused by your description of the environment.  The
stack trace below shows that you are running a version of Go that was
built to run on an arm64 host.  You mention amd64 a few times above,
though.  I gather that you are running this version of Go on amd64
hardware using QEMU to run arm64 binaries?  If that is the case then
my first guess would be that QEMU does not fully implement the clone
system call.  The code (runtime·clone in
src/runtime/sys_linux_arm64.s) passes flags in x0 (CLONE_VM | CLONE_FS
| CLONE_FILES | CLONE_SIGHAND | CLONE_THREAD) and the child stack
address in x1.  Registers x2, x3, and x4 are not set to anything in
particular, as the flags are such that they are not needed.  With
those arguments the clone system call, presumably as executed by QEMU,
is returning EINVAL.

That's all I can see.  Hope that helps.

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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

AW: [go-nuts] Question about int inside json

2018-04-29 Thread Lutz Horn

Use `int64` instad of `int`.

https://play.golang.com/p/j10cDz7z-N0


Von: golang-nuts@googlegroups.com  im Auftrag von 
pick...@kamelos.org 
Gesendet: Samstag, 28. April 2018 20:04
An: golang-nuts
Betreff: [go-nuts] Question about int inside json


Hallo all,

I've a "stupid" question about the type "int" when used inside json.
Almost every documentation I've found says int is 32 bit long, so that I expect 
a range from -2.147.483.648 to 2.147.483.647.



So I "mistakely" did that:

type Comment struct {
 IDint   `json:"id"`
 URL   string`json:"url"`
 Comment   string`json:"comment"`
 Html  string`json:"html"`
 Name  string`json:"name"`
 Timestamp time.Time `json:"timestamp"`
 Parentint   `json:"parent"`
}



then some code, where c is *Comment, and..


t := time.Now()
c.ID = int(t.UnixNano() / 100)


but, when I wrote c.ID into a JSON file, it resulted in:

1524937580003

which is correct, but cannot fit in 32 bits.

The version I'm using is
go version go1.9.4 linux/amd64


is it a bug of this specific version, or is something I didn't got about int 
inside struct json structs, like c.ID?

many thanks

Milo










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

[go-nuts] Failure to build syzkaller in a build chroot

2018-04-29 Thread Theodore Y. Ts'o

Hi, I'm having trouble building syzkaller (which is primarily written
in Go) in a Debian schroot for amd64 using qemu emulation.  That is,
I'm using a chroot filled with arm64 binaries, running them on an
x86_64 system using a setup such as described in [1].  The specific
chroot I am using can be set up using the setup-buildchroot[2] which
is part of the xfstests-bld repository.

[1] https://wiki.debian.org/QemuUserEmulation
[2] https://github.com/tytso/xfstests-bld/blob/master/setup-buildchroot

The goal of this exercise is to create an android-xfstests[3] test
appliance using a x86_64 based build machine (because good luck
finding a performant armhf or arm64 build system) which includes
syzkaller.

[3] https://thunk.org/android-xfstests

When I run make in a Debian stretch-arm64 chroot, while trying to
build syzkaller, I get the following failure messages.  (See
attached).  Running make and gcc and binutils using arm64 to run the
arm64 binaries work just fine; I assume this is some kind of
go-specific runtime issue?

Any help or suggestions would be greatly appreciated.

Thanks!!

- Ted

 
{/usr/projects/xfstests-bld/build-arm64/go/src/github.com/google/syzkaller}
1008% make
GOOS=linux GOARCH=arm64 go install ./syz-manager
# github.com/google/syzkaller/sys/targets
runtime: failed to create new OS thread (have 2 already; errno=22)
fatal error: newosproc

runtime stack:
runtime.throw(0x5fdfda, 0x9)
/usr/lib/go-1.8/src/runtime/panic.go:596 +0x70
runtime.newosproc(0x14420010400, 0x1442004)
/usr/lib/go-1.8/src/runtime/os_linux.go:163 +0x168
runtime.newm(0x618cb0, 0x0)
/usr/lib/go-1.8/src/runtime/proc.go:1628 +0x110
runtime.main.func1()
/usr/lib/go-1.8/src/runtime/proc.go:126 +0x28
runtime.systemstack(0x909800)
/usr/lib/go-1.8/src/runtime/asm_arm64.s:241 +0x90
runtime.mstart()
/usr/lib/go-1.8/src/runtime/proc.go:1132

goroutine 1 [running]:
runtime.systemstack_switch()
/usr/lib/go-1.8/src/runtime/asm_arm64.s:190 +0x8 fp=0x1442002e780 
sp=0x1442002e770
runtime.main()
/usr/lib/go-1.8/src/runtime/proc.go:127 +0x58 fp=0x1442002e7d0 
sp=0x1442002e780
runtime.goexit()
/usr/lib/go-1.8/src/runtime/asm_arm64.s:981 +0x4 fp=0x1442002e7d0 
sp=0x1442002e7d0
# github.com/google/syzkaller/pkg/ifuzz
runtime: failed to create new OS thread (have 2 already; errno=22)
fatal error: newosproc

runtime stack:
runtime.throw(0x5fdfda, 0x9)
/usr/lib/go-1.8/src/runtime/panic.go:596 +0x70
runtime.newosproc(0x14420010400, 0x1442004)
/usr/lib/go-1.8/src/runtime/os_linux.go:163 +0x168
runtime.newm(0x618cb0, 0x0)
/usr/lib/go-1.8/src/runtime/proc.go:1628 +0x110
runtime.main.func1()
/usr/lib/go-1.8/src/runtime/proc.go:126 +0x28
runtime.systemstack(0x909800)
/usr/lib/go-1.8/src/runtime/asm_arm64.s:241 +0x90
runtime.mstart()
/usr/lib/go-1.8/src/runtime/proc.go:1132

goroutine 1 [running]:
runtime.systemstack_switch()
/usr/lib/go-1.8/src/runtime/asm_arm64.s:190 +0x8 fp=0x1442002e780 
sp=0x1442002e770
runtime.main()
/usr/lib/go-1.8/src/runtime/proc.go:127 +0x58 fp=0x1442002e7d0 
sp=0x1442002e780
runtime.goexit()
/usr/lib/go-1.8/src/runtime/asm_arm64.s:981 +0x4 fp=0x1442002e7d0 
sp=0x1442002e7d0
# github.com/google/syzkaller/vendor/golang.org/x/net/context
runtime: failed to create new OS thread (have 2 already; errno=22)
fatal error: newosproc

runtime stack:
runtime.throw(0x5fdfda, 0x9)
/usr/lib/go-1.8/src/runtime/panic.go:596 +0x70
runtime.newosproc(0x14420010400, 0x14420042000)
/usr/lib/go-1.8/src/runtime/os_linux.go:163 +0x168
runtime.newm(0x618cb0, 0x0)
/usr/lib/go-1.8/src/runtime/proc.go:1628 +0x110
runtime.main.func1()
/usr/lib/go-1.8/src/runtime/proc.go:126 +0x28
runtime.systemstack(0x909800)
/usr/lib/go-1.8/src/runtime/asm_arm64.s:241 +0x90
runtime.mstart()
/usr/lib/go-1.8/src/runtime/proc.go:1132

goroutine 1 [running]:
runtime.systemstack_switch()
/usr/lib/go-1.8/src/runtime/asm_arm64.s:190 +0x8 fp=0x14420030780 
sp=0x14420030770
runtime.main()
/usr/lib/go-1.8/src/runtime/proc.go:127 +0x58 fp=0x144200307d0 
sp=0x14420030780
runtime.goexit()
/usr/lib/go-1.8/src/runtime/asm_arm64.s:981 +0x4 fp=0x144200307d0 
sp=0x144200307d0
# net
runtime: failed to create new OS thread (have 2 already; errno=22)
fatal error: newosproc

runtime stack:
runtime.throw(0x5fdfda, 0x9)
/usr/lib/go-1.8/src/runtime/panic.go:596 +0x70
runtime.newosproc(0x14420010400, 0x1442004)
/usr/lib/go-1.8/src/runtime/os_linux.go:163 +0x168
runtime.newm(0x618cb0, 0x0)
/usr/lib/go-1.8/src/runtime/proc.go:1628 +0x110
runtime.main.func1()
/usr/lib/go-1.8/src/runtime/proc.go:126 +0x28
runtime.systemstack(0x909800)
/usr/lib/go-1.8/src/runtime/asm_arm64.s:241 +0x90
runtime.mstart()
/usr/lib/go-1.8/src/runtime/proc.go:1132

goroutine 1 [running]:
runtime.sy

[go-nuts] Goroutines memory leak

2018-04-29 Thread Vadim

I'm have memory leak in this function but i don't know where.

func CheckProxySOCKS(prox string, c chan QR) (err error) {


//Sending request through proxy
dialer, _ := proxy.SOCKS5("tcp", prox, nil, proxy.Direct)
timeout := time.Duration(5 * time.Second)
httpClient := &http.Client{Timeout: timeout, Transport: &http.Transport{
Dial: dialer.Dial}}
res, err := httpClient.Get("https://api.ipify.org?format=json";)


if err != nil {


c <- QR{Addr: prox, Res: false}
return
}


_, err = ioutil.ReadAll(res.Body)
res.Body.Close()
if err != nil {
return
}


c <- QR{Addr: prox, Res: true}
return
}

Here i called it

for _, proxy := range splitedProxies {
go code.CheckProxySOCKS(proxy, respChan)
}


for range splitedProxies {
r := <-respChan
if r.Res {
checkedProxiesArray = append(checkedProxiesArray, r.Addr)
}
}

After 3-4 cycle i'v got more than 40k goroutines(i'v check it by 
runtime.NumGoroutine()). After start app used around 100mb after 4 cycle 
more than 1GB

Github  repo with all code

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

Re: [go-nuts] [ANN] gomacro v2.6 - interactive Go interpreter, now with debugger

2018-04-29 Thread Maxim Khitrov

I didn't have anything specific in mind, just curious about what is
possible and how much work is required. Sounds like it's something
I'll probably avoid for now. Thanks for the API and info about adding
special commands!

I can't offer much feedback about Mozilla Public License because it's
not one that my company has vetted. To me, it seems more
commercial-friendly than [L]GPL, but IANAL.

On Sun, Apr 29, 2018 at 9:52 AM, Max  wrote:
> About the "other languages extensions":
>
> it's obviously easier than modifying the official Go compiler, but it's
> usually still a major task,
> especially if it involves modifying the "poor man's compiler" fast.Comp
> which converts a parsed ast.Node into a tree of function closures for
> execution.
>
> If you have a specific example in mind and you describe it, I can be more
> specific.
>
> On Saturday, April 28, 2018 at 11:59:41 PM UTC+2, Maxim Khitrov wrote:
>>
>> Do you have examples of adding custom ":xyz" or other language extensions?

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

Re: [go-nuts] float accuracy when calculating Fibonacci numbers

2018-04-29 Thread Michael Jones

Not sure what you mean with "by design." The design here is the IEEE
Standard for Floating-Point Arithmetic (IEEE 754). It is authoritative for
Intel, AMD, IBM, Sun, etc.

Typical (universal?) C and C++ implementations map 'float' to 32-bit IEEE
754 binary floating point and 'double' to the related 64-bit version. Go
uses this same hardware in the same (universal?) way, through the types
"float32" and "float64."

Truncation of floating point types to integer, or the floor() function,
discards any fractional part. Such that:
int(e) => 2
int(pi) => 3

Rounding up to the nearest integer with int(v+0.5) and floor(v+0.5) is a
different operation:
round(e) => 3
round(pi) => 3

Your C program truncates and your Go program rounds. They are not the same
program. They compute different things, which is why the results are
different.

In a de Moivre coding of Fibonacci evaluation using rounding as above,
Knuth showed that the pow((1-sqrt(5))/2,n) term--the second summand--may be
dropped.

For 64-bit floating point the F(75) value is the most that you can generate
this way.

Using other methods you can (and more quickly) generate values up to F(92),
which is the greatest Fibonacci value (7540113804746346429) representable
as a 64-bit unsigned integer.

For completeness, there is also the Ceiling function:
ceil(e) => 3
ceil(pi) => 4

hope this helps.

On Sun, Apr 29, 2018 at 12:36 PM Yuval Lifshitz  wrote:

> in C/C++ (at least on my system) "float" 4 has 4 bytes (32bits) and double
> has 8 bytes (64bits). according to this: https://golang.org/pkg/math/ its
> is the same thing with go.
>
> On Sunday, 29 April 2018 22:27:23 UTC+3, Louki Sumirniy wrote:
>>
>> I could be wrong but float64 is 'float' and 'double float' is float128. I
>> dunno, I have not tinkered with these imprecise math types. That's just,
>> essentially, what they were back in the olden days, like 20 years ago. 64
>> bit was basic float, 128 was double. I have been out of the loop for way
>> too long on these things (and I am not a fan of floats anyway, give me some
>> fixed precision pls).
>>
>> On Sunday, 29 April 2018 10:08:15 UTC+3, Yuval Lifshitz wrote:
>>>
>>> (1) I understand the issue of limited precision, this is why I did not
>>> try anything above F(59) But my concern was not the difference between
>>> algebra and the go implementation it was the different results I got with
>>> the C/C++ implementation (gcc 7.3.1):
>>>
>>> #include 
>>>
>>> const double sqrt_5 = sqrt(5.0);
>>> const double phi = (1.0 + sqrt_5)/2.0;
>>> const double psi = -1.0/phi;
>>>
>>> // find the nth fibonacci number based on Binet's formula
>>> // see here:
>>> https://en.wikipedia.org/wiki/Fibonacci_number#Closed-form_expression
>>> unsigned long long fibonacci(unsigned n)
>>> {
>>> return (unsigned long long)((pow(phi, n) - pow(psi, n))/sqrt_5);
>>> }
>>>
>>>
>>> (2) Thanks for the fix, work well for the go implementation. However, if
>>> i try to apply it on the C++ one (where there is no rounding), it makes
>>> some of the tests fails. So, I guess that without rounding, the psi part is
>>> needed
>>>
>>> (3) Is there a way to print the map ordered (didn't see that in your
>>> snippet)?
>>>
>>> (4) Wanted to compare "double" in C++ to "float64" in go. As they should
>>> consume same amount of memory, have similar algorithms etc. but good to
>>> know about the "big" package in go
>>>
>>> (5) Thanks for the reference. interesting read
>>>
>>> On Saturday, 28 April 2018 00:57:42 UTC+3, Michael Jones wrote:

 Yuval,

 There are fundamental issues here.

 1. That equation (de Moivre, Binet) is from the algebra of ideal
 numbers. Numbers of infinite precision. Not the realm of computer
 arithmetic. It works fine with double precision (go: float64, c/c++:
 double) up to F(75) but must fail for F(76) due to the limited precision of
 64-bit floating point and has nothing to do with language.

 F(76) = 3416454622906707 but the best we can do in 64 bits is
 3416454622906706 even with a Pow() function good to +/-1 least significant
 bit.

 2. Another difference between algebra and computer arithmetic
 (well...actually about the floor function) is that one of your two power
 terms is not needed. Psi < 1 so Psi^N is pretty small, so small, that it
 never changes the value of the rounded result. So you can just evaluate:

 return round(math.Pow(math.Phi, float_n) / sqrt_5)

 3. Using a map in your test is not wrong, but it means that the tests
 will be executed in a random order, which makes the printed errors a little
 less clear.

 celeste:fib mtj$ go test -v
 === RUN   Test_fibonacci
 --- FAIL: Test_fibonacci (0.00s)
 fib_test.go:104: 82 : Expected 61305790721611591 got 61305790721611584
 fib_test.go:104: 84 : Expected 160500643816367088 got 160500643816367040
 fib_test.go:104: 81 : Expected 37889062373143906 got 37889062373143896
 fib_test.go:

Re: [go-nuts] float accuracy when calculating Fibonacci numbers

2018-04-29 Thread Yuval Lifshitz

in C/C++ (at least on my system) "float" 4 has 4 bytes (32bits) and double 
has 8 bytes (64bits). according to this: https://golang.org/pkg/math/ its 
is the same thing with go.

On Sunday, 29 April 2018 22:27:23 UTC+3, Louki Sumirniy wrote:
>
> I could be wrong but float64 is 'float' and 'double float' is float128. I 
> dunno, I have not tinkered with these imprecise math types. That's just, 
> essentially, what they were back in the olden days, like 20 years ago. 64 
> bit was basic float, 128 was double. I have been out of the loop for way 
> too long on these things (and I am not a fan of floats anyway, give me some 
> fixed precision pls).
>
> On Sunday, 29 April 2018 10:08:15 UTC+3, Yuval Lifshitz wrote:
>>
>> (1) I understand the issue of limited precision, this is why I did not 
>> try anything above F(59) But my concern was not the difference between 
>> algebra and the go implementation it was the different results I got with 
>> the C/C++ implementation (gcc 7.3.1):
>>
>> #include 
>>
>> const double sqrt_5 = sqrt(5.0);
>> const double phi = (1.0 + sqrt_5)/2.0;
>> const double psi = -1.0/phi;
>>
>> // find the nth fibonacci number based on Binet's formula
>> // see here: 
>> https://en.wikipedia.org/wiki/Fibonacci_number#Closed-form_expression
>> unsigned long long fibonacci(unsigned n)
>> {
>> return (unsigned long long)((pow(phi, n) - pow(psi, n))/sqrt_5);
>> }
>>
>>
>> (2) Thanks for the fix, work well for the go implementation. However, if 
>> i try to apply it on the C++ one (where there is no rounding), it makes 
>> some of the tests fails. So, I guess that without rounding, the psi part is 
>> needed
>>
>> (3) Is there a way to print the map ordered (didn't see that in your 
>> snippet)?
>>
>> (4) Wanted to compare "double" in C++ to "float64" in go. As they should 
>> consume same amount of memory, have similar algorithms etc. but good to 
>> know about the "big" package in go
>>
>> (5) Thanks for the reference. interesting read
>>
>> On Saturday, 28 April 2018 00:57:42 UTC+3, Michael Jones wrote:
>>>
>>> Yuval,
>>>
>>> There are fundamental issues here.
>>>
>>> 1. That equation (de Moivre, Binet) is from the algebra of ideal 
>>> numbers. Numbers of infinite precision. Not the realm of computer 
>>> arithmetic. It works fine with double precision (go: float64, c/c++: 
>>> double) up to F(75) but must fail for F(76) due to the limited precision of 
>>> 64-bit floating point and has nothing to do with language.
>>>
>>> F(76) = 3416454622906707 but the best we can do in 64 bits is 
>>> 3416454622906706 even with a Pow() function good to +/-1 least significant 
>>> bit.
>>>
>>> 2. Another difference between algebra and computer arithmetic 
>>> (well...actually about the floor function) is that one of your two power 
>>> terms is not needed. Psi < 1 so Psi^N is pretty small, so small, that it 
>>> never changes the value of the rounded result. So you can just evaluate:
>>>
>>> return round(math.Pow(math.Phi, float_n) / sqrt_5)
>>>
>>> 3. Using a map in your test is not wrong, but it means that the tests 
>>> will be executed in a random order, which makes the printed errors a little 
>>> less clear.
>>>
>>> celeste:fib mtj$ go test -v 
>>> === RUN   Test_fibonacci
>>> --- FAIL: Test_fibonacci (0.00s)
>>> fib_test.go:104: 82 : Expected 61305790721611591 got 61305790721611584
>>> fib_test.go:104: 84 : Expected 160500643816367088 got 160500643816367040
>>> fib_test.go:104: 81 : Expected 37889062373143906 got 37889062373143896
>>> fib_test.go:104: 87 : Expected 679891637638612258 got 679891637638612096
>>> fib_test.go:104: 88 : Expected 1100087778366101931 got 
>>> 1100087778366101632
>>> fib_test.go:104: 83 : Expected 99194853094755497 got 99194853094755488
>>> fib_test.go:104: 77 : Expected 5527939700884757 got 5527939700884756
>>> fib_test.go:104: 86 : Expected 420196140727489673 got 420196140727489600
>>> fib_test.go:104: 90 : Expected 2880067194370816120 got 
>>> 2880067194370815488
>>> fib_test.go:104: 91 : Expected 4660046610375530309 got 
>>> 4660046610375529472
>>> fib_test.go:104: 92 : Expected 7540113804746346429 got 
>>> 754011380474638
>>> fib_test.go:104: 76 : Expected 3416454622906707 got 3416454622906706
>>> fib_test.go:104: 85 : Expected 259695496911122585 got 259695496911122528
>>> fib_test.go:104: 89 : Expected 1779979416004714189 got 
>>> 1779979416004713728
>>> fib_test.go:104: 79 : Expected 14472334024676221 got 14472334024676218
>>> fib_test.go:104: 80 : Expected 23416728348467685 got 23416728348467676
>>> FAIL
>>> exit status 1
>>> FAIL fib 0.003s
>>>
>>> updated fib.go: https://play.golang.org/p/N-8lmjrMYAq
>>> update fib_test.go: https://play.golang.org/p/FPuN58m1VVs
>>>
>>> 4. Plenty of ways to do this computation in Go using 64-bit integers, or 
>>> big floats, or big ints.
>>>
>>> 5. Plenty of algorithms, some quite fascinating! 
>>> https://ir.library.oregonstate.edu/downloads/t435gg51w 
>>>

Re: [go-nuts] float accuracy when calculating Fibonacci numbers

2018-04-29 Thread Louki Sumirniy

I could be wrong but float64 is 'float' and 'double float' is float128. I 
dunno, I have not tinkered with these imprecise math types. That's just, 
essentially, what they were back in the olden days, like 20 years ago. 64 
bit was basic float, 128 was double. I have been out of the loop for way 
too long on these things (and I am not a fan of floats anyway, give me some 
fixed precision pls).

On Sunday, 29 April 2018 10:08:15 UTC+3, Yuval Lifshitz wrote:
>
> (1) I understand the issue of limited precision, this is why I did not try 
> anything above F(59) But my concern was not the difference between algebra 
> and the go implementation it was the different results I got with the C/C++ 
> implementation (gcc 7.3.1):
>
> #include 
>
> const double sqrt_5 = sqrt(5.0);
> const double phi = (1.0 + sqrt_5)/2.0;
> const double psi = -1.0/phi;
>
> // find the nth fibonacci number based on Binet's formula
> // see here: 
> https://en.wikipedia.org/wiki/Fibonacci_number#Closed-form_expression
> unsigned long long fibonacci(unsigned n)
> {
> return (unsigned long long)((pow(phi, n) - pow(psi, n))/sqrt_5);
> }
>
>
> (2) Thanks for the fix, work well for the go implementation. However, if i 
> try to apply it on the C++ one (where there is no rounding), it makes some 
> of the tests fails. So, I guess that without rounding, the psi part is 
> needed
>
> (3) Is there a way to print the map ordered (didn't see that in your 
> snippet)?
>
> (4) Wanted to compare "double" in C++ to "float64" in go. As they should 
> consume same amount of memory, have similar algorithms etc. but good to 
> know about the "big" package in go
>
> (5) Thanks for the reference. interesting read
>
> On Saturday, 28 April 2018 00:57:42 UTC+3, Michael Jones wrote:
>>
>> Yuval,
>>
>> There are fundamental issues here.
>>
>> 1. That equation (de Moivre, Binet) is from the algebra of ideal numbers. 
>> Numbers of infinite precision. Not the realm of computer arithmetic. It 
>> works fine with double precision (go: float64, c/c++: double) up to F(75) 
>> but must fail for F(76) due to the limited precision of 64-bit floating 
>> point and has nothing to do with language.
>>
>> F(76) = 3416454622906707 but the best we can do in 64 bits is 
>> 3416454622906706 even with a Pow() function good to +/-1 least significant 
>> bit.
>>
>> 2. Another difference between algebra and computer arithmetic 
>> (well...actually about the floor function) is that one of your two power 
>> terms is not needed. Psi < 1 so Psi^N is pretty small, so small, that it 
>> never changes the value of the rounded result. So you can just evaluate:
>>
>> return round(math.Pow(math.Phi, float_n) / sqrt_5)
>>
>> 3. Using a map in your test is not wrong, but it means that the tests 
>> will be executed in a random order, which makes the printed errors a little 
>> less clear.
>>
>> celeste:fib mtj$ go test -v 
>> === RUN   Test_fibonacci
>> --- FAIL: Test_fibonacci (0.00s)
>> fib_test.go:104: 82 : Expected 61305790721611591 got 61305790721611584
>> fib_test.go:104: 84 : Expected 160500643816367088 got 160500643816367040
>> fib_test.go:104: 81 : Expected 37889062373143906 got 37889062373143896
>> fib_test.go:104: 87 : Expected 679891637638612258 got 679891637638612096
>> fib_test.go:104: 88 : Expected 1100087778366101931 got 1100087778366101632
>> fib_test.go:104: 83 : Expected 99194853094755497 got 99194853094755488
>> fib_test.go:104: 77 : Expected 5527939700884757 got 5527939700884756
>> fib_test.go:104: 86 : Expected 420196140727489673 got 420196140727489600
>> fib_test.go:104: 90 : Expected 2880067194370816120 got 2880067194370815488
>> fib_test.go:104: 91 : Expected 4660046610375530309 got 4660046610375529472
>> fib_test.go:104: 92 : Expected 7540113804746346429 got 754011380474638
>> fib_test.go:104: 76 : Expected 3416454622906707 got 3416454622906706
>> fib_test.go:104: 85 : Expected 259695496911122585 got 259695496911122528
>> fib_test.go:104: 89 : Expected 1779979416004714189 got 1779979416004713728
>> fib_test.go:104: 79 : Expected 14472334024676221 got 14472334024676218
>> fib_test.go:104: 80 : Expected 23416728348467685 got 23416728348467676
>> FAIL
>> exit status 1
>> FAIL fib 0.003s
>>
>> updated fib.go: https://play.golang.org/p/N-8lmjrMYAq
>> update fib_test.go: https://play.golang.org/p/FPuN58m1VVs
>>
>> 4. Plenty of ways to do this computation in Go using 64-bit integers, or 
>> big floats, or big ints.
>>
>> 5. Plenty of algorithms, some quite fascinating! 
>> https://ir.library.oregonstate.edu/downloads/t435gg51w 
>> 
>>
>>
>> On Thu, Apr 26, 2018 at 10:22 AM, Ian Lance Taylor  
>> wrote:
>>
>>> On Thu, Apr 26, 2018 at 1:17 AM, Yuval Lifshitz  
>>> wrote:
>>> >
>>> > I ran into the following issue when started playing with go. Had the
>>> > following small program to calculate Fibonacci numbers using the closed

Re: [go-nuts] float accuracy when calculating Fibonacci numbers

2018-04-29 Thread Yuval Lifshitz

Thanks Michael. Is this "by design"? Does it worth an issue here 
?

On Sunday, 29 April 2018 18:06:23 UTC+3, Michael Jones wrote:
>
> yes. truncation and round-up are important differences between your c/c++ 
> code and the go code.
>
> On Sun, Apr 29, 2018 at 12:08 AM Yuval Lifshitz  > wrote:
>
>> (1) I understand the issue of limited precision, this is why I did not 
>> try anything above F(59) But my concern was not the difference between 
>> algebra and the go implementation it was the different results I got with 
>> the C/C++ implementation (gcc 7.3.1):
>>
>> #include 
>>
>> const double sqrt_5 = sqrt(5.0);
>> const double phi = (1.0 + sqrt_5)/2.0;
>> const double psi = -1.0/phi;
>>
>> // find the nth fibonacci number based on Binet's formula
>> // see here: 
>> https://en.wikipedia.org/wiki/Fibonacci_number#Closed-form_expression
>> unsigned long long fibonacci(unsigned n)
>> {
>> return (unsigned long long)((pow(phi, n) - pow(psi, n))/sqrt_5);
>> }
>>
>>
>> (2) Thanks for the fix, work well for the go implementation. However, if 
>> i try to apply it on the C++ one (where there is no rounding), it makes 
>> some of the tests fails. So, I guess that without rounding, the psi part is 
>> needed
>>
>> (3) Is there a way to print the map ordered (didn't see that in your 
>> snippet)?
>>
>> (4) Wanted to compare "double" in C++ to "float64" in go. As they should 
>> consume same amount of memory, have similar algorithms etc. but good to 
>> know about the "big" package in go
>>
>> (5) Thanks for the reference. interesting read
>>
>> On Saturday, 28 April 2018 00:57:42 UTC+3, Michael Jones wrote:
>>>
>>> Yuval,
>>>
>>> There are fundamental issues here.
>>>
>>> 1. That equation (de Moivre, Binet) is from the algebra of ideal 
>>> numbers. Numbers of infinite precision. Not the realm of computer 
>>> arithmetic. It works fine with double precision (go: float64, c/c++: 
>>> double) up to F(75) but must fail for F(76) due to the limited precision of 
>>> 64-bit floating point and has nothing to do with language.
>>>
>>> F(76) = 3416454622906707 but the best we can do in 64 bits is 
>>> 3416454622906706 even with a Pow() function good to +/-1 least significant 
>>> bit.
>>>
>>> 2. Another difference between algebra and computer arithmetic 
>>> (well...actually about the floor function) is that one of your two power 
>>> terms is not needed. Psi < 1 so Psi^N is pretty small, so small, that it 
>>> never changes the value of the rounded result. So you can just evaluate:
>>>
>>> return round(math.Pow(math.Phi, float_n) / sqrt_5)
>>>
>>> 3. Using a map in your test is not wrong, but it means that the tests 
>>> will be executed in a random order, which makes the printed errors a little 
>>> less clear.
>>>
>>> celeste:fib mtj$ go test -v 
>>> === RUN   Test_fibonacci
>>> --- FAIL: Test_fibonacci (0.00s)
>>> fib_test.go:104: 82 : Expected 61305790721611591 got 61305790721611584
>>> fib_test.go:104: 84 : Expected 160500643816367088 got 160500643816367040
>>> fib_test.go:104: 81 : Expected 37889062373143906 got 37889062373143896
>>> fib_test.go:104: 87 : Expected 679891637638612258 got 679891637638612096
>>> fib_test.go:104: 88 : Expected 1100087778366101931 got 
>>> 1100087778366101632
>>> fib_test.go:104: 83 : Expected 99194853094755497 got 99194853094755488
>>> fib_test.go:104: 77 : Expected 5527939700884757 got 5527939700884756
>>> fib_test.go:104: 86 : Expected 420196140727489673 got 420196140727489600
>>> fib_test.go:104: 90 : Expected 2880067194370816120 got 
>>> 2880067194370815488
>>> fib_test.go:104: 91 : Expected 4660046610375530309 got 
>>> 4660046610375529472
>>> fib_test.go:104: 92 : Expected 7540113804746346429 got 
>>> 754011380474638
>>> fib_test.go:104: 76 : Expected 3416454622906707 got 3416454622906706
>>> fib_test.go:104: 85 : Expected 259695496911122585 got 259695496911122528
>>> fib_test.go:104: 89 : Expected 1779979416004714189 got 
>>> 1779979416004713728
>>> fib_test.go:104: 79 : Expected 14472334024676221 got 14472334024676218
>>> fib_test.go:104: 80 : Expected 23416728348467685 got 23416728348467676
>>> FAIL
>>> exit status 1
>>> FAIL fib 0.003s
>>>
>>> updated fib.go: https://play.golang.org/p/N-8lmjrMYAq
>>> update fib_test.go: https://play.golang.org/p/FPuN58m1VVs
>>>
>>> 4. Plenty of ways to do this computation in Go using 64-bit integers, or 
>>> big floats, or big ints.
>>>
>>> 5. Plenty of algorithms, some quite fascinating! 
>>> https://ir.library.oregonstate.edu/downloads/t435gg51w 
>>> 
>>>
>>>
>>> On Thu, Apr 26, 2018 at 10:22 AM, Ian Lance Taylor  
>>> wrote:
>>>
 On Thu, Apr 26, 2018 at 1:17 AM, Yuval Lifshitz  
 wrote:
 >
 > I ran into the following issue when started playing with go. Had the
 > following small program to calculate Fibonacci numbers using the

Re: [go-nuts] [ANN] gomacro v2.6 - interactive Go interpreter, now with debugger

2018-04-29 Thread Louki Sumirniy

So, the fastest way on the compile-side for making collections of functions 
(optionally, tied to some common data type) is using closures? I thought so 
also, that's the direction I went instead of interfaces in my own work for 
the same reason.

On Sunday, 29 April 2018 16:52:44 UTC+3, Max wrote:
>
> About the "other languages extensions":
>
> it's obviously easier than modifying the official Go compiler, but it's 
> usually still a major task,
> especially if it involves modifying the "poor man's compiler" fast.Comp
> which converts a parsed ast.Node into a tree of function closures for 
> execution.
>
> If you have a specific example in mind and you describe it, I can be more 
> specific.
>
> On Saturday, April 28, 2018 at 11:59:41 PM UTC+2, Maxim Khitrov wrote:
>>
>> Do you have examples of adding custom ":xyz" or other language 
>> extensions? 
>>
>

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

Re: [go-nuts] float accuracy when calculating Fibonacci numbers

2018-04-29 Thread Michael Jones

yes. truncation and round-up are important differences between your c/c++
code and the go code.

On Sun, Apr 29, 2018 at 12:08 AM Yuval Lifshitz  wrote:

> (1) I understand the issue of limited precision, this is why I did not try
> anything above F(59) But my concern was not the difference between algebra
> and the go implementation it was the different results I got with the C/C++
> implementation (gcc 7.3.1):
>
> #include 
>
> const double sqrt_5 = sqrt(5.0);
> const double phi = (1.0 + sqrt_5)/2.0;
> const double psi = -1.0/phi;
>
> // find the nth fibonacci number based on Binet's formula
> // see here:
> https://en.wikipedia.org/wiki/Fibonacci_number#Closed-form_expression
> unsigned long long fibonacci(unsigned n)
> {
> return (unsigned long long)((pow(phi, n) - pow(psi, n))/sqrt_5);
> }
>
>
> (2) Thanks for the fix, work well for the go implementation. However, if i
> try to apply it on the C++ one (where there is no rounding), it makes some
> of the tests fails. So, I guess that without rounding, the psi part is
> needed
>
> (3) Is there a way to print the map ordered (didn't see that in your
> snippet)?
>
> (4) Wanted to compare "double" in C++ to "float64" in go. As they should
> consume same amount of memory, have similar algorithms etc. but good to
> know about the "big" package in go
>
> (5) Thanks for the reference. interesting read
>
> On Saturday, 28 April 2018 00:57:42 UTC+3, Michael Jones wrote:
>>
>> Yuval,
>>
>> There are fundamental issues here.
>>
>> 1. That equation (de Moivre, Binet) is from the algebra of ideal numbers.
>> Numbers of infinite precision. Not the realm of computer arithmetic. It
>> works fine with double precision (go: float64, c/c++: double) up to F(75)
>> but must fail for F(76) due to the limited precision of 64-bit floating
>> point and has nothing to do with language.
>>
>> F(76) = 3416454622906707 but the best we can do in 64 bits is
>> 3416454622906706 even with a Pow() function good to +/-1 least significant
>> bit.
>>
>> 2. Another difference between algebra and computer arithmetic
>> (well...actually about the floor function) is that one of your two power
>> terms is not needed. Psi < 1 so Psi^N is pretty small, so small, that it
>> never changes the value of the rounded result. So you can just evaluate:
>>
>> return round(math.Pow(math.Phi, float_n) / sqrt_5)
>>
>> 3. Using a map in your test is not wrong, but it means that the tests
>> will be executed in a random order, which makes the printed errors a little
>> less clear.
>>
>> celeste:fib mtj$ go test -v
>> === RUN   Test_fibonacci
>> --- FAIL: Test_fibonacci (0.00s)
>> fib_test.go:104: 82 : Expected 61305790721611591 got 61305790721611584
>> fib_test.go:104: 84 : Expected 160500643816367088 got 160500643816367040
>> fib_test.go:104: 81 : Expected 37889062373143906 got 37889062373143896
>> fib_test.go:104: 87 : Expected 679891637638612258 got 679891637638612096
>> fib_test.go:104: 88 : Expected 1100087778366101931 got 1100087778366101632
>> fib_test.go:104: 83 : Expected 99194853094755497 got 99194853094755488
>> fib_test.go:104: 77 : Expected 5527939700884757 got 5527939700884756
>> fib_test.go:104: 86 : Expected 420196140727489673 got 420196140727489600
>> fib_test.go:104: 90 : Expected 2880067194370816120 got 2880067194370815488
>> fib_test.go:104: 91 : Expected 4660046610375530309 got 4660046610375529472
>> fib_test.go:104: 92 : Expected 7540113804746346429 got 754011380474638
>> fib_test.go:104: 76 : Expected 3416454622906707 got 3416454622906706
>> fib_test.go:104: 85 : Expected 259695496911122585 got 259695496911122528
>> fib_test.go:104: 89 : Expected 1779979416004714189 got 1779979416004713728
>> fib_test.go:104: 79 : Expected 14472334024676221 got 14472334024676218
>> fib_test.go:104: 80 : Expected 23416728348467685 got 23416728348467676
>> FAIL
>> exit status 1
>> FAIL fib 0.003s
>>
>> updated fib.go: https://play.golang.org/p/N-8lmjrMYAq
>> update fib_test.go: https://play.golang.org/p/FPuN58m1VVs
>>
>> 4. Plenty of ways to do this computation in Go using 64-bit integers, or
>> big floats, or big ints.
>>
>> 5. Plenty of algorithms, some quite fascinating!
>> https://ir.library.oregonstate.edu/downloads/t435gg51w
>> 
>>
>>
>> On Thu, Apr 26, 2018 at 10:22 AM, Ian Lance Taylor 
>> wrote:
>>
>>> On Thu, Apr 26, 2018 at 1:17 AM, Yuval Lifshitz 
>>> wrote:
>>> >
>>> > I ran into the following issue when started playing with go. Had the
>>> > following small program to calculate Fibonacci numbers using the closed
>>> > form:
>>> >
>>> > package "fib"
>>> >
>>> > import "math"
>>> >
>>> > var sqrt_5 = math.Sqrt(5.0)
>>> > var psi = -1.0/math.Phi
>>> >
>>> > // had to add this to solve accuracy issue
>>> > func round(x float64) uint64 {
>>> > return uint64(math.Floor(x + 0.5))
>>> > }
>>> >
>>> > // find the nth fibonacci number based on Bi

Re: [go-nuts] [ANN] gomacro v2.6 - interactive Go interpreter, now with debugger

2018-04-29 Thread Max

About the "other languages extensions":

it's obviously easier than modifying the official Go compiler, but it's 
usually still a major task,
especially if it involves modifying the "poor man's compiler" fast.Comp
which converts a parsed ast.Node into a tree of function closures for 
execution.

If you have a specific example in mind and you describe it, I can be more 
specific.

On Saturday, April 28, 2018 at 11:59:41 PM UTC+2, Maxim Khitrov wrote:
>
> Do you have examples of adding custom ":xyz" or other language extensions? 
>

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

Re: [go-nuts] [ANN] gomacro v2.6 - interactive Go interpreter, now with debugger

2018-04-29 Thread Max

Done and documented :)

As I also wrote in README.md, see 
https://github.com/cosmos72/gomacro/blob/master/fast/cmd.go#L37
for the documentation and API to define new special commands.

The TL;DR summary is:

choose a name for the new command, write a function with signature
  func(interp *fast.Interp, arg string, opt fast.CmdOpt) (string, 
fast.CmdOpt)
that implements the desired functionality, write the help string, then call:

fast.Commands.Add(Cmd{Name: name, Func: function, Help: help})

On Saturday, April 28, 2018 at 11:59:41 PM UTC+2, Maxim Khitrov wrote:
>
> Do you have examples of adding custom ":xyz" or other language extensions? 
>

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

[go-nuts] gomobile bind "skipped function" error in xcode

2018-04-29 Thread Elias Naur

Only byte slices ([]byte) are supported by gomobile bind. Try replacing your 
int slices with byte slices and it should appear in ObjC.

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

Re: [go-nuts] Question about int inside json

2018-04-29 Thread Jan Mercl

On Sun, Apr 29, 2018 at 5:52 AM  wrote:

> Almost every documentation I've found says int is 32 bit long, so that I
expect a range from -2.147.483.648 to 2.147.483.647.

Can you please share an example of such incorrect documentation?

-- 

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

[go-nuts] Re: Question about int inside json

2018-04-29 Thread T L



On Saturday, April 28, 2018 at 11:52:24 PM UTC-4, Milo Pickard wrote:
>
>
> Hallo all, 
>
> I've a "stupid" question about the type "int" when used inside json. 
> Almost every documentation I've found says int is 32 bit long, so that I 
> expect a range from -2.147.483.648 to 2.147.483.647.
>
>
>
> So I "mistakely" did that:
>
> type Comment struct {
>  IDint   `json:"id"`
>  URL   string`json:"url"`
>  Comment   string`json:"comment"`
>  Html  string`json:"html"`
>  Name  string`json:"name"`
>  Timestamp time.Time `json:"timestamp"`
>  Parentint   `json:"parent"`
> }
>
>
>
> then some code, where c is *Comment, and..
>
>
> t := time.Now()
> c.ID = int(t.UnixNano() / 100)
>
>
> but, when I wrote c.ID into a JSON file, it resulted in:
>
> 1524937580003
>
> which is correct, but cannot fit in 32 bits. 
>

why not use int64 instead?
 

>
> The version I'm using is 
> go version go1.9.4 linux/amd64
>
>
> is it a bug of this specific version, or is something I didn't got about 
> int inside struct json structs, like c.ID? 
>
> many thanks
>
> Milo
>
>
>
>
>
>
>
>
>
>

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

Re: [go-nuts] float accuracy when calculating Fibonacci numbers

2018-04-29 Thread Yuval Lifshitz

(1) I understand the issue of limited precision, this is why I did not try 
anything above F(59) But my concern was not the difference between algebra 
and the go implementation it was the different results I got with the C/C++ 
implementation (gcc 7.3.1):

#include 

const double sqrt_5 = sqrt(5.0);
const double phi = (1.0 + sqrt_5)/2.0;
const double psi = -1.0/phi;

// find the nth fibonacci number based on Binet's formula
// see here: 
https://en.wikipedia.org/wiki/Fibonacci_number#Closed-form_expression
unsigned long long fibonacci(unsigned n)
{
return (unsigned long long)((pow(phi, n) - pow(psi, n))/sqrt_5);
}


(2) Thanks for the fix, work well for the go implementation. However, if i 
try to apply it on the C++ one (where there is no rounding), it makes some 
of the tests fails. So, I guess that without rounding, the psi part is 
needed

(3) Is there a way to print the map ordered (didn't see that in your 
snippet)?

(4) Wanted to compare "double" in C++ to "float64" in go. As they should 
consume same amount of memory, have similar algorithms etc. but good to 
know about the "big" package in go

(5) Thanks for the reference. interesting read

On Saturday, 28 April 2018 00:57:42 UTC+3, Michael Jones wrote:
>
> Yuval,
>
> There are fundamental issues here.
>
> 1. That equation (de Moivre, Binet) is from the algebra of ideal numbers. 
> Numbers of infinite precision. Not the realm of computer arithmetic. It 
> works fine with double precision (go: float64, c/c++: double) up to F(75) 
> but must fail for F(76) due to the limited precision of 64-bit floating 
> point and has nothing to do with language.
>
> F(76) = 3416454622906707 but the best we can do in 64 bits is 
> 3416454622906706 even with a Pow() function good to +/-1 least significant 
> bit.
>
> 2. Another difference between algebra and computer arithmetic 
> (well...actually about the floor function) is that one of your two power 
> terms is not needed. Psi < 1 so Psi^N is pretty small, so small, that it 
> never changes the value of the rounded result. So you can just evaluate:
>
> return round(math.Pow(math.Phi, float_n) / sqrt_5)
>
> 3. Using a map in your test is not wrong, but it means that the tests will 
> be executed in a random order, which makes the printed errors a little less 
> clear.
>
> celeste:fib mtj$ go test -v 
> === RUN   Test_fibonacci
> --- FAIL: Test_fibonacci (0.00s)
> fib_test.go:104: 82 : Expected 61305790721611591 got 61305790721611584
> fib_test.go:104: 84 : Expected 160500643816367088 got 160500643816367040
> fib_test.go:104: 81 : Expected 37889062373143906 got 37889062373143896
> fib_test.go:104: 87 : Expected 679891637638612258 got 679891637638612096
> fib_test.go:104: 88 : Expected 1100087778366101931 got 1100087778366101632
> fib_test.go:104: 83 : Expected 99194853094755497 got 99194853094755488
> fib_test.go:104: 77 : Expected 5527939700884757 got 5527939700884756
> fib_test.go:104: 86 : Expected 420196140727489673 got 420196140727489600
> fib_test.go:104: 90 : Expected 2880067194370816120 got 2880067194370815488
> fib_test.go:104: 91 : Expected 4660046610375530309 got 4660046610375529472
> fib_test.go:104: 92 : Expected 7540113804746346429 got 754011380474638
> fib_test.go:104: 76 : Expected 3416454622906707 got 3416454622906706
> fib_test.go:104: 85 : Expected 259695496911122585 got 259695496911122528
> fib_test.go:104: 89 : Expected 1779979416004714189 got 1779979416004713728
> fib_test.go:104: 79 : Expected 14472334024676221 got 14472334024676218
> fib_test.go:104: 80 : Expected 23416728348467685 got 23416728348467676
> FAIL
> exit status 1
> FAIL fib 0.003s
>
> updated fib.go: https://play.golang.org/p/N-8lmjrMYAq
> update fib_test.go: https://play.golang.org/p/FPuN58m1VVs
>
> 4. Plenty of ways to do this computation in Go using 64-bit integers, or 
> big floats, or big ints.
>
> 5. Plenty of algorithms, some quite fascinating! 
> https://ir.library.oregonstate.edu/downloads/t435gg51w 
> 
>
>
> On Thu, Apr 26, 2018 at 10:22 AM, Ian Lance Taylor  > wrote:
>
>> On Thu, Apr 26, 2018 at 1:17 AM, Yuval Lifshitz > > wrote:
>> >
>> > I ran into the following issue when started playing with go. Had the
>> > following small program to calculate Fibonacci numbers using the closed
>> > form:
>> >
>> > package "fib"
>> >
>> > import "math"
>> >
>> > var sqrt_5 = math.Sqrt(5.0)
>> > var psi = -1.0/math.Phi
>> >
>> > // had to add this to solve accuracy issue
>> > func round(x float64) uint64 {
>> > return uint64(math.Floor(x + 0.5))
>> > }
>> >
>> > // find the nth fibonacci number based on Binet's formula
>> > // see here:
>> > https://en.wikipedia.org/wiki/Fibonacci_number#Closed-form_expression
>> > func fibonacci(n uint) uint64 {
>> > float_n := float64(n)
>> > return round((math.Pow(math.Phi, float_n) - math.Pow(psi,
>> > float_n))/sqrt_5)
>> > }
>

Re: [go-nuts] float accuracy when calculating Fibonacci numbers

[go-nuts] Re: Failure to build syzkaller in a build chroot

[go-nuts] Goroutines memory leak

Re: [go-nuts] Failure to build syzkaller in a build chroot

AW: [go-nuts] Question about int inside json

[go-nuts] Failure to build syzkaller in a build chroot

[go-nuts] Goroutines memory leak

Re: [go-nuts] [ANN] gomacro v2.6 - interactive Go interpreter, now with debugger

Re: [go-nuts] float accuracy when calculating Fibonacci numbers

Re: [go-nuts] float accuracy when calculating Fibonacci numbers

Re: [go-nuts] float accuracy when calculating Fibonacci numbers

Re: [go-nuts] float accuracy when calculating Fibonacci numbers

Re: [go-nuts] [ANN] gomacro v2.6 - interactive Go interpreter, now with debugger

Re: [go-nuts] float accuracy when calculating Fibonacci numbers

Re: [go-nuts] [ANN] gomacro v2.6 - interactive Go interpreter, now with debugger

Re: [go-nuts] [ANN] gomacro v2.6 - interactive Go interpreter, now with debugger

[go-nuts] gomobile bind "skipped function" error in xcode

Re: [go-nuts] Question about int inside json

[go-nuts] Re: Question about int inside json

Re: [go-nuts] float accuracy when calculating Fibonacci numbers

20 matches

Site Navigation

Mail list logo

Footer information