34 ms·

Potential of the Julia programming language for high energy physics computing

120 points by npalli 3y ago

booleandilemma 3y ago
Any chance of Julia supplanting Python for scientific computing?
- leephillips 3y ago
  These discussions tend to go in circles because there are several incompatible notions of what “scientific computing” is. The first arena that comes to my mind is very high performance numerical code: simulations of merging galaxies, of the atmosphere, etc. In this arena, there are exactly four languages that have been used at the most demanding level: Fortran, C, C++, and Julia. Python is not on the radar.
  - agoose77 3y ago
    I think this is somewhat restrictive. A significant amount of scientific computing work is done in high-level languages like Python that dispatch to lower-level kernels (like C++, jitted Numba, etc). I wouldn't discount them as "not scientific computing". The jitted kernels really blur the line, of course, because in many cases the jitted code runs in the same environment as the higher-level language.
    - phkahler 3y ago
      In some sense it's not right to claim python is used in those cases. The core libraries are all written in one of the 4 languages GP listed. Python is just the glue, or high level algorithm.
      - SiempreViernes 3y ago
        Sure, but it's a pretty useless sense because it will, among other problems, cause you to answer the question "which language should I teach my undergrads first" completely wrong.
- eigenspace 3y ago
  Depends on what you mean. For me personally as a physicst, Julia supplanted Python like 7 years ago and I haven't looked back. There's a vibrant, active ecosystem of useful open source packages relevant to my needs constantly being developed. I've had zero reason to use python in ages. Other people may have different needs, different experiences, and different organizational or legacy constraints that makes it so that switching from python to julia is just not on the table any time soon. That's fine. Julia and Python continue to both grow in the scientific computing space, and I think Julia is becoming more and more of a known name, and an accepted tool in the scientist's toolkit. It may not be the tool the majority of scientists use any time soon, but that's not really a problem.
- soulbadguy 3y ago
  I think trying to supplant python is the wrong goal, or maybe the wrong frame. Supplanting an already established technology is very hard and depend so many factors that not directly controllable by the julia designer and community. I think focusing on providing significant value to the dev community in a way that's not disruptive to their current workflow is a better metric of success.
- cashsterling 3y ago
  I am not at the numerical programming level of most folks in this thread but have written useful numerical software in Python, Julia, Fortran, Java, C#, C++, and Matlab. My 0.02 is that Julia is awesome... if I was starting a new numerical project from scratch, I'd pick Julia 100% unless there was a very compelling reason to use another language (e.g. to interact with a legacy system). There are some Julia libraries that are so insanely good, like SciML/DiffEq, that I use Julia just to use those libraries (because I'm not smart enough to re-implement that stuff in some other language). That being said, Python has a sufficiently good ecosystem that it's a sane choice for scientific programming where all out speed (or multi-node parallel computing) is not the top priority. Python with Numpy/Numba, RAPIDS and/or JAX can be very fast and it is very easy to write concise and fast programs this way. The code quality of RAPIDS and JAX are very high too and documentation is solid. I'd also offer that Chapel and Rust belong in the "HPC/super-computing capable" pantheon of programming languages.
