Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Jupyter, Mathematica, and the Future of the Research Paper

paulromer.net

Post reply on HN
Print view View original

51–60 of 179 posts

Re: Jupyter, Mathematica, and the Future of the Research Paper

#51

Post by lopmotr »

Open source is only great when it exists. For finite element analysis, there are only two generally useful open source products and neither of them has a remotely modern or easy UI. For $10,000 or so, you can get a proprietary one that's fast to use and doesn't have you hitting a brick wall when you find there's some key feature it can't do.

UI is a major failure of open source - it can hardly ever achieve it, at least not well. Most of the popular open source programs have no UI at all.

Re: Jupyter, Mathematica, and the Future of the Research Paper

#52

Post by sago »

Jupyter is an amazing and useful piece of software. I agree that its openness is important, that its flexibility in producing content is excellent, and that it deserves to be the current hotness. But I'm afraid

> Now, Jupyter is the unambiguous technical leader.

is pure fantasy, imho. SymPy is still two decades behind Mathematica in large swathes of symbolic computation.

It may be that, for the things that the author wanted to do, the Python libraries were a good fit (it seems he was working on NLP), but overall, I just don't see it.

Re: Jupyter, Mathematica, and the Future of the Research Paper

#53

Post by BlackFingolfin »

gaius wrote: post #41
askvictor wrote: post #27

Earlier quoted context omitted.

While I totally hear you regarding the pain of python modules (particularly on Windows), the point of python 'distributions' like anaconda and canopy is to bring the kitchen sink along, kind of like mathematica. The problem with Mathematica from a science point of view is that, being closed source, means you can't independently ensure the calculations are happening correctly. To be replicable, science involving data…

The problem with Mathematica from a science point of view is that, being closed source, means you can't independently ensure the calculations are happening correctly Have there been any high profile failures root-caused to Mathematica (or MATLAB or any similar product) getting its sums wrong? I can find any news stories etc. Plenty of serious calculations were and are done on “closed source” HP and TI calculators too…

I am not sure that there are/were "high profile failures", but serious bugs for sure, not just in Mathmetica but also in the calculators you mention; ser eg here: https://mathoverflow.net/questions/11517/computer-algebra-er...

Now being open source does not prevent such errors. What I think is far more important here is open issue tracking: companies like Wolfram may not be exactly eager to let you know that there are serious bugs in their products (and what they are) unless they must. Being able to fix the bug yourself can of course be a real perk for some user's, but realistically, it's out if question for most.

Re: Jupyter, Mathematica, and the Future of the Research Paper

#54

Post by emj »

tincholio wrote: post #50
sanderjd wrote: post #47

Earlier quoted context omitted.

I used MathCAD in physics and chemistry classes in college. I frequently wonder what happened to it, because I share your perception that while Jupyter is very nifty, it is hamstrung by the limitations of the browser environment. I'm waiting impatiently for the coming revolution of non-web collaborative internet-connected rich client applications.

