This question already has answers here:
How can I check if code is executed in the IPython notebook?
(16 answers)
Closed 6 years ago.
I'm writing some software that creates matplotlib plots of simulation data. Since these plotting routines are often running in a headless environment, I've chosen to use the matplotlib object oriented interface explicitly assign canvases to figures only just before they are saved. This means I cannot use pylab or pyplot based solutions for this issue.
I've added some special sauce so the plots show up inline either by invoking a display method on the plot object or by invoking __repr__. However, the check I'm doing to determine if a user is running under IPython (checking for "__IPYTHON__" in dir(__builtin__)) cannot discriminate whether the user is in a notebook or just a regular terminal session where inline figures won't work.
Is there some way to programatically check whether a code snippet has been executed in a notebook, qt console, or terminal IPython session? Am I doing something silly here - I haven't looked too closely at the display semantics so perhaps I'm ignorant about some portion of the IPython internal API that will take care of this for me.
Answerd many time : No you cant.
How can I check if code is executed in the IPython notebook?
Same kernel can be connected to notebook, qtconsole and terminal at the same time, even to many at once.
Your question is like a TV star asking "how can I know if the person watching me on tv is male of female? ". It does not make sens.
Don't invoke _repr_*_ yourself. Try to import display, make it no-op if import fail.
that should be sufficient to both in python or IPython not.
Better return object instead of displaying. The display hook will work by itself in IPython if the object has a _repr_png_ or equivalent.
Related
My colab kernel restarted itself for unknown reasons when I tried to plot my data with matplotlib plot (right before which, I had successfully plotted histograms for the same data). The colab gave a notification to check the runtime logs, which are as follows. I don't see any apparent reason why this happened.
I just found out why it was happening. The colab runtime RAM was being consumed entirely while running through the last cell. It happened when I used the matplotlib plot, but when I used matplotlib histograms, it turned out just fine. Histograms are probably lighter when you have a high precision float values.
I repeated with multiple trials between the two methods, and got the same result every time.
I am working with a program that is meant to take a few parameters and use a genetic algorithm to optimize a five-layer mirror coating according to said parameters. Just before termination, the program is meant to display a plot of the theoretical reflectivity of the mirror over a range of wavelengths. The last four lines of the program are:
plot(lam,rf)
xlabel("wavelength(AA)")
ylabel("reflectivity")
title("Broadband reflectivity")
When I run this from the command line (sudo julia Broadband.jl), the plot never displays; I put a few println() functions in there and there is output just before and just after plot(lam,rf).
Perhaps the strangest part is the fact that I copied the entirety of the code, pasted it to the terminal and ran it directly from julia (julia> [ENTIRETY OF .JL FILE]), and the plot displayed. Does anyone know what I'm missing?
Please note the following from the PyPlot README:
If you use PyPlot from an interactive Julia prompt, such as the Julia command-line prompt or an IJulia notebook, then plots appear immediately after a plotting function (plot etc.) is evaluated.
However, if you use PyPlot from a Julia script that is run non-interactively (e.g. julia myscript.jl), then Matplotlib is executed in non-interactive mode: a plot window is not opened until you run show() (equivalent to plt.show() in the Python examples).
Thus, you must call show() for your plot to display when run from the command line.
I started using Julia to analyse some data, which works perfect.
I also use PyPlot / Matplotlib for plotting, which I got working as well.
Now, these plots need to find their way into my latex document, which I want to achieve using the matplotlib pgf backend. It also works, but I really have no idea how to pass arguments to
mpl.rcParams.update(parameters)
Is there somebody skilled out there in the Julia community who can tell me how to achieve this?
EDIT2:
short update on the issue: Setting rc-options work by setting them in the following way:
PyPlot.matplotlib[:rc]("text", usetex=true) # here: allow tex rendering
I have recently begun learning to use Julia, converting over from Matlab/Octave. I decided that the best way to get some experience was to convert some code I was already working on i Octave - a Newton solver for a complicated multidimensional problem. I have been able to convert the code over successfully (and with noticeable speedup relative to Octave, without devectorisation or other performance-based changes), with only one issue arising.
I have chosen to use PyPlot for plotting, due to its similarity to Matlab/Octave's plotting functionality. However, there is some behaviour from PyPlot that is undesired. I use the plotting function to display the current state of the vector I am trying to get to zero (using the Newton solver part of the code), so that I can see what it is doing, and adjust the code to try to improve this behaviour. I input the number of Newton steps to take before the code stops, and then I can make adjustments or re-issue the command to continue attempting to converge.
I have the code set up to plot the current state every few steps, so that I can, for instance, have the code take 200 steps, but show me the status after every 10 steps. In Octave, this works perfectly, providing me with up-to-date information - should the behaviour of the code not be desirable, I can quickly cancel the code with Ctrl-C (this part works in Julia, too).
However, Julia does not produce or update the plots when the plot() command is used; instead, it produces the plot, or updates it if the plot window is already open, only when the code finishes. This entirely defeats the purpose of the intermittent plotting within the code. Once the code has completed, the plot is correctly generated, so I know that the plot() command itself is being used correctly.
I have tried adding either draw() or show() immediately after the plot command. I have also tried display(gcf()). None of these have modified the result. I have confirmed that isinteractive() outputs "true". I have also tried turning interactivity off (ioff()) and switching whether to use the python or julia backend (pygui(true) and pygui(false)), with no effect on this behaviour.
Have I missed something? Is there another package or option that needs to be set in order to force PyPlot to generate the current plot immediately, rather than waiting until Julia finishes its current code run to generate the plot?
Or is it perhaps possible that scope is causing a problem, here, as the intermittent plotting happens inside a while loop?
I am using xubuntu 12.10 with Julia 0.2.1.
PyPlot defaults to this behavior in the REPL. To make it show the plots as they are plotted type ion(). To turn it off again type ioff().
ion() is only effective for the current season so if you want it to stay on across sessions just add it to your .juliarc file.
If you're using iPython ion() will plot to a new window but ioff() will plot inline.
I'm using Django's django-extensions to run an iPython notebook with access to the Django models (as detailed here http://andrewbrookins.com/python/using-ipython-notebook-with-django/). When I make model queries, the notebook shows the underlying SQL queries executed by Django, like so:
Can I hide this SQL? It's so voluminous it makes the display unusable at times.
with recent version, you could use
%%capture variable
the code
to capture stdout and stderr into a variable
adding the --no-stdout flag
%%capture --no-stdout variable
wont capture stdout, thus displaying it.
Also, please, IPython (upper casse I) preferably,
ipython accepted, but try to avoid iPython