cozzyd 3y ago
Can you call Julia routines from other languages? Otherwise you sort of have to go all in...
- eigenspace 3y ago
  Yes, julia can be called from other languages rather easily, Julia functions can be exposed and called with a C-like ABI [1], and then there's also various dedicated packages for languages like Python[2], R[3], C++[4], Rust[5] and more to call Julia code. With PackageCompiler.jl [6] you can even make AOT compiled standalone binaries, though these are rather large. They've shrunk a fair amount in recent releases, but they're still a lot of low hanging fruit to make the compiled binaries smaller, and some manual work you can do like removing LLVM and filtering stdlibs when they're not needed. Work is also happening on a more stable / mature system that acts like StaticCompiler.jl [7] except provided by the base language and people who are more experienced in the compiler (i.e. not a janky prototype) [1] https://docs.julialang.org/en/v1/manual/embedding/ https://docs.julialang.org/en/v1/manual/embedding/ [2] https://pypi.org/project/juliacall/ https://pypi.org/project/juliacall/ [3] https://www.rdocumentation.org/packages/JuliaCall/ https://www.rdocumentation.org/packages/JuliaCall/ [4] https://github.com/Clemapfel/jluna https://github.com/Clemapfel/jluna [5] https://github.com/Taaitaaiger/jlrs https://github.com/Taaitaaiger/jlrs [6] https://github.com/JuliaLang/PackageCompiler.jl https://github.com/JuliaLang/PackageCompiler.jl [7] https://github.com/tshort/StaticCompiler.jl https://github.com/tshort/StaticCompiler.jl
  - huijzer 3y ago
    > Yes, julia can be called from other languages rather easily This seems false to me. StaticCompiler.jl [1] puts in their limitations that "GC-tracked allocations and global variables do not work with compile_executable or compile_shlib. This has some interesting consequences, including that all functions within the function you want to compile must either be inlined or return only native types (otherwise Julia would have to allocate a place to put the results, which will fail)." In practice, this means that you can therefore not use the base library in your own programs. PackageCompiler.jl [2] has the same limitations if I'm not mistaken. So then you have to fall back to distributing the Julia "binary" with a full Julia runtime, which is pretty heavy. There are some packages, such as PySR [3], which do this. It seems pretty usable for research I'd say, but difficult to put in production. There is some word going around though that there is an even better static compiler in the making, but as long as that one is not publicly available I'd say that Julia cannot easily be called from other languages. [1]: https://github.com/tshort/StaticCompiler.jl https://github.com/tshort/StaticCompiler.jl [2]: https://github.com/JuliaLang/PackageCompiler.jl https://github.com/JuliaLang/PackageCompiler.jl [3]: https://github.com/MilesCranmer/PySR https://github.com/MilesCranmer/PySR
fnands 3y ago
Cool! Writing math-heavy code in Julia is such a pleasure. C++ is a pain, numpy is alright but Julia just makes sense. I really wish I could use it for my day-job. Back when I was on ATLAS we mostly did things in C++. If I never have to do another matrix multiplication in C++ again it will be too soon.
- sampo 3y ago
  > C++ is a pain Fortran would be less painful than C++, for math-heavy code.
  - fnands 3y ago
    Julia code is actually very Fortran-like (if Fortran was designed in the 21st century). I did some Fortran in undergrad, and while it's pleasant to work with, if you have to do anything beyond numerical calculations you are basically screwed.
  - jampekka 3y ago
    Yes, but Fortran is outright hell outside mathy stuff. C++ has the features as a language to be almost Fortran level pain for math heavy. But the libraries tend to fall short. E.g. Eigen kind of does it, but it will just explode with a thousand line compile error when you least expect it. Also it's missing some quite elemental stuff like ND arrays. And getting code to work across even minor Eigen versions is a crapshoot. Xtensor seems to have some potential, although it was too buggy to use back when I last tried it. However, due to many fundamental design mistakes in C++ I'm not really expecting any code, including math heavy, to be very plesant or productive in it.
    - m_mueller 3y ago
      Why would you need Fortran for anything other than math? To put it differently, what’s the problem with just using 2 languages, e.g. Fortran plus Python with f2py?
      - 3y ago
