7 ms·

Gosl – Go scientific library

125 points by wener 10y ago

howeman 10y ago
Wow! That's a ton of stuff. I wish you were working with us at gonum. Can we work together?
- saturn_vk 10y ago
  Is there a reason why every component of gonum is scattered across different repositories. For me, it makes it extremely hard to browse through the stuff and try to find anything that might be useful to me.
  - Dawny33 10y ago
    I find it quite legit. Having a singe repo would hinder progress as more and more implementations are added. Even JuliaStats followed a similar distribution (https://github.com/JuliaStats https://github.com/JuliaStats), and it looks neat and organized.
    - ngrilly 10y ago
      > Having a singe repo would hinder progress as more and more implementations are added. Why?
      - Taek 10y ago
        You're more likely to touch more files if they are all in the same repository. All of the issues are going to be in the same issue tracker (tags can help, but only if you know how to use them well, and that causes overhead for the maintainers), and all of the Pull Requests are going to notify everyone who is watching the repository, whether it's relevant to the part you care about or not. There are clear drawbacks, but there are clear advantages as well.
  - howeman 10y ago
    In the beginning we were still trying to figure out what we wanted. There was a lot of really free-form changes, and it was easier to keep those sweeping changes isolated from one another. We're planning to do a couple breaking changes at once at some point, and one of those is likely moving everything into a single repo.
gtani 10y ago
Wow, that's a lot of good work. I asked recently about go wrappers for the Cuda Runtime or Driver API's and didn't get much response, I don't see a lot happening with openCL either, is there anything like that in the prospects? https://news.ycombinator.com/item?id=12528206 https://news.ycombinator.com/item?id=12528206
IndianAstronaut 10y ago
The excitement and libraries around Go remind me of Python around 2009.
- coldtea 10y ago
  So, like that totally irrelevant time for Python when nothing special was going on? (Edit: not that Python was itself irrelevant, but 2009 was an irrelevant time for Python, when nothing special news/projects/etc wise for Python. I've been using the language since 1998, and the most "hyped" period was in the early 00s. Mid 00's Ruby/Rails caught on).
  - deleted 10y ago
    [deleted]
  - IndianAstronaut 10y ago
    This was around when Numpy and Scipy were taking off. Pandas, scikit learn, theano, started development soon after.
    - coldtea 10y ago
      That was more of a slow adoption and consolidation that some dramatic spike. Numpy (renamed as such around 2006) has been around for like 20 years, and has been quite popular in the noughties too for those doing numeric stuff in Python.
joelthelion 10y ago
Not sure Go is such a great fit for scientific computing. On the one hand, with garbage collection and other things, it won't be as fast as C++. On the other hand, it's less flexible than Python. That said, it's always useful to have a good scientific library in every language.
- theparanoid 10y ago
  Lacking SSE2/4 is a big factor. The gonum packages use assembly in performance critical sections for this reason.
- pjmlp 10y ago
  > it won't be as fast as C++. People used to say the same of C++ against C and Pascal compilers. Where would C++ compilers be now, if C++ compiler vendors had given up?
  - joelthelion 10y ago
    I don't think getting performance on par with C or C++ is even among the design goals of Go, but I could be wrong. Within one order of magnitude? Sure. But not on par.
    - pjmlp 10y ago
      Anyone is free to implement a compiler for Go. Who knows what the goals of this person might be.
  - baldfat 10y ago
    The issue was when those statements were made computers were super slow. This was where FORTRAN became king of scientific computing.
    - pjmlp 10y ago
      Those were the 50 and 60's, C was yet to be invented and only became competitive against Fortran compilers after restrict was added (C99) and the special scientific extensions from the ANSI working group for numerical computing. Should C compiler vendors also given up against Fortran compilers?
pm90 10y ago
While this looks like great stuff and there is no way I will discourage anyone from developing tools for scientific computing in any programming language, the vast majority of users of these tools IMO are scientists and engineers who are not programmers. Or to put it another way, most of them don't have a degree in CS, they are usually Mathematicians, Physicists etc. When I hung out in that community about 3 years ago, there was already a wholesale movement going on in moving from MATLAB and/or Fortran to Python... and I don't think the vast majority of that community (which is generally conservative when it comes to tooling) will adopt yet another tool unless it offers some significant benefit. (MATLAB was easy to write and use but proprietary. Python was easier and free. Both make use of high performance libraries written in C/Fortran).
- gautamdivgi 10y ago
  Yup. I'm one of those people. Well, partially at least. I do a lot of distributed computing. But my PhD was in a statistical area. I used Octave for a while (matlab clone). But then as my data sets got larger and I mean really large (non-linear equation solving on 11m points on my puny desktop), I went full force on Python (NumPy, SciPy, Matplotlib). The reason - its is super easily scriptable, the libraries are great and easy to use and python allows me to use multi-processor capabilities to distribute my work to all my cpu cores. Keep in mind I could have used GSL. But Numpy/Scipy & matplotlib were just faster and more productive for me. That being said, I'd rather have one source of truth - i.e. GSL and have this be a wrapper around it as opposed to re-creating all the logic. Either way - its a fantastic effort. If at anytime I create systems that need numerical computation (as opposed to the hacks that I did for my thesis) I will definitely look into this.

125 points by wener 10y ago

howeman 10y ago

Wow! That's a ton of stuff. I wish you were working with us at gonum. Can we work together?

saturn_vk 10y ago
Is there a reason why every component of gonum is scattered across different repositories. For me, it makes it extremely hard to browse through the stuff and try to find anything that might be useful to me.
- Dawny33 10y ago
  I find it quite legit. Having a singe repo would hinder progress as more and more implementations are added. Even JuliaStats followed a similar distribution (https://github.com/JuliaStats https://github.com/JuliaStats), and it looks neat and organized.
  - ngrilly 10y ago
    > Having a singe repo would hinder progress as more and more implementations are added. Why?
    - Taek 10y ago
      You're more likely to touch more files if they are all in the same repository. All of the issues are going to be in the same issue tracker (tags can help, but only if you know how to use them well, and that causes overhead for the maintainers), and all of the Pull Requests are going to notify everyone who is watching the repository, whether it's relevant to the part you care about or not. There are clear drawbacks, but there are clear advantages as well.
- howeman 10y ago
  In the beginning we were still trying to figure out what we wanted. There was a lot of really free-form changes, and it was easier to keep those sweeping changes isolated from one another. We're planning to do a couple breaking changes at once at some point, and one of those is likely moving everything into a single repo.

gtani 10y ago

Wow, that's a lot of good work. I asked recently about go wrappers for the Cuda Runtime or Driver API's and didn't get much response, I don't see a lot happening with openCL either, is there anything like that in the prospects? https://news.ycombinator.com/item?id=12528206 https://news.ycombinator.com/item?id=12528206

IndianAstronaut 10y ago

The excitement and libraries around Go remind me of Python around 2009.

coldtea 10y ago
So, like that totally irrelevant time for Python when nothing special was going on? (Edit: not that Python was itself irrelevant, but 2009 was an irrelevant time for Python, when nothing special news/projects/etc wise for Python. I've been using the language since 1998, and the most "hyped" period was in the early 00s. Mid 00's Ruby/Rails caught on).
- deleted 10y ago
  [deleted]
- IndianAstronaut 10y ago
  This was around when Numpy and Scipy were taking off. Pandas, scikit learn, theano, started development soon after.
  - coldtea 10y ago
    That was more of a slow adoption and consolidation that some dramatic spike. Numpy (renamed as such around 2006) has been around for like 20 years, and has been quite popular in the noughties too for those doing numeric stuff in Python.

joelthelion 10y ago

Not sure Go is such a great fit for scientific computing. On the one hand, with garbage collection and other things, it won't be as fast as C++. On the other hand, it's less flexible than Python. That said, it's always useful to have a good scientific library in every language.

theparanoid 10y ago
Lacking SSE2/4 is a big factor. The gonum packages use assembly in performance critical sections for this reason.
pjmlp 10y ago
> it won't be as fast as C++. People used to say the same of C++ against C and Pascal compilers. Where would C++ compilers be now, if C++ compiler vendors had given up?
- joelthelion 10y ago
  I don't think getting performance on par with C or C++ is even among the design goals of Go, but I could be wrong. Within one order of magnitude? Sure. But not on par.
  - pjmlp 10y ago
    Anyone is free to implement a compiler for Go. Who knows what the goals of this person might be.
- baldfat 10y ago
  The issue was when those statements were made computers were super slow. This was where FORTRAN became king of scientific computing.
  - pjmlp 10y ago
    Those were the 50 and 60's, C was yet to be invented and only became competitive against Fortran compilers after restrict was added (C99) and the special scientific extensions from the ANSI working group for numerical computing. Should C compiler vendors also given up against Fortran compilers?

pm90 10y ago

While this looks like great stuff and there is no way I will discourage anyone from developing tools for scientific computing in any programming language, the vast majority of users of these tools IMO are scientists and engineers who are not programmers. Or to put it another way, most of them don't have a degree in CS, they are usually Mathematicians, Physicists etc. When I hung out in that community about 3 years ago, there was already a wholesale movement going on in moving from MATLAB and/or Fortran to Python... and I don't think the vast majority of that community (which is generally conservative when it comes to tooling) will adopt yet another tool unless it offers some significant benefit. (MATLAB was easy to write and use but proprietary. Python was easier and free. Both make use of high performance libraries written in C/Fortran).

gautamdivgi 10y ago
Yup. I'm one of those people. Well, partially at least. I do a lot of distributed computing. But my PhD was in a statistical area. I used Octave for a while (matlab clone). But then as my data sets got larger and I mean really large (non-linear equation solving on 11m points on my puny desktop), I went full force on Python (NumPy, SciPy, Matplotlib). The reason - its is super easily scriptable, the libraries are great and easy to use and python allows me to use multi-processor capabilities to distribute my work to all my cpu cores. Keep in mind I could have used GSL. But Numpy/Scipy & matplotlib were just faster and more productive for me. That being said, I'd rather have one source of truth - i.e. GSL and have this be a wrapper around it as opposed to re-creating all the logic. Either way - its a fantastic effort. If at anytime I create systems that need numerical computation (as opposed to the hacks that I did for my thesis) I will definitely look into this.