Thanks for the clarification Robert. In many cases, when building ML models, panicking is fine. But in some, it is not, specially if running some type of server, that will handle different models, or with various shapes of inputs (e.g. images in different sizes and formats, some may lead to unexpected invalid combinations, that cannot crash a server).
Now using a DSL and go generate seems not ergonomic ? I understand it wouldn't play well with IDEs (auto-complete, info about the parameters of function one is calling, etc.), and other various checks we get for granted. Or am I missing something? Care to give a small example of what you envision ? Notice these math functions are inter-spaced with normal Go code. Some recent example code here <https://github.com/gomlx/gomlx/blob/main/examples/oxfordflowers102/diffusion/diffusion.go> (an example diffusion model, that generates flower images <https://github.com/gomlx/gomlx/blob/main/examples/oxfordflowers102/OxfordFlowers102_Diffusion.ipynb>) for those curious. On Monday, June 19, 2023 at 6:36:28 AM UTC+2 Robert Engels wrote: > What I was suggesting was a far narrower scope. I can see how go’s error > handling makes writing composable math functions more difficult (although I > would think these would panic not return an error - so then it is trivial). > > If they do need to return errors then using a DSL for the equations and go > generate you don’t really care how much boilerplate code there is - you > don’t read or edit it. > > On Jun 18, 2023, at 3:10 PM, Jan Pfeifer <pfe...@gmail.com> wrote: > > > > A DSL + code generator is a longer discussion. But I'm not sure I'm > getting the scope of your suggestion right: > > If you refer to having a full ML language DSL and a > generator/AOT(ahead-of-time) compiler: folks have tried it before -- see > the Swift ML effort by Chris Lattner, now leading Mojo in Modular AI. I > don't know the detailed story there, but I thought hard about this (having > a separate ML language and generator) before I started the GoMLX project. > But from what I can imagine some of the shapes (and hyperparameters) that > need checking often are only known at runtime. Also for development and > debugging it complicates things: it's super nice to have a full language > (Go) in parallel to constructing the graph. > > If you are referring to a DSL and code generator for error handling only: > I'm not sure it would work well because it requires an extra step when > developing ... it is just not as convenient / portable -- for instance for > IDEs; also I'm often coding in a Jupyter Notebook using GoNB > <https://github.com/janpfeifer/gonb>, which would also need > modifications. Better if there was some form of support for the language. > I'm hoping some error handling proposal would cover this use case. > > > On Sun, Jun 18, 2023 at 5:11 PM Robert Engels <ren...@ix.netcom.com> > wrote: > >> Seems the easiest way to address that is with a DSL and a code >> generator. >> >> On Jun 18, 2023, at 9:47 AM, Jan Pfeifer <pfe...@gmail.com> wrote: >> >> >> hi Shulhan, I see your points, thanks for the reply. Let me comment on >> them below: >> >> On Sat, Jun 17, 2023 at 9:21 AM Shulhan <m.sh...@gmail.com> wrote: >> >>> Hi Jan, thanks for response. >>> >>> On Mon, 5 Jun 2023 01:06:37 -0700 (PDT) >>> Jan <pfe...@gmail.com> wrote: >>> >>> > Repeating Justin's consideration: one of my (and from colleagues I >>> > discuss the topic with) major issues with current error handling is >>> > the repetition of identical code. Your proposal still requires `when >>> > err handle ...` at every statement. >>> >>> Yes, correct. >>> The idea is not to minimise repetition on error handling statement, the >>> "if err != nil", but to minimise repetitive error handling body by >>> grouping it into single handle based on the context of error. >>> >> >> Oh, I see. I have to say I wish one didn't need to do the `if err != nil` >> all the time either, when the handling is the same :) But if that is your >> proposal it makes sense. >> >> > It also doesn't allow for nested >>> > call of functions that return errors -- e.g: `f(g(h(x)))`, where `h`, >>> > `g`, and `f` can return errors (all presumably handled the same way). >>> > >>> >>> I am not sure I understand this, but should not each function handle it >>> on its own? >>> Or should not `f` being called if `g` return an error? >>> If its later, yes, it does not allow for nested handling of error. >>> >> >> Sorry I was not clear. What I mean is, with current error handling would >> be written like: >> >> hValue, err := h(x) >> if err != nil {...} >> gValue, err := g(hValue) >> if err != nil {...} >> fValue, err := f(gValue) >> if err != nil {...} >> >> Where all of the `if err` are identical. >> >> Let me provide a more concrete example: I'm working on an ML framework ( >> github.com/gomlx/gomlx), and I'm writing computational graphs (that get >> just-in-time compiled for speed/GPU support) like: >> >> func EuclideanDistance(x, y *Node) *Node { >> return Sqrt(ReduceAllSum(Square(Sub(x, y)))) >> } >> >> Where each of these functions could return an error (if shapes are >> incompatible). If an error is raised (they hold a stack trace), I want them >> simply propagated upwards. Error handling in the middle of these math >> expressions (some are larger) get in the way of the math being expressed. >> >> cheers >> Jan >> >> >> >> >> -- >> 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...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/CAE%3D7LsUQfPLP1w0s9EN3XZSsoproEStkQHRb-s8pcdTgmpbzTw%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/golang-nuts/CAE%3D7LsUQfPLP1w0s9EN3XZSsoproEStkQHRb-s8pcdTgmpbzTw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> -- > 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...@googlegroups.com. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/CAE%3D7LsVD7Nf3%2B-dtrtSPxKjstimrczis%2BEhbWYT5Wasix3zaEg%40mail.gmail.com > > <https://groups.google.com/d/msgid/golang-nuts/CAE%3D7LsVD7Nf3%2B-dtrtSPxKjstimrczis%2BEhbWYT5Wasix3zaEg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > -- 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/3a788583-9ab5-420b-887e-c7eadae6bd1an%40googlegroups.com.