aborsy 3y ago
Julia is great for numerical simulations. Companies such as Google and Facebook should have supported Julia for machine learning, in my opinion. Numpy is OK, but verbose and a bit of a pain.
- ykonstant 3y ago
  > Companies such as Google and Facebook should have supported Julia for machine learning, in my opinion. Given that ML is becoming so important and Julia has ergonomic handling of numerical code, why don't they explicitly support it? Is it inertia?
  - Joel_Mckay 3y ago
    You didn't look hard enough. ML on CUDA is very much part of Julia already, and Meta seems into that lib as well. =)
    - jjoonathan 3y ago
      Is it good? PyCUDA was so bad (as of 2018) that after 3 major bugfixes from me and no end in sight it still almost sank a major project until I gave up on it and went with native CUDA.
      - empyrrhicist 3y ago
        Anecdotally, the Julia approach certainly seems... nicer via e.g. KernelAbstractions etc. I don't know if the performance/flexibility is quite there vs. native CUDA, but going from zero to GPU kernel programming in Julia is as close to painless as I've ever seen, especially given how modular everything is (for example, you can use OffsetArrays.jl directly in GPU kernel code).
      - Joel_Mckay 3y ago
        "Is it good?" Compared to the CUDA dumpster fire at a cat food factory, it is often trivial and nearly transparent syntax for the users familiar with ML. Really depends on the use-case =) The conventional options are fairly well documented: https://sciml.ai/ https://sciml.ai/ https://fluxml.ai/Flux.jl/stable/gpu/ https://fluxml.ai/Flux.jl/stable/gpu/ https://github.com/SciML/DiffEqFlux.jl https://github.com/SciML/DiffEqFlux.jl https://github.com/alan-turing-institute/MLJ.jl https://github.com/alan-turing-institute/MLJ.jl
coldcache 3y ago
I've been doing economics research in Julia for a couple of months. The scientific community surrounding it is fairly rich, and there's a lot of very well-written packages for performance.
- fnands 3y ago
  In academia it totally makes sense. If you have to do numerical work a d don't have to integrate into some legacy code base it is totally the way to go
daynthelife 3y ago
If it weren’t for the one based indexing, I would use Julia for almost all my math research. Overall it is a very well designed language, and a ton of things just work. But I can’t for the life of me understand how any language designer signed off on one based indexing.
- HappySweeney 3y ago
  Don't all the languages geared towards science and math use 1-based indexing?
- soulbadguy 3y ago
  I think the rational for one based indexing was to be closer to other languages used to numerical computation such as Fortran or Matlab. It's been a long time i have used any language with one based indexing, but i don't remember it being particularly important in my day to day.
- staunton 3y ago
  I've never understood why this bugs people so much. I switch between languages with zero-based and one-based indexing about every hour or so. Never had a problem beyond the usual "off-by-one's" that I do anyway even without switching. You have to keep track of which language you're using anyway to produce correct syntax...
  - j-pb 3y ago
    Julia aims to also be a C-Compatible low-level language with manual memory management in addition to the GC. When building data-structures you're often using small unsigned integers that use the complete value-space, (e.g. u8s and their bitsets in tries, u16s and blocks with that size in sparse vectors). With 1 based indexing, you can't do that anymore without first having to cast the index into the next larger integer, adding 1, and then doing the access, which is a PITA, adds instructions, and messes with prefetching, while you're already working with difficult, hard to read, and heavily optimised stuff.
    - 3y ago
moelf 3y ago
We had our first JuliaHEP workshop this year: https://indico.cern.ch/event/1292759/ https://indico.cern.ch/event/1292759/
- pjmlp 3y ago
  As someone that took part on the early Python courses during the Summer Schools in 2003/4, and was doing CMT build scripts, as Python was slowly being adopted at CERN, it will be interesting to follow how Julia will be picked up.