As a die-hard Emacs user, I think that org-mode with it's org-babel capabilities blows Jupyter out of the water, and it produces much better, readable output. You can use it with pretty much any language, and combine several languages in a single document without any issues. Besides all this, it's just a plain text format, and you can extract all the code into proper source files for later offline use, too ('tangling…

Requiring basic Emacs knowledge is just too much, just looking through the features of org-babel I can't really find anything that makes it better suited. Except not having to bother with a webbrowser, that is a nice plus, but hardly important for most people I work with.

Re: Jupyter, Mathematica, and the Future of the Research Paper

#55

Post by rotorblade »

dahart wrote: post #8

> The tie-breaker is social, not technical. The tie-breaker is financial. Jupyter is winning because it's free, not because it's social. It becomes social because of widespread adoption, and it get's widespread adoption because it's free. I love Jupyter, love love love. But there's a lot of hyperbole and opinion here. Mathematica is just a for-profit business, it's that simple. And it wouldn't be fair to deny the exa…

>> The tie-breaker is social, not technical.

> The tie-breaker is financial. Jupyter is winning because it's free [...]

It is a bit more nuanced than that. Personally I do not pay from Mathematica usage, so why do I like Jupyter more?

The Mathematica notebook interface is horrible. You may go "oh, neat" the first few times you try it then, at least I, get more and more frustrated on all the idiotic issues

* Indentation/text-wrapping. Write a long line that starts wrapping, it gives it a little indentation to signify this, an your next line that you have indented is slightly more indented, but it is really hard to see, so you have no idea of where your line-breaks are.

* Brackets. "[" are used for function calls and for part-specification. The number of square brackets in your expression makes it necessary hard to read when it is big enough.

* Jumping text. The notebook interface does not have the "auto-complete brackets" (maybe v11 does), so you add your first, all the text in the Cell gets reformatted and you have to find the fucking place you wanted end the bracket. This is akin to working with images in MS Word.

* Exporting. The notation is just ugly, fine, that is personal, but "Sin[]" as "sin()"... ok. Ah, good, it has a "Copy as Latex", nice... "Sin[]" -> "\text{Sin}[]". Really? Who in the world uses "\text{Sin}" for the sine-function and square brackets for function-calls when typesetting maths in Latex?

It is just a complete nightmare to try and incorporate these things into your workflow, at least for me.

Jupyter just behaves as you'd expect. Just that it is so much smoother to work with wins. For me, I do symbolic calculations, SymPy can do some things much easier than Mathematica, but a lot of things it can't or you have to work some more to get going. That Jupyter allows you not to have an aneurysm every day at work, which makes you actually wanna spend the extra time working it out.

Re: Jupyter, Mathematica, and the Future of the Research Paper

#56

Post by jhbadger »

ChrisRackauckas wrote: post #17

>Which reminds me. If you are a Julia enthusiast, how do you suppose the investors in this new language plan to make their big score? This is a weird jab at Julia. Open source software is woefully underfunded. Julia Computing was founded in the wake of Heartbleed where people learned that open source needs some kind of funding to keep developers alive (example article: https://arstechnica.com/information-technology/2…

Also the idea of companies making money off of open source isn't new or nefarious and often helps people who aren't even their customer. Red Hat is the classic example, and many organizations use CentOS, a distribution based off of Red Hat's distro without paying Red Hat anything. And in scientific computing there's RStudio, which makes a great open source IDE for R besides offering prducts and services for sale.

Re: Jupyter, Mathematica, and the Future of the Research Paper

#57

Post by s3s1212312 »

cs702 wrote: post #2

This is spot-on: "Membership in an open source community is like membership in the community of science. There is a straightforward process for finding a true answer to any question. People disagree in public conversations. They must explain clearly and listen to those who response with equal clarity. Members of the community pay more attention to those who have been right in the past, and to those who enhance their…

This is true for the working part of the open source community. It is not true for the promoters, profiteurs, conference whores, all of whom attach their own names to something they did not write.

And the latter people are often best known.

Re: Jupyter, Mathematica, and the Future of the Research Paper

#58

Post by improbable22 »

rotorblade wrote: post #55
dahart wrote: post #8

> The tie-breaker is social, not technical. The tie-breaker is financial. Jupyter is winning because it's free, not because it's social. It becomes social because of widespread adoption, and it get's widespread adoption because it's free. I love Jupyter, love love love. But there's a lot of hyperbole and opinion here. Mathematica is just a for-profit business, it's that simple. And it wouldn't be fair to deny the exa…

>> The tie-breaker is social, not technical. > The tie-breaker is financial. Jupyter is winning because it's free [...] It is a bit more nuanced than that. Personally I do not pay from Mathematica usage, so why do I like Jupyter more? The Mathematica notebook interface is horrible . You may go "oh, neat" the first few times you try it then, at least I, get more and more frustrated on all the idiotic issues * Indentat…

These are matters of taste, I use both & find Mathematica's notebooks much better than Jupyter. Editing text in a web browser is just painfully clumsy, and plain text is not great for reading mathematical expressions of any length. But obviously it depends what you're doing with it.

You complain about Sin[] but not about ugly things like np.sin()? Also I think you're looking for

    Sin[θ] //TraditionalForm //TeXForm

Re: Jupyter, Mathematica, and the Future of the Research Paper

#59

Post by rotorblade »

improbable22 wrote: post #58
rotorblade wrote: post #55

Earlier quoted context omitted.

>> The tie-breaker is social, not technical. > The tie-breaker is financial. Jupyter is winning because it's free [...] It is a bit more nuanced than that. Personally I do not pay from Mathematica usage, so why do I like Jupyter more? The Mathematica notebook interface is horrible . You may go "oh, neat" the first few times you try it then, at least I, get more and more frustrated on all the idiotic issues * Indentat…

These are matters of taste, I use both & find Mathematica's notebooks much better than Jupyter. Editing text in a web browser is just painfully clumsy, and plain text is not great for reading mathematical expressions of any length. But obviously it depends what you're doing with it. You complain about Sin[] but not about ugly things like np.sin()? Also I think you're looking for Sin[θ] //TraditionalForm //TeXForm

Yeah, I guess that is fair. It might just be that it is more or less the furthest way from how I like to work as I can imagine.

> Sin[θ] //TraditionalForm //TeXForm

Did not know of this. Thanks!

Re: Jupyter, Mathematica, and the Future of the Research Paper

#60

Post by fdej »

gaius wrote: post #41
askvictor wrote: post #27

Earlier quoted context omitted.

While I totally hear you regarding the pain of python modules (particularly on Windows), the point of python 'distributions' like anaconda and canopy is to bring the kitchen sink along, kind of like mathematica. The problem with Mathematica from a science point of view is that, being closed source, means you can't independently ensure the calculations are happening correctly. To be replicable, science involving data…

The problem with Mathematica from a science point of view is that, being closed source, means you can't independently ensure the calculations are happening correctly Have there been any high profile failures root-caused to Mathematica (or MATLAB or any similar product) getting its sums wrong? I can find any news stories etc. Plenty of serious calculations were and are done on “closed source” HP and TI calculators too…

Here is an article from a couple of years ago about how one group of mathematicians were misled by (and had to spend some time tracking down) a bug in Mathematica determinant evaluation: http://www.ams.org/notices/201410/rnoti-p1249.pdf
Post reply on HN