Failing NumberPlane Constructor options, i.e. x_range and y_range

[robypoteau]

Description of bug / unexpected behavior

When I use the NumberPlace constructor with the x_range and y_range options, those options do not change the NumberPlane dimensions. The default constructor values remain.

Expected behavior

I expected the x_range and y_range to edit the number plane object and the tic placements.

How to reproduce the issue

Code for reproducing the problem

```py from manim import * class GraphSceneExample(Scene): def construct(self): #Create number plane number_plane = NumberPlane( x_range=[-10, 10, 1], y_range=[-10, 10, 1], background_line_style={ "stroke_color": TEAL, "stroke_width": 4, "stroke_opacity": 0.6 } ) self.add(number_plane) dot = Dot([7,4,0]) self.add(dot) ```

Additional media files

Images/GIFs

Logs

Terminal output

``` PASTE HERE OR PROVIDE LINK TO https://pastebin.com/ OR SIMILAR ```

System specifications

System Details

- OS (macOS 10.15.7 (Catalina)): - RAM 16GB: - Python version (3.7.3): - Installed modules (provide output from `pip list`): ``` certifi 2021.5.30 charset-normalizer 2.0.4 click 8.0.1 click-default-group 1.2.2 cloup 0.7.1 colorama 0.4.4 colour 0.1.5 commonmark 0.9.1 Cython 0.29.24 decorator 5.0.9 glcontext 2.3.4 idna 3.2 importlib-metadata 4.6.3 manim 0.9.0 ManimPango 0.3.0 mapbox-earcut 0.12.10 moderngl 5.6.4 moderngl-window 2.4.0 multipledispatch 0.6.0 networkx 2.6.2 numpy 1.21.1 Pillow 8.3.1 pip 21.2.3 pycairo 1.20.1 pydub 0.25.1 pyglet 1.5.18 Pygments 2.9.0 pyobjc-core 7.3 pyobjc-framework-Cocoa 7.3 pyrr 0.10.3 requests 2.26.0 rich 10.7.0 scipy 1.7.1 screeninfo 0.6.7 setuptools 57.4.0 six 1.16.0 tqdm 4.62.0 typing-extensions 3.10.0.0 urllib3 1.26.6 watchdog 2.1.3 wheel 0.37.0 zipp 3.5.0 ```

LaTeX details

+ LaTeX distribution (e.g. TeX Live 2019): + Installed LaTeX packages: too much...

FFMPEG

Output of `ffmpeg -version`: ``` fmpeg version 4.4 Copyright (c) 2000-2021 the FFmpeg developers built with Apple clang version 12.0.0 (clang-1200.0.32.29) configuration: --prefix=/usr/local/Cellar/ffmpeg/4.4_2 --enable-shared --enable-pthreads --enable-version3 --cc=clang --host-cflags= --host-ldflags= --enable-ffplay --enable-gnutls --enable-gpl --enable-libaom --enable-libbluray --enable-libdav1d --enable-libmp3lame --enable-libopus --enable-librav1e --enable-librubberband --enable-libsnappy --enable-libsrt --enable-libtesseract --enable-libtheora --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libxvid --enable-lzma --enable-libfontconfig --enable-libfreetype --enable-frei0r --enable-libass --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libspeex --enable-libsoxr --enable-libzmq --enable-libzimg --disable-libjack --disable-indev=jack --enable-avresample --enable-videotoolbox libavutil 56. 70.100 / 56. 70.100 libavcodec 58.134.100 / 58.134.100 libavformat 58. 76.100 / 58. 76.100 libavdevice 58. 13.100 / 58. 13.100 libavfilter 7.110.100 / 7.110.100 libavresample 4. 0. 0 / 4. 0. 0 libswscale 5. 9.100 / 5. 9.100 libswresample 3. 9.100 / 3. 9.100 libpostproc 55. 9.100 / 55. 9.100 ```

Additional comments

[hydrobeam]

Hello! NumberPlane automatically adjusts based on the range values provided so that each box is a 1x1 square in manim-space. The parameters are in fact doing something, it's just they're extending the range of the plane off-screen. If you'd like to shrink the numberplane down, you'd have to additionally specify x_length/y_length parameters

[WampyCakes]

@hydrobeam that seems unintuitive. I remember having a lot of issues with numberplanes being off screen when I was new to manim and it was not easy to figure out how to fix it (at least back then since there were no docs). Perhaps there should be a parameter defaulted to true on whether to scale the numberplane to show all in screen?

[hydrobeam]

I think this could be mitigated by a better example in the docs 🤔. A solution like that feels a little odd to me.

[WampyCakes]

It feels odd to add a mobject that I have to explicitly make fit in the screen

[AlfaBetaBeta]

I think this could be mitigated by a better example in the docs 🤔. A solution like that feels a little odd to me.

Would this example be suitable? It's a basic scene that I wrote when making sense out of NumberPlane (I tweaked it a little to make it resemble @robypoteau's example).

class NumberPlaneRangeExample(MovingCameraScene):
    def construct(self):
        self.camera.frame.save_state()

        number_plane_default = NumberPlane(axis_config={"include_numbers": True})
        number_plane_custom = NumberPlane(
            x_range=[-18, 18],
            y_range=[-10, 10],
            axis_config={"include_numbers": True}
        )
        number_plane_resized = NumberPlane(
            x_range=[-18, 18],
            y_range=[-10, 10],
            x_length=14.22,
            y_length=8,
            axis_config={"include_numbers": True}
        )
        dot_coords = [10, 7, 0]
        dot = Dot(point=dot_coords)

        self.add(number_plane_default, dot)
        self.play(self.camera.frame.animate.scale(2))
        self.wait()

        self.play(Restore(self.camera.frame))
        self.wait()

        self.remove(number_plane_default)
        self.add(number_plane_custom)
        self.play(self.camera.frame.animate.scale(2))
        self.wait()

        self.play(Restore(self.camera.frame))
        self.wait()

        self.play(AnimationGroup(
            Transform(number_plane_custom, number_plane_resized)),
            dot.animate.move_to(number_plane_resized.coords_to_point(*dot_coords))
        )
        self.wait()

On the other hand, this example mixes NumberPlane with MovingCameraScene, which might be detrimental on a first read, so I'm not sure (the examples in the docs tend to be concise and on point).