profile
viewpoint

gopherdata/gophernotes 2362

The Go kernel for Jupyter notebooks and nteract.

cznic/ql 1321

github.com/cznic/ql has moved to modernc.org/ql

neugram/ng 918

scripting language integrated with Go

go-sqlite/sqlite3 93

pure-Go sqlite3 file reader

cbourjau/alice-rs 69

Analyze the public data from the CERN base ALICE collaboration with Rust

FairRootGroup/FairRoot 40

C++ simulation, reconstruction and analysis framework for particle physics experiments

gopherdata/mybinder-go 19

Go on Jupyter via http://mybinder.org

go-boostio/boostio 5

Serialization library compatible with C++ Boost Serialization

go-daq/tdaq 3

tdaq: a toolkit for building DAQ systems

sbinet/atl-cvmfs 3

atl-cvmfs is a simple command to create, install and remove athena package tarballs off a CVMFs repository

delete branch sbinet-hep/hep

delete branch : ci-travis-mail

delete time in a day

push eventsbinet-hep/hep

Sebastien Binet

commit sha 4e246266edf139a2f6102c0e25ba3dc819208526

ci: make travis ci less verbose

view details

push time in a day

PR merged go-hep/hep

ci: make travis ci less verbose
+0 -2

1 comment

1 changed file

sbinet

pr closed time in a day

push eventgo-hep/hep

Sebastien Binet

commit sha 4e246266edf139a2f6102c0e25ba3dc819208526

ci: make travis ci less verbose

view details

push time in a day

PR opened go-hep/hep

ci: make travis ci less verbose
+0 -2

0 comment

1 changed file

pr created time in a day

create barnchsbinet-hep/hep

branch : ci-travis-mail

created branch time in a day

issue commentgonum/gonum

plot matrix as bitmap

Yes. See for example: https://godoc.org/gonum.org/v1/plot/plotter#example-HeatMap

(Also: this kind of query is best directed at the gonum-dev mailing list)

guanicoe

comment created time in 2 days

issue commentgo-hep/hep

groot/rtree: speed lost between two commits

'Reader.Formula' documentation probably deserves a bit of polishing.

rmadar

comment created time in 2 days

issue commentgo-hep/hep

groot/rtree: speed lost between two commits

We could indeed have a 'rtree.Formula' interface that would be the same then the 'rfunc.Formula' one without the 'Bind' method. And have the 'rtree.Reader' return the 'rtree.Formula' one.

rmadar

comment created time in 2 days

issue commentgo-hep/hep

groot/rtree: speed lost between two commits

yes, that's (more or less, see: here and there) how originally the rfunc.New function was implemented. I believe it's fine to push it into user code: they know the set of functions they want to be able to use for a given workload.

I'd argue doing the same thing in rtree/rfunc makes less sense b/c: where do you draw the line b/w what is sensible for application-A and what's sensible for application-B. you'd end up with the whole set of possible functions/formulae.

that said, in a couple of years, it might be a completely moot point if generics are accepted into Go, in some form, such as: https://github.com/golang/go/issues/15292

rmadar

comment created time in 2 days

push eventsbinet-hep/hep

Sebastien Binet

commit sha 384b9ef333aad490169ebe8fc3651ee8ed9ad9a8

groot/rdict: add generation of streamer info checksum

view details

Sebastien Binet

commit sha 3b702ec41bed5d81419567ae889c82226e121b50

groot: implement new rfunc-gen default type name convention Updates #737.

view details

push time in 3 days

delete branch sbinet-hep/hep

delete branch : rdict-chksum

delete time in 3 days

issue commentgo-hep/hep

groot/{cmd/root-gen-rfunc,rtree/rfunc}: additional rfuncs, rfunc name cosmetics

done. I had to change a bit what I initially proposed because of possible collisions between slices and uint16. see:

  • https://godoc.org/go-hep.org/x/hep/groot/rtree/rfunc#FuncF32F32F32ToF32
  • https://godoc.org/go-hep.org/x/hep/groot/rtree/rfunc#FuncF32sToF64s
sbinet

comment created time in 3 days

delete branch sbinet-hep/hep

delete branch : issue-737

delete time in 3 days

push eventgo-hep/hep

Sebastien Binet

commit sha 3b702ec41bed5d81419567ae889c82226e121b50

groot: implement new rfunc-gen default type name convention Updates #737.

view details

push time in 3 days

PR merged go-hep/hep

groot/rdict: add generation of streamer info checksum
+208 -1

1 comment