trostaft 3y ago
I wish the FEM ecosystem was a little more mature in Julia (particularly weak forms, their derivatives, and assembly). I'm confident about rewriting the other pieces of my research, but it took me a long time to be happy with FEniCS, and I'm not entirely sure if going through the same with Gridap is worthwhile. Despite being fairly happy with Python, I've used a lot of Julia before settling into this field and would be happy to use it again.
kloch 3y ago
Physics (and more generally numerical simulations) is the killer app for Julia Language. No other language makes it as easy to work with arbitrary precision math. Whatever precision you need/want, just call setprecision(), Initialize variables/constants as BigInt/BitFloat, then do all your math just like you would in C. Just remember to put the value in quotes when initializing: BigFloat("1.0") NOT BigFloat(1.0). Without quotes it's silently initialized as double precision (!)
- leephillips 3y ago
  I don’t see that: julia> BigFloat(1.0) |> typeof BigFloat
  - eigenspace 3y ago
    The problem isn't the type, it's the bits. If you convert from Float64, you'll get garbage bits once you go past the bits determined by float64: julia> BigFloat(1.1) 1.100000000000000088817841970012523233890533447265625 I'd recommend using the big string macro though isntead of converting explictly from a string: julia> big"1.1" 1.100000000000000000000000000000000000000000000000000000000000000000000000000003
    - leephillips 3y ago
      Oh, I see. Thank you. (And, in Julia’s defense, this is all spelled out in the documentation, immediately accessible from the REPL. I just never read it carefully enough.)
      - kloch 3y ago
        > And, in Julia’s defense, this is all spelled out in the documentation, immediately accessible from the REPL. I just never read it carefully enough. My concern is most physicists won't read that either and may not even notice the loss of precision until it's too late (after a paper has been published).
Alifatisk 3y ago
Okey, I gotta mention this feeling I've had in my chest for a while. A couple of years ago, when I was so faschinated by different programming languages, I stumpled upon Julia. I don't exactly remember how but I think I was scrolling through a list of programming languages that looked interesting so I could write "Hello, world" in it. So I stumpled upon Julia, knowing nothing about it and downloaded it. At the time the language was still very young, but I remember thinking to myself that this language has a lot of potential, it promises something we actually need, like being dynamic yet high performance. I've slowly been following Julias progress overtime and damn, it is growing rapidly and gained a lot of attention! I'm happy because it deserves it. I've been working with Matlab again and I'm thinking about giving Julia another shot, this is also because Apache Octave was a disaster for me. The end.

120 points by npalli 3y ago

booleandilemma 3y ago

Any chance of Julia supplanting Python for scientific computing?

leephillips 3y ago
These discussions tend to go in circles because there are several incompatible notions of what “scientific computing” is. The first arena that comes to my mind is very high performance numerical code: simulations of merging galaxies, of the atmosphere, etc. In this arena, there are exactly four languages that have been used at the most demanding level: Fortran, C, C++, and Julia. Python is not on the radar.
- agoose77 3y ago
  I think this is somewhat restrictive. A significant amount of scientific computing work is done in high-level languages like Python that dispatch to lower-level kernels (like C++, jitted Numba, etc). I wouldn't discount them as "not scientific computing". The jitted kernels really blur the line, of course, because in many cases the jitted code runs in the same environment as the higher-level language.
  - phkahler 3y ago
    In some sense it's not right to claim python is used in those cases. The core libraries are all written in one of the 4 languages GP listed. Python is just the glue, or high level algorithm.
    - SiempreViernes 3y ago
      Sure, but it's a pretty useless sense because it will, among other problems, cause you to answer the question "which language should I teach my undergrads first" completely wrong.
eigenspace 3y ago
Depends on what you mean. For me personally as a physicst, Julia supplanted Python like 7 years ago and I haven't looked back. There's a vibrant, active ecosystem of useful open source packages relevant to my needs constantly being developed. I've had zero reason to use python in ages. Other people may have different needs, different experiences, and different organizational or legacy constraints that makes it so that switching from python to julia is just not on the table any time soon. That's fine. Julia and Python continue to both grow in the scientific computing space, and I think Julia is becoming more and more of a known name, and an accepted tool in the scientist's toolkit. It may not be the tool the majority of scientists use any time soon, but that's not really a problem.
soulbadguy 3y ago
I think trying to supplant python is the wrong goal, or maybe the wrong frame. Supplanting an already established technology is very hard and depend so many factors that not directly controllable by the julia designer and community. I think focusing on providing significant value to the dev community in a way that's not disruptive to their current workflow is a better metric of success.
cashsterling 3y ago
I am not at the numerical programming level of most folks in this thread but have written useful numerical software in Python, Julia, Fortran, Java, C#, C++, and Matlab. My 0.02 is that Julia is awesome... if I was starting a new numerical project from scratch, I'd pick Julia 100% unless there was a very compelling reason to use another language (e.g. to interact with a legacy system). There are some Julia libraries that are so insanely good, like SciML/DiffEq, that I use Julia just to use those libraries (because I'm not smart enough to re-implement that stuff in some other language). That being said, Python has a sufficiently good ecosystem that it's a sane choice for scientific programming where all out speed (or multi-node parallel computing) is not the top priority. Python with Numpy/Numba, RAPIDS and/or JAX can be very fast and it is very easy to write concise and fast programs this way. The code quality of RAPIDS and JAX are very high too and documentation is solid. I'd also offer that Chapel and Rust belong in the "HPC/super-computing capable" pantheon of programming languages.

cozzyd 3y ago

Can you call Julia routines from other languages? Otherwise you sort of have to go all in...

eigenspace 3y ago
Yes, julia can be called from other languages rather easily, Julia functions can be exposed and called with a C-like ABI [1], and then there's also various dedicated packages for languages like Python[2], R[3], C++[4], Rust[5] and more to call Julia code. With PackageCompiler.jl [6] you can even make AOT compiled standalone binaries, though these are rather large. They've shrunk a fair amount in recent releases, but they're still a lot of low hanging fruit to make the compiled binaries smaller, and some manual work you can do like removing LLVM and filtering stdlibs when they're not needed. Work is also happening on a more stable / mature system that acts like StaticCompiler.jl [7] except provided by the base language and people who are more experienced in the compiler (i.e. not a janky prototype) [1] https://docs.julialang.org/en/v1/manual/embedding/ https://docs.julialang.org/en/v1/manual/embedding/ [2] https://pypi.org/project/juliacall/ https://pypi.org/project/juliacall/ [3] https://www.rdocumentation.org/packages/JuliaCall/ https://www.rdocumentation.org/packages/JuliaCall/ [4] https://github.com/Clemapfel/jluna https://github.com/Clemapfel/jluna [5] https://github.com/Taaitaaiger/jlrs https://github.com/Taaitaaiger/jlrs [6] https://github.com/JuliaLang/PackageCompiler.jl https://github.com/JuliaLang/PackageCompiler.jl [7] https://github.com/tshort/StaticCompiler.jl https://github.com/tshort/StaticCompiler.jl
- huijzer 3y ago
  > Yes, julia can be called from other languages rather easily This seems false to me. StaticCompiler.jl [1] puts in their limitations that "GC-tracked allocations and global variables do not work with compile_executable or compile_shlib. This has some interesting consequences, including that all functions within the function you want to compile must either be inlined or return only native types (otherwise Julia would have to allocate a place to put the results, which will fail)." In practice, this means that you can therefore not use the base library in your own programs. PackageCompiler.jl [2] has the same limitations if I'm not mistaken. So then you have to fall back to distributing the Julia "binary" with a full Julia runtime, which is pretty heavy. There are some packages, such as PySR [3], which do this. It seems pretty usable for research I'd say, but difficult to put in production. There is some word going around though that there is an even better static compiler in the making, but as long as that one is not publicly available I'd say that Julia cannot easily be called from other languages. [1]: https://github.com/tshort/StaticCompiler.jl https://github.com/tshort/StaticCompiler.jl [2]: https://github.com/JuliaLang/PackageCompiler.jl https://github.com/JuliaLang/PackageCompiler.jl [3]: https://github.com/MilesCranmer/PySR https://github.com/MilesCranmer/PySR

