Re: [go-nuts] how to write methods for a generic Matrix[float64 constrained by Addable]?

['Jakob Borg' via golang-nuts]

Two minor issues; you can’t declare func (m *Matrix[float64]) NanToZero() 
because we don’t have specialisation, it needs to be func (m *Matrix[T]) 
NanToZero(), and you can’t have complex as one of the possible types because 
it’s impossible to convert a complex to a float.

https://go.dev/play/p/QnWoKJ4bRcI

//jb

On 10 Sep 2023, at 01:31, Jason E. Aten  wrote:

I made a playground if anyone wants to play with it and figure out how to test 
their ideas.

https://go.dev/play/p/h1nqHJAdVG8

On Sunday, September 10, 2023 at 12:24:54 AM UTC+1 Jason E. Aten wrote:
Like how, specifically?

func (m *Matrix[float64]) NanToZero() {
for i := 0; i < m.Nrow; i++ {
for j := 0; j < m.Ncol; j++ {
v := m.At(i, j).(float64)
if math.IsNaN(v) {
m.Set(i, j, 0)
}
}
}
}
gives
./slurp1.go:944:9: invalid operation: cannot use type assertion on type 
parameter value m.At(i, j) (value of type float64 constrained by Addable)

On Sunday, September 10, 2023 at 12:04:53 AM UTC+1 Dan Kortschak wrote:
On Sat, 2023-09-09 at 15:39 -0700, Jason E. Aten wrote:
> New to generics... how can I write a method for a Matrix[float64]
> that uses a math function that expects a float64?   I get:
>
> ./slurp1.go:936:18: cannot use m.At(i, j) (value of type float64
> constrained by Addable) as float64 value in argument to math.IsNaN
>
> Casting it to float64() does not change this error(!)
>
> here is the essentials:
>
> type Addable interface {
> ~complex128 | ~complex64 | ~float64 | ~float32 |
> ~byte | ~uint16 | ~uint32 | ~uint64 |
> ~int8 | ~int16 | ~int32 | ~int64 | ~int
> }
>
> type Matrix[T Addable] struct {
> Nrow int
> Ncol int
> Dat[]T
> }
> ...
> func (m *Matrix[float64]) NanToZero() {
> for i := 0; i < m.Nrow; i++ {
> for j := 0; j < m.Ncol; j++ {
>
> if math.IsNaN(m.At(i, j)) {  // line 936, where the error
> is; ./slurp1.go:936:18: cannot use m.At(i, j) (value of type float64
> constrained by Addable) as float64 value in argument to math.IsNaN
>
> m.Set(i, j, 0)
> }
> }
> }
> }
>
> go version go1.20.6 linux/amd64

You will probably need to type assert.


--
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/4f7e642b-ef44-4564-93e7-b2f7c10ffb6dn%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 golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/DB33082D-B560-4C0C-846E-1E23F8BF846E%40kastelo.net.

Re: [go-nuts] map type conversion

['Jakob Borg' via golang-nuts]

On 17 Jul 2023, at 14:50, Leonard Mittmann  wrote:

Yes, but my thought was that it might be possible to do an unsafe conversion as 
the underlying types are the same. I just have no idea how.

https://go.dev/play/p/ViLnLvInv-1

The unsafe conversion appears to work, but it’s unsafe and not obvious to me 
that this is guaranteed to work. It’s allowed to convert one pointer to another 
if they have an “equivalent memory layout”, and I would guess that two map 
types with equivalent underlying types would share memory layout, but I don’t 
think the specs say anything about map memory layouts one way or the other.

//jb

-- 
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/AA75B829-B48F-4207-8D5F-9B75B2D17FAD%40kastelo.net.

Re: [go-nuts] Various questions about posts from The Go Blog

['Jakob Borg' via golang-nuts]

On 26 Mar 2023, at 20:01, Kamil Ziemian  wrote:

But I cannot understand why in the blog post we have in go.mod file
require rsc.io/quote v1.5.2
so "rsc.io/quote" is considered direct dependency, while 
go.mod produced by Go 1.20 give me
rsc.io/quote v1.5.2 // indirect
so now "rsc.io/quote" is indirect dependency, even when I 
write in package
import "rsc.io/quote”

That doesn’t happen for me though:

% cat hello.go
package hello

import "rsc.io/quote"

func Hello() string {
return quote.Hello()
}

% go mod init example.com/hello
go: creating new go.mod: module example.com/hello
go: to add module requirements and sums:
go mod tidy

% go mod tidy
go: finding module for package rsc.io/quote
go: found rsc.io/quote in rsc.io/quote v1.5.2

% cat go.mod
module example.com/hello

go 1.20

require rsc.io/quote v1.5.2

require (
golang.org/x/text v0.0.0-20170915032832-14c0d48ead0c // indirect
rsc.io/sampler v1.3.0 // indirect
)

-- 
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/067B34F7-F369-4622-8CBD-5BE3BA44DC3C%40kastelo.net.

Re: [go-nuts] Variable Declaration inside infinite loop

['Jakob Borg' via golang-nuts]

On 25 Jan 2023, at 12:26, Shashwat  wrote:
> 
> Is it safe to declare a variable inside an infinite loop ?
> 
> for {
> a := 0
> a += 1
> }
> 
> Won't this cause memory allocation in every iteration ?
> 
> As the declared variables will be allocated memory in the stack and not heap 
> memory, so garbage collector can't clear the allocated memory, and eventually 
> process will be terminated, isn't it?

No. Apart from compiler optimisations, consider that the variable goes out of 
scope at the end of each iteration.

//jb

-- 
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/CE4EFF63-BD16-46F8-96EF-69000F7D9ACD%40kastelo.net.