2 changed files

sbinet

pr closed time in 3 days

PR merged go-hep/hep

groot: implement new rfunc-gen default type name convention

Updates #737.

+1822 -1209

1 comment

25 changed files

sbinet

pr closed time in 3 days

push eventgo-hep/hep

Sebastien Binet

commit sha 384b9ef333aad490169ebe8fc3651ee8ed9ad9a8

groot/rdict: add generation of streamer info checksum

view details

Sebastien Binet

commit sha 95039a377b212c5e771bf4b04a77804cd00edbb4

groot: implement new rfunc-gen default type name convention Updates #737.

view details

Sebastien Binet

commit sha 020b43efe1b68462225d82cfc3f72e9f7d78efd9

PS1

view details

push time in 3 days

push eventsbinet-hep/hep

Sebastien Binet

commit sha 020b43efe1b68462225d82cfc3f72e9f7d78efd9

PS1

view details

push time in 3 days

startedaaronjanse/3mux

started time in 3 days

PR opened go-hep/hep

groot: implement new rfunc-gen default type name convention

Updates #737.

+1612 -1001

0 comment

24 changed files

pr created time in 3 days

create barnchsbinet-hep/hep

branch : issue-737

created branch time in 3 days

issue commentgo-hep/hep

groot/{cmd/root-gen-rfunc,rtree/rfunc}: additional rfuncs, rfunc name cosmetics

I'll send a PR tackling the (default) naming convention change.

sbinet

comment created time in 3 days

issue commentgo-hep/hep

groot/rtree: speed lost between two commits

I don't think we can re-introduce the automatic loading of the non-reflect-based formula funcs w/o preventing the Go compiler/linker from removing the unused formula-funcs types from the final binary.

for the moment, I suspect helping the linker won't save much, but it's the kind of slippery slope that get's you to "bloated C++" :P

at the moment, we have:

form, err := rfunc.NewGenericFormula(branches, fct)
form := rfunc.NewF64Ar1(branches, func(x float64)float64{ return 2*x} )

so, save the naming convention that would need to be implemented, I think we're (almost already) inline with what you've proposed above.

rmadar

comment created time in 3 days

PR opened go-hep/hep

groot/rdict: add generation of streamer info checksum
+208 -1

0 comment

2 changed files

pr created time in 3 days

push eventsbinet-hep/hep

Sebastien Binet

commit sha 384b9ef333aad490169ebe8fc3651ee8ed9ad9a8

groot/rdict: add generation of streamer info checksum

view details

push time in 3 days

create barnchsbinet-hep/hep

branch : rdict-chksum

created branch time in 3 days

issue commentgo-hep/hep

groot/rtree: speed lost between two commits

perhaps keeping the rtree.Reader.FormulaFunc(...) API was a mistake? should we just drop it and ask users to replace:

form, err := r.FormulaFunc(branches, usrFct)

with:

form, err := rfunc.NewGenericFormula(branches, usrFct)
check(err)
form, err = r.Formula(form)
check(err)

? this would perhaps reduce confusion down the line...

rmadar

comment created time in 3 days

issue commentgo-hep/hep

groot/rtree: speed lost between two commits

here is the beginning of a fix (on your side):