fnands 3y ago

Cool! Writing math-heavy code in Julia is such a pleasure. C++ is a pain, numpy is alright but Julia just makes sense. I really wish I could use it for my day-job. Back when I was on ATLAS we mostly did things in C++. If I never have to do another matrix multiplication in C++ again it will be too soon.

sampo 3y ago
> C++ is a pain Fortran would be less painful than C++, for math-heavy code.
- fnands 3y ago
  Julia code is actually very Fortran-like (if Fortran was designed in the 21st century). I did some Fortran in undergrad, and while it's pleasant to work with, if you have to do anything beyond numerical calculations you are basically screwed.
- jampekka 3y ago
  Yes, but Fortran is outright hell outside mathy stuff. C++ has the features as a language to be almost Fortran level pain for math heavy. But the libraries tend to fall short. E.g. Eigen kind of does it, but it will just explode with a thousand line compile error when you least expect it. Also it's missing some quite elemental stuff like ND arrays. And getting code to work across even minor Eigen versions is a crapshoot. Xtensor seems to have some potential, although it was too buggy to use back when I last tried it. However, due to many fundamental design mistakes in C++ I'm not really expecting any code, including math heavy, to be very plesant or productive in it.
  - m_mueller 3y ago
    Why would you need Fortran for anything other than math? To put it differently, what’s the problem with just using 2 languages, e.g. Fortran plus Python with f2py?
    - 3y ago

aborsy 3y ago

Julia is great for numerical simulations. Companies such as Google and Facebook should have supported Julia for machine learning, in my opinion. Numpy is OK, but verbose and a bit of a pain.

ykonstant 3y ago
> Companies such as Google and Facebook should have supported Julia for machine learning, in my opinion. Given that ML is becoming so important and Julia has ergonomic handling of numerical code, why don't they explicitly support it? Is it inertia?
- Joel_Mckay 3y ago
  You didn't look hard enough. ML on CUDA is very much part of Julia already, and Meta seems into that lib as well. =)
  - jjoonathan 3y ago
    Is it good? PyCUDA was so bad (as of 2018) that after 3 major bugfixes from me and no end in sight it still almost sank a major project until I gave up on it and went with native CUDA.
    - empyrrhicist 3y ago
      Anecdotally, the Julia approach certainly seems... nicer via e.g. KernelAbstractions etc. I don't know if the performance/flexibility is quite there vs. native CUDA, but going from zero to GPU kernel programming in Julia is as close to painless as I've ever seen, especially given how modular everything is (for example, you can use OffsetArrays.jl directly in GPU kernel code).
    - Joel_Mckay 3y ago
      "Is it good?" Compared to the CUDA dumpster fire at a cat food factory, it is often trivial and nearly transparent syntax for the users familiar with ML. Really depends on the use-case =) The conventional options are fairly well documented: https://sciml.ai/ https://sciml.ai/ https://fluxml.ai/Flux.jl/stable/gpu/ https://fluxml.ai/Flux.jl/stable/gpu/ https://github.com/SciML/DiffEqFlux.jl https://github.com/SciML/DiffEqFlux.jl https://github.com/alan-turing-institute/MLJ.jl https://github.com/alan-turing-institute/MLJ.jl

coldcache 3y ago

I've been doing economics research in Julia for a couple of months. The scientific community surrounding it is fairly rich, and there's a lot of very well-written packages for performance.

fnands 3y ago
In academia it totally makes sense. If you have to do numerical work a d don't have to integrate into some legacy code base it is totally the way to go

daynthelife 3y ago

If it weren’t for the one based indexing, I would use Julia for almost all my math research. Overall it is a very well designed language, and a ton of things just work. But I can’t for the life of me understand how any language designer signed off on one based indexing.

HappySweeney 3y ago
Don't all the languages geared towards science and math use 1-based indexing?
soulbadguy 3y ago
I think the rational for one based indexing was to be closer to other languages used to numerical computation such as Fortran or Matlab. It's been a long time i have used any language with one based indexing, but i don't remember it being particularly important in my day to day.
staunton 3y ago
I've never understood why this bugs people so much. I switch between languages with zero-based and one-based indexing about every hour or so. Never had a problem beyond the usual "off-by-one's" that I do anyway even without switching. You have to keep track of which language you're using anyway to produce correct syntax...
- j-pb 3y ago
  Julia aims to also be a C-Compatible low-level language with manual memory management in addition to the GC. When building data-structures you're often using small unsigned integers that use the complete value-space, (e.g. u8s and their bitsets in tries, u16s and blocks with that size in sparse vectors). With 1 based indexing, you can't do that anymore without first having to cast the index into the next larger integer, adding 1, and then doing the access, which is a PITA, adds instructions, and messes with prefetching, while you're already working with difficult, hard to read, and heavily optimised stuff.
  - 3y ago

moelf 3y ago

We had our first JuliaHEP workshop this year: https://indico.cern.ch/event/1292759/ https://indico.cern.ch/event/1292759/

pjmlp 3y ago
As someone that took part on the early Python courses during the Summer Schools in 2003/4, and was doing CMT build scripts, as Python was slowly being adopted at CERN, it will be interesting to follow how Julia will be picked up.

trostaft 3y ago

I wish the FEM ecosystem was a little more mature in Julia (particularly weak forms, their derivatives, and assembly). I'm confident about rewriting the other pieces of my research, but it took me a long time to be happy with FEniCS, and I'm not entirely sure if going through the same with Gridap is worthwhile. Despite being fairly happy with Python, I've used a lot of Julia before settling into this field and would be happy to use it again.

kloch 3y ago

Physics (and more generally numerical simulations) is the killer app for Julia Language. No other language makes it as easy to work with arbitrary precision math. Whatever precision you need/want, just call setprecision(), Initialize variables/constants as BigInt/BitFloat, then do all your math just like you would in C. Just remember to put the value in quotes when initializing: BigFloat("1.0") NOT BigFloat(1.0). Without quotes it's silently initialized as double precision (!)

leephillips 3y ago
I don’t see that: julia> BigFloat(1.0) |> typeof BigFloat
- eigenspace 3y ago
  The problem isn't the type, it's the bits. If you convert from Float64, you'll get garbage bits once you go past the bits determined by float64: julia> BigFloat(1.1) 1.100000000000000088817841970012523233890533447265625 I'd recommend using the big string macro though isntead of converting explictly from a string: julia> big"1.1" 1.100000000000000000000000000000000000000000000000000000000000000000000000000003
  - leephillips 3y ago
    Oh, I see. Thank you. (And, in Julia’s defense, this is all spelled out in the documentation, immediately accessible from the REPL. I just never read it carefully enough.)
    - kloch 3y ago
      > And, in Julia’s defense, this is all spelled out in the documentation, immediately accessible from the REPL. I just never read it carefully enough. My concern is most physicists won't read that either and may not even notice the loss of precision until it's too late (after a paper has been published).

Alifatisk 3y ago

Okey, I gotta mention this feeling I've had in my chest for a while. A couple of years ago, when I was so faschinated by different programming languages, I stumpled upon Julia. I don't exactly remember how but I think I was scrolling through a list of programming languages that looked interesting so I could write "Hello, world" in it. So I stumpled upon Julia, knowing nothing about it and downloaded it. At the time the language was still very young, but I remember thinking to myself that this language has a lot of potential, it promises something we actually need, like being dynamic yet high performance. I've slowly been following Julias progress overtime and damn, it is growing rapidly and gained a lot of attention! I'm happy because it deserves it. I've been working with Matlab again and I'm thinking about giving Julia another shot, this is also because Apache Octave was a disaster for me. The end.