diff --git a/ana/treefunc.go b/ana/treefunc.go
index 6ed2dad..ac868fc 100644
--- a/ana/treefunc.go
+++ b/ana/treefunc.go
@@ -154,7 +154,20 @@ func NewVarI32s(v string) TreeFunc {
 // FormulaFrom returns the rtree.FormulaFunc function associated
 // to the TreeFunc f, from a give rtree.Reader r.
 func (f *TreeFunc) FormulaFrom(r *rtree.Reader) rfunc.Formula {
-       ff, err := r.FormulaFunc(f.VarsName, f.Fct)
+       var (
+               ff  rfunc.Formula
+               err error
+       )
+       switch fct := f.Fct.(type) {
+       case func(float64) float64:
+               ff = rfunc.NewF64Ar1(f.VarsName, fct)
+       default:
+               ff, err = rfunc.NewGenericFormula(f.VarsName, f.Fct)
+               if err != nil {
+                       log.Fatalf("could not create formula func: %+v", err)
+               }
+       }
+       ff, err = r.Formula(ff)
        if err != nil {
                log.Fatalf("could not create formulaFunc: %+v", err)
        }

(perhaps a better fix would to add a private field to TreeFunc that's a rfunc.Formula, left nil for non-specialized formulae, instead of re-doing the type-switch...)

rmadar

comment created time in 3 days

issue commentgo-hep/hep

groot/rtree: speed lost between two commits

yep:

2020/05/29 15:34:03 warning: slow formula for []string{"truth_dphi_ll"} (fct=func(float64) float64)
2020/05/29 15:34:03 warning: slow formula for []string{} (fct=func() float64)
2020/05/29 15:34:03 warning: slow formula for []string{} (fct=func() bool)
rmadar

comment created time in 3 days

issue commentgo-hep/hep

groot/rtree: speed lost between two commits

isn't this because of the use of a non-specialized formula-func?

* 4d1e5f08 groot/rtree: fix handling of rleaf-element with a "This" StreamerSTL
* 5e981213 groot/rtree: add formula test for slices
* 351d7f17 groot: add support for extracting copyright year from code templates
* c771d0c9 groot/cmd/root-gen-rfunc: first import
* e1d8871a hplot: fix HStack band display logic

between e1d8871a and 4d1e5f08, there's c771d0c9 that removed the automagic registration of formula-funcs.

rmadar

comment created time in 3 days

push eventsbinet-hep/hep

Sebastien Binet

commit sha 4d1e5f0811fbe1bbe4b07393e4c70822c14c026d

groot/rtree: fix handling of rleaf-element with a "This" StreamerSTL Fixes go-hep/hep#736.

view details

push time in 3 days

issue commentgo-hep/hep

groot/rtree: speed lost between two commits

I was perusing your code and indeed noticed the variables you declare aren't bound to []T... ok. back to a nice debugging session :)

rmadar

comment created time in 3 days

issue commentgo-hep/hep

groot/rtree: speed lost between two commits

probably it's because before the (real) fix for #736, rtree.Reader wasn't actually reading all the data. depending on the number of branches that had the same problem than in #736 and their size, ... it could explain the effect you see.

rmadar

comment created time in 3 days

CommitCommentEvent
CommitCommentEvent
CommitCommentEvent

delete branch sbinet-hep/hep

delete branch : issue-736

delete time in 3 days

PR merged go-hep/hep

groot/rtree: fix handling of rleaf-element with a "This" StreamerSTL

Fixes go-hep/hep#736.

+80 -2

1 comment

5 changed files

sbinet

pr closed time in 3 days

issue closedgo-hep/hep

groot/rtree: problem reading slices with formula?

I am trying to read a slice, i.e a vector<float> branch with a rtree.Formula, using something like:

VarsName := []string{"hits"}, 
Fct :=: func(xs []float32) []float64 {
    res := make([]float64, len(xs))
    for i, x := range xs { res[i] = float64(x)  } 
    return res
}
f := r.FormulaFunc(VarsName, Fct)
getSlice := f.Func().(func() []float64)

In the event loop, getSlice() returns always an empty slice. Given it's quite late, it's not impossible I am doing a mistake ... But I wanted to know if there would be a reason why reading slices can fail with rtree.Formula.

closed time in 3 days

rmadar

push eventgo-hep/hep

Sebastien Binet

commit sha 4d1e5f0811fbe1bbe4b07393e4c70822c14c026d

groot/rtree: fix handling of rleaf-element with a "This" StreamerSTL Fixes go-hep/hep#736.

view details

push time in 3 days

issue closedgo-hep/hep

groot/rtree: problem reading slices with formula?

I am trying to read a slice, i.e a vector<float> branch with a rtree.Formula, using something like:

VarsName := []string{"hits"}, 
Fct :=: func(xs []float32) []float64 {
    res := make([]float64, len(xs))
    for i, x := range xs { res[i] = float64(x)  } 
    return res
}
f := r.FormulaFunc(VarsName, Fct)
getSlice := f.Func().(func() []float64)

In the event loop, getSlice() returns always an empty slice. Given it's quite late, it's not impossible I am doing a mistake ... But I wanted to know if there would be a reason why reading slices can fail with rtree.Formula.

closed time in 3 days

rmadar

issue commentgo-hep/hep

groot/rtree: problem reading slices with formula?

thanks for the input file. see: https://github.com/go-hep/hep/pull/739.

rmadar

comment created time in 3 days

PR opened go-hep/hep

groot/rtree: fix handling of rleaf-element with a "This" StreamerSTL

Fixes go-hep/hep#736.

+80 -2

0 comment

5 changed files

pr created time in 3 days

create barnchsbinet-hep/hep

branch : issue-736

created branch time in 3 days

issue commentgo-hep/hep

groot/rtree: problem reading slices with formula?

ok, thanks.

as soon as I finished my "entretien annuel", I'll commit the fix:

$> root-dump
2020/05/29 10:02:22 evt[0]: [24.412797927856445 23.422243118286133 23.469839096069336 24.914079666137695 23.116113662719727 23.13003921508789 23.375518798828125 23.057828903198242 25.786481857299805 22.85857582092285] | [12.206399 11.711122 11.73492 12.45704 11.558057 11.56502 11.687759 11.528914 12.893241 11.429288] n=10
2020/05/29 10:02:22 evt[1]: [23.436037063598633 25.970693588256836 24.462419509887695 23.650163650512695 24.811952590942383 30.67894172668457 23.878101348876953 25.87006378173828 27.323381423950195 23.939083099365234 23.786226272583008] | [11.718019 12.985347 12.23121 11.825082 12.405976 15.339471 11.939051 12.935032 13.661691 11.969542 11.893113] n=11
2020/05/29 10:02:22 evt[2]: [24.462657928466797 24.429365158081055 24.389734268188477 24.492183685302734 23.71849822998047 38.71868133544922 24.310426712036133 24.45393180847168 -9.42474365234375 23.703657150268555 23.761384963989258 23.640995025634766 23.732669830322266 26.57146644592285 -9.294095039367676] | [12.231329 12.214683 12.194867 12.246092 11.859249 19.35934 12.155213 12.226966 -4.712372 11.851829 11.8806925 11.8204975 11.866335 13.285733 -4.6470475] n=15
2020/05/29 10:02:22 evt[3]: [22.6768798828125 23.451208114624023 25.548261642456055 24.217187881469727 24.384170532226562 24.241182327270508 24.25889015197754 24.366979598999023 23.182010650634766] | [11.33844 11.725604 12.774131 12.108594 12.192085 12.120591 12.129445 12.18349 11.591005] n=9
2020/05/29 10:02:22 evt[4]: [24.312828063964844 25.28243064880371 23.35763168334961 24.659414291381836 23.15633773803711 25.025495529174805 23.680923461914062 28.24120330810547 23.750375747680664 28.266529083251953 28.211824417114258 29.810104370117188 23.62776756286621] | [12.156414 12.641215 11.678816 12.329707 11.578169 12.512748 11.840462 14.120602 11.875188 14.133265 14.105912 14.905052 11.813884] n=13

rmadar

comment created time in 3 days

issue commentgo-hep/hep

groot/rtree: problem reading slices with formula?

(and -if possible- only with the hits_n and hits_time_mc branches?)

rmadar

comment created time in 3 days

issue commentgo-hep/hep

groot/rtree: problem reading slices with formula?

I think I have a fix.

could you reproduce that file (but with only, say, 5 events, so its size is about ~200k ?) I'd like to put it into my regression test suite.

rmadar

comment created time in 3 days

issue commentgo-hep/hep

groot/rtree: problem reading slices with formula?

ok: that's because, in your file, the "hits_mc" leaf reports no associated "LeafCount" (ie: the size of the slice/vector is 0. ROOT's TTree::Scan does display data, so there must be something missing on groot's side.)

rmadar

comment created time in 4 days

push eventgo-hep/hep

Sebastien Binet

commit sha 5e981213fd6e4997c3f1bef90b35c3936192fded

groot/rtree: add formula test for slices Fixes #736.

view details

push time in 4 days

push eventsbinet-hep/hep

Sebastien Binet

commit sha 5e981213fd6e4997c3f1bef90b35c3936192fded

groot/rtree: add formula test for slices Fixes #736.

view details

push time in 4 days

delete branch sbinet-hep/hep

delete branch : issue-736

delete time in 4 days

PR merged go-hep/hep

groot/rtree: add formula test for slices

Fixes #736.

+15 -1

1 comment

1 changed file

sbinet

pr closed time in 4 days

issue commentgo-hep/hep

groot/rtree: problem reading slices with formula?

must be something else. I tried:

package main

import (
	"flag"
	"log"

	"go-hep.org/x/hep/groot"
	"go-hep.org/x/hep/groot/rtree"
)

func main() {
	flag.Parse()
	fname := flag.Arg(0)
	tname := "tree"

	f, err := groot.Open(fname)
	if err != nil {
		panic(err)
	}
	defer f.Close()

	o, err := f.Get(tname)
	if err != nil {
		panic(err)
	}
	t := o.(rtree.Tree)

	r, err := rtree.NewReader(t, []rtree.ReadVar{})
	if err != nil {
		panic(err)
	}
	defer r.Close()

	form, err := r.FormulaFunc(
		[]string{"SliF32"},
		func(xs []float32) []float64 {
			o := make([]float64, len(xs))
			for i, v := range xs {
				o[i] = float64(2 * v)
			}
			return o
		},
	)
	if err != nil {
		panic(err)
	}

	fct := form.Func().(func() []float64)

	err = r.Read(func(ctx rtree.RCtx) error {
		log.Printf("evt[%d]: %v", ctx.Entry, fct())
		return nil
	})
	if err != nil {
		panic(err)
	}
}

and then:

$> go run ./main.go /path/to/go-hep.org/x/hep/groot/testdata/leaves.root
2020/05/28 16:51:09 evt[0]: []
2020/05/28 16:51:09 evt[1]: [2]
2020/05/28 16:51:09 evt[2]: [4 4]
2020/05/28 16:51:09 evt[3]: [6 6 6]
2020/05/28 16:51:09 evt[4]: [8 8 8 8]
2020/05/28 16:51:09 evt[5]: [10 10 10 10 10]
2020/05/28 16:51:09 evt[6]: [12 12 12 12 12 12]
2020/05/28 16:51:09 evt[7]: [14 14 14 14 14 14 14]
2020/05/28 16:51:09 evt[8]: [16 16 16 16 16 16 16 16]
2020/05/28 16:51:09 evt[9]: [18 18 18 18 18 18 18 18 18]
rmadar

comment created time in 4 days

issue commentgo-hep/hep

groot/rtree: problem reading slices with formula?

ok. so, you pass a nil slice of rtree.ReadVar to rtree.NewReader ? I suspect the issue comes from the way the ReadVar gets its Value.

rmadar

comment created time in 4 days

issue commentrmadar/tree-gonalyzer

Consider having an interface for basic types of TreeFunc

I am not sure one can achieve this kind of API with the current Go language:

f1 := ana.NewCutBool("branchBool") // f.Fct returns a bool
v1 := treeFunc.GetFunc(r)          // Returning a func() bool

f2 := ana.NewVarBool("branchBool") // f.Fct returns a float64 for plotting
v2 := treeFunc.GetFunc(r)          // Returning a func() float64

Go, unlike e.g. C++ or Python, doesn't have covariant return: the ability to define an interface:

type Value interface {}
type Getter interface {
    Get() Value
}

and have other types T1 and T2 implement Getter while returning different types:

type T1 int
type T2 float64
func (t T1) Get() int     { return int(t) }     // does NOT implement Getter
func (t T2) Get() float64 { return float64(t) } // does NOT implement Getter

func (t T1) Get() Value { return t } // OK. but then, users need to type-assert
func (t T2) Get() Value { return t } // OK. but then, users need to type-assert

I guess the only way to have something that implements an interface (or has the same API) and deals with different types (w/o the need to type-assert afterwards) would be:

func (tf TreeFunc) GetFunc(r *rtree.Reader, fct interface{}) {
    rv := reflect.ValueOf(fct).Elem() // pointer-to-fct
    rv.Set(reflect.ValueOf(tf.FormulaFrom(r).Func())) // basically: *fct = r.formula.Func()
}

func foo() {
    var fct func() float64
    treeFunc.GetFunc(r, &fct)
}
rmadar

comment created time in 4 days

CommitCommentEvent

issue commentgo-hep/hep

groot/rtree: problem reading slices with formula?

hum... I've added a test for that: https://github.com/go-hep/hep/pull/738

it's working (locally, at least, let's see what the CI pipeline says). so it might be something on your end.

how do you create the rtree.ReadVar that will be bound to the "hits" leaf?

rmadar

comment created time in 4 days

PR opened go-hep/hep

groot/rtree: add formula test for slices

Fixes #736.

+15 -1

0 comment

1 changed file

pr created time in 4 days

create barnchsbinet-hep/hep

branch : issue-736

created branch time in 4 days

issue commentgo-zeromq/zmq4

Close on ipc:// cause unix socket be removed

you're right. the rationale for doing like so was: "who creates, cleans up". but it shouldn't prevent the valid use case you describe.

do you want to send a PR?

egorse

comment created time in 4 days

delete branch go-hep/groot-bench

delete branch : split-read-cms

delete time in 4 days

push eventgo-hep/groot-bench

Sebastien Binet

commit sha e5ad5433777fbf06a5128b833dd5e0e7b75336fd

all: split read-cms into read-cms-sca and read-cms-ana Fixes #2.

view details

push time in 4 days

push eventgo-hep/groot-bench

Sebastien Binet

commit sha e5ad5433777fbf06a5128b833dd5e0e7b75336fd

all: split read-cms into read-cms-sca and read-cms-ana Fixes #2.

view details

push time in 4 days

issue closedgo-hep/groot-bench

odd result

ReadCMS/ROOT-TreeBranch/Zlib-8     37.5s ± 1%
ReadCMS/ROOT-TreeReader/Zlib-8     26.1s ± 3%

This result is hard to understand. TTreeReader introduced extra feature and thus extra cost and cannot/should-not be faster than direct access. Do you understand what is unusual here?

closed time in 4 days

pcanal

push eventgo-hep/groot-bench

Sebastien Binet

commit sha 5f22859abeca7d9f1d446763aecf10267b1d2caa

PS3

view details

push time in 4 days

push eventgo-hep/groot-bench

Sebastien Binet

commit sha 13c53131d757e7f09968c9b77a1a634d0980446d

PS2

view details

push time in 4 days

push eventgo-hep/groot-bench

Sebastien Binet

commit sha 3db5dfcf6772913cc093e41ff374c1c38509ce24

PS1

view details

push time in 4 days

create barnchgo-hep/groot-bench

branch : split-read-cms

created branch time in 4 days

issue commentgo-hep/hep

groot/{cmd/root-gen-rfunc,rtree/rfunc}: additional rfuncs, rfunc name cosmetics

Do you want to give it a stab? (At least the list of functions you'd like to add. The naming convention also if you want)

sbinet

comment created time in 4 days

issue commentgo-hep/hep

groot/{cmd/root-gen-rfunc,rtree/rfunc}: additional rfuncs, rfunc name cosmetics

I would like to know: is it somehow "expensive" to generate many pre-defined functions or not?

with the new scheme (ie: sans the automagical registration of pre-defined formulae), it's less expansive. e.g.:

$> ll go-hep.org/x/hep/groot/rtree/rfunc.a 
-rw-r--r-- 1 binet binet 1.4M May 28 08:50 go-hep.org/x/hep/groot/rtree/rfunc.a

$> ll go-hep.org/x/hep/groot/rtree.a 
-rw-r--r-- 1 binet binet 3.7M May 28 08:50 go-hep.org/x/hep/groot/rtree.a

of course, some balance and restrain have to be applied: we don't want to bloat too much that little rfunc package :)

But I think we might want to tune the naming convention to make appear input type/multiplicity and output type

yeah. the naming/mangling scheme could be improved, indeed. what about:

  • func(float64)float64 -> FuncDtoD
  • func(x1,x2 float64) float64 -> FuncDDtoD
  • func(int32,float32,bool) float64 -> FuncIFBtoD (well, the root-gen-rfunc tool allows users to specify the output name as they wish)
  1. Other types to float64 conversion func(float32) float64 func(int) float64 func(int32) float64 func(int64) float64

I am ok with adding those to rfunc, except for func(int)float64. int shouldn't be stored in a rtree.Tree, so I don't see much value in having that one generated. (branches/leaves are always sized types)

  1. "Multi-branches" cuts

same comment wrt int. how much arity would you want: 2,3,4,5 ? 10? let's start with 5?

  1. Slice manipulations

same comment wrt int as <input>. also, for func([]<input>, int) float64, where there's the same argument.

sbinet

comment created time in 4 days

pull request commentgo-hep/hep

groot/cmd/root-gen-rfunc: first import

let's move the discussion over there: https://github.com/go-hep/hep/issues/737

sbinet

comment created time in 4 days

issue openedgo-hep/hep

groot/{cmd/root-gen-rfunc,rtree/rfunc}: additional rfuncs, rfunc name cosmetics

raised in https://github.com/go-hep/hep/pull/734#issuecomment-634926739 by @rmadar:


Thanks a lot for this, this is really super useful! I would like to propose few signatures/types that I personally find useful (feel free to tell me if this is too specific). But before:

  1. I would like to know: is it somehow "expensive" to generate many pre-defined functions or not?
  2. It would be nice to have the list of implemented type/signatures in the doc. Right now, I see something like this: image But I think we might want to tune the naming convention to make appear input type/multiplicity and output type. Why not something like: In<T1>Ar<N1><T2>Ar<N2>...Out<T1>Ar<N1><T2>Ar<N2>. For func(in32, float64, float64) bool, it would look like InI32Ar1F64Ar1F64Ar1OutB ... ok maybe not so readable (it would be better with _ in this case ;-) )!

Wish-list and motivation

My strategy is to work only with float64 (for values) and bool (for cuts) as output types, to avoid too much combination. Enable pre-defined functions for slices would be also nice. Here is the (first) full wish-list, organized by goals:

1. Other types to float64 conversion

  • func(float32) float64
  • func(int) float64
  • func(int32) float64
  • func(int64) float64

2. "Multi-branches" cuts (I guess it's fair to let the "mixed" signatures to the user)

  • func(int) bool + arrities
  • func(int32) bool + arrities
  • func(float32) bool + arrities
  • func(float64) bool + arrities

3. Slice manipulations (both for reducing operation and element operation)

  • func([]<input>) []float64
  • func([]<input>) float64
  • func([]<input>, int) float64 (where <input> can be int, int32, int64, float32 or float64)

created time in 4 days

pull request commentgonum/gonum

float: Function KahanSum for Kahan's compensated summation algorithm.

could you add the result of the benchmark (for Sum and KahanSum) to the commit message? so we'd get a sense of the added cost and a point of reference for later.

(would be great to pass it through benchcmp or at least benchstat)

romanwerpachowski

comment created time in 4 days

issue closedgo-hep/hep

Codecov migration to marketplace app

Hi, Tom from Codecov here.

We noticed that you are using Codecov with fairly high frequency, and we’re so excited to see that! However, because you are not using our app, you may have experienced issues with uploading reports or viewing coverage information. This is due to rate-limiting issues from GitHub.

In order to prevent any future outages, we ask that you move over to our GitHub app integration.

The process is extremely simple and shouldn’t require more than a few clicks, and you should not expect any downtime. By moving to our app, you will no longer need an admin or separate account to manage the relationship with GitHub as the team bot.

Let me know if you have any questions, or if I can help at all with this process.

closed time in 5 days

thomasrockhu

issue commentgo-hep/hep

Codecov migration to marketplace app

done. (I think).

thanks for letting us know.

thomasrockhu

comment created time in 5 days

issue commentrmadar/tree-gonalyzer

Considering a support TTreeFiend?

no, the automagical registration of the rfunc concrete types. (yes, I probably replied on the wrong thread...)

rmadar

comment created time in 5 days

delete branch sbinet-hep/hep

delete branch : issue-729

delete time in 5 days

push eventsbinet-hep/hep

Sebastien Binet

commit sha c771d0c9b5e8d601c1ae5909ddc5c6dcc119ba6d

groot/cmd/root-gen-rfunc: first import This CL adds a new command to automatically generate the rfunc.Formula implementation corresponding to a func signature (or a function in a package (ex: math.Abs)). This CL also drops the automagical registration of rfunc.Formula implementations from the rfunc package (as it would prevent the linker from applying dead code elimination). Fixes #729.

view details

Sebastien Binet

commit sha 351d7f1793557910105cfd2136fc3a69a92de356

groot: add support for extracting copyright year from code templates

view details

push time in 5 days

PR merged go-hep/hep

groot/cmd/root-gen-rfunc: first import

This CL adds a new command to automatically generate the rfunc.Formula implementation corresponding to a func signature (or a function in a package (ex: math.Abs)).

This CL also drops the automagical registration of rfunc.Formula implementations from the rfunc package (as it would prevent the linker from applying dead code elimination).

Fixes #729.

+4531 -12508

1 comment

47 changed files

sbinet

pr closed time in 5 days

push eventgo-hep/hep

Sebastien Binet

commit sha c771d0c9b5e8d601c1ae5909ddc5c6dcc119ba6d

groot/cmd/root-gen-rfunc: first import This CL adds a new command to automatically generate the rfunc.Formula implementation corresponding to a func signature (or a function in a package (ex: math.Abs)). This CL also drops the automagical registration of rfunc.Formula implementations from the rfunc package (as it would prevent the linker from applying dead code elimination). Fixes #729.

view details

Sebastien Binet

commit sha 351d7f1793557910105cfd2136fc3a69a92de356

groot: add support for extracting copyright year from code templates

view details

push time in 5 days

issue closedgo-hep/hep

groot/rtree/rfunc: consider using go/types to generate rfunc.Formula implementations

right now, we use a ad hoc type (Func) to gather facts about the Formula implementation to generate (input types, output types, arity, etc...)

we could in fact generate the code from a go/types.Func value. we could also perhaps expose a little command, taking a func signature as input, to generate the Formula implementation.

e.g.:

$> gen-rfunc-formula -pkg mypkg 'func(int32, float32, string) float64'

or, directly pointing the tool at the function to be wrapped:

$> gen-rfunc-formula -func 'example.com/mypkg.MyFunc'
  • [ ] use go/types to generate code
  • [ ] export a generation command

closed time in 5 days

sbinet

delete branch go-hep/groot-bench

delete branch : use-setbr

delete time in 5 days

push eventsbinet-hep/hep

Sebastien Binet

commit sha c771d0c9b5e8d601c1ae5909ddc5c6dcc119ba6d

groot/cmd/root-gen-rfunc: first import This CL adds a new command to automatically generate the rfunc.Formula implementation corresponding to a func signature (or a function in a package (ex: math.Abs)). This CL also drops the automagical registration of rfunc.Formula implementations from the rfunc package (as it would prevent the linker from applying dead code elimination). Fixes #729.

view details

Sebastien Binet

commit sha 351d7f1793557910105cfd2136fc3a69a92de356

groot: add support for extracting copyright year from code templates

view details

push time in 5 days

push eventsbinet-hep/hep

Sebastien Binet

commit sha 00104caf5c48ba3fee74cf732685eb99e7df0adb

groot: add support for extracting copyright year from code templates

view details

push time in 5 days

push eventsbinet-hep/hep

Sebastien Binet

commit sha ccf8e425cf30db0fccf7b9c4811517dab9dd0c80

PS3

view details

push time in 5 days

issue commentgo-hep/groot-bench

odd result

nope. ATM, groot doesn't do lazy-loading as TreeReader or RDF do.

I'll split that benchmark b/w one that reads all the branches that are never empty (ie: all scalars) and one that computes some pt-sum (or something).

pcanal

comment created time in 5 days

push eventsbinet-hep/hep

Sebastien Binet

commit sha 7fc2807c193fe7acc2a65bc156d891cc765fd322

PS2

view details

push time in 5 days

push eventsbinet-hep/hep

Sebastien Binet

commit sha 1a9f315f93868542aef94cf2eae5abdfa188546c

PS1

view details

push time in 5 days

issue commentgo-hep/hep

groot/rtree: idea to improve FormulaFunc in most usual cases

cool. yeah, see, the automagical thingy is already proven a bit treacherous. I've removed it in https://github.com/go-hep/hep/pull/734

please comment on that PR for signatures to be added.

rmadar

comment created time in 5 days

PR opened go-hep/hep

groot/cmd/root-gen-rfunc: first import

This CL adds a new command to automatically generate the rfunc.Formula implementation corresponding to a func signature (or a function in a package (ex: math.Abs)).

This CL also drops the automagical registration of rfunc.Formula implementations from the rfunc package (as it would prevent the linker from applying dead code elimination).

Fixes #729.

+3949 -12492

0 comment

40 changed files

pr created time in 5 days

create barnchsbinet-hep/hep

branch : issue-729

created branch time in 5 days

pull request commentgo-hep/groot-bench

Switch from adding new branch to reading branch

yep, that has improved performances.

pcanal

comment created time in 5 days

issue commentgo-hep/groot-bench

odd result

yes, groot is reading all the branches. rtree.NewReadVars(tree) returns the complete set of "read-vars" associated to the given tree:

  • https://godoc.org/go-hep.org/x/hep/groot/rtree#NewReadVars

one possible reason for TreeReader being faster in ReadCMS is that I don't explicitly read the leaves if nMuon or nElecton <= 0. whereas, I suspect, in the TreeBranch case, even though the associated leaves will return empty for those events, the I/O layer will still be queried.

would tha make sense?

pcanal

comment created time in 5 days

push eventgo-hep/groot-bench

Sebastien Binet

commit sha dc5a277558bb8fe3901c931190e03d6228ad7c30

all: update ReadScalars results w/ SetBranch

view details

push time in 5 days

pull request commentgo-hep/groot-bench

Switch from adding new branch to reading branch

thanks. apologies for not noticing this earlier. (I was also doing this in my use-setbr branch...)

pcanal

comment created time in 5 days

push eventgo-hep/groot-bench

Sebastien Binet

commit sha c48c0dc6198d884b4a61476e63b19e4604ef87c9

cxx-root: use SetBranchAddress

view details

Sebastien Binet

commit sha 49c3d5bb65d0f7687302e2d087c1a11b54576c5b

all: update ReadCMS results w/ SetBranch

view details

push time in 5 days

more