ManimCommunity
V0.18.1 NumberLine's number_to_point() is broken when using `add_tip`
Description of bug / unexpected behavior
the method .number_to_point() does not provide the correct position in scene coordinates
Expected behavior
...well, it should provide the correct location along the numberline
How to reproduce the issue
Code for reproducing the problem
class group2(Scene):
def construct(self):
axes = NumberLine(x_range=[-5,5.2,1]).add_numbers().add_tip(tip_length=0.5,tip_width=0.1)
t = [MathTex("h_{i}") for i in range(1,11)]
self.add(axes)
for i in range(1,10):
self.add(t[i].next_to(axes.n2p(i-6),DOWN,buff=0.5))
self.add(Dot().move_to(axes.n2p(i-6)))
Without the added tip, the positions are correct
class group2(Scene):
def construct(self):
axes = NumberLine(
x_range=[-5,5.2,1]).add_numbers()
t = [MathTex("h_{i}") for i in range(1,11)]
self.add(axes)
for i in range(1,10):
self.add(t[i].next_to(axes.n2p(i-6),DOWN,buff=0.5))
self.add(Dot().move_to(axes.n2p(i-6)))
Also adding the tip from the start works
class group2(Scene):
def construct(self):
axes = NumberLine(
x_range=[-5,5.5,1],
include_tip=True,
).add_numbers()
t = [MathTex("h_{i}") for i in range(1,11)]
self.add(axes)
for i in range(1,10):
self.add(t[i].next_to(axes.n2p(i-6),DOWN,buff=0.5))
self.add(Dot().move_to(axes.n2p(i-6)))
Additional media files
Images/GIFs
System specifications
System Details
- OS (with version, e.g., Windows 10 v2004 or macOS 10.15 (Catalina)): Windows 10 64 bit
- Python version (
python/py/python3 --version): 3.11.6
Additional comments
The problem only arises when later adding a tip to the NumberLine() object. Scaling of both tipped and untipped nmberlines works as expected
class nlineScaling(Scene):
def construct(self):
nline1 = NumberLine(
x_range=[0,10,1],
length=8,
font_size=16,
label_direction=UP,
).add_numbers().to_corner(UL)
dot1 = Dot(nline1.n2p(5),color=RED)
self.add(nline1, dot1)
nline2 = nline1.copy().scale(1.5).next_to(nline1,DOWN,aligned_edge=LEFT)
dot2 = Dot(nline2.n2p(5),color=BLUE)
self.add(nline2,dot2)
nline3 = nline2.copy().next_to(nline2,DOWN,aligned_edge=LEFT)
nline3.add_tip()
dot3 = Dot(nline3.n2p(5),color=YELLOW)
self.add(nline3,dot3)
nline4 = NumberLine(
x_range=[0,10,1],
length=12,
font_size=16,
label_direction=UP,
include_tip=True,
).add_numbers().next_to(nline3,DOWN,aligned_edge=LEFT)
dot4 = Dot(nline4.n2p(5),color=TEAL)
self.add(nline4,dot4)
nline5 = NumberLine(
x_range=[0,10.5,1],
length=12.5,
font_size=16,
label_direction=UP,
include_tip=True,
).add_numbers().next_to(nline4,DOWN,aligned_edge=LEFT)
dot5 = Dot(nline5.n2p(5),color=ORANGE)
self.add(nline5,dot5)
nline6 = nline5.copy().scale(0.7).next_to(nline5,DOWN,aligned_edge=LEFT)
dot6 = Dot(nline6.n2p(5),color=GREEN)
self.add(nline6,dot6)
I have been doing some digging when I have the chance, and it seems if you remove and replace the ticks and numbers after adding the tip places them in the same positions as if the tip is added during creation. This makes sense, since it is what occurs during initialization. It seems the easy fix would be to reset these within add_tip, but to me it seems like not the right way to go about this.
Here's an example that shows what I mean.
class nlineScaling(Scene):
def construct(self):
# add_tip by itself
nline1 = NumberLine(
x_range=[0,10,1],
length=8,
font_size=16,
label_direction=UP,
).add_numbers().to_corner(UL)
nline1.add_tip()
dot = Dot(nline1.n2p(5), color=YELLOW)
self.add(nline1, dot)
# add_tip, followed by resetting the ticks
nline2 = NumberLine(
x_range=[0,10,1],
length=8,
font_size=16,
label_direction=UP,
).add_numbers().next_to(nline1,DOWN,aligned_edge=LEFT)
nline2.add_tip()
nline2.remove(nline2.ticks).remove(nline2.numbers)
nline2.add_ticks()
nline2.add_numbers()
dot2 = Dot(nline2.n2p(5), color=RED)
self.add(nline2, dot2)
# Adding the tip from the beginning
nline3 = NumberLine(
x_range=[0,10,1],
length=8,
font_size=16,
label_direction=UP,
include_tip=True,
).add_numbers().next_to(nline2,DOWN,aligned_edge=LEFT)
dot3 = Dot(nline3.n2p(5), color=GREEN)
self.add(nline3, dot3)
and the resulting image
I also suspect there may be a deeper issue with the way add_tip works, but it'll take a bit more digging.
Looking into theTipableVMobject class, the end of the number line should be at the base of the tip, but is instead being set to the end of the tip when calculating the tick locations and any other use of n2p. n2p is incorrectly incorporating the length of the tip into its calculations. Oddly enough, calling add_tip after creation actually results in the correct display for the number line (with the end of the number line placed at the base of the tip), though subsequent n2p calls result in incorrect locations being calculated along the number line.
So the solution should be as "simple" as removing the length of the tip from the calculations for n2p.
Ok, I think I got it!
The issue was with the way the TipableVMobject defined get_end (and by extension get_start). It was using the tip's get_end method, which doesn't actually get the base location, but rather the end of the polygon that defines the arrow tip (which happens to be the very tip of the arrow).
def get_end(self) -> Point3D:
if self.has_tip():
return self.tip.get_end()
else:
return super().get_end()
By changing the method to use the tip's base property, it fixes the positioning problem.
def get_end(self) -> Point3D:
if self.has_tip():
return self.tip.base
else:
return super().get_end()
Using the same test code from above with the updated get_end method, I get the following image:
Now, there's an issue with the last line where it doesn't show the last tick mark.
Ok, got the tick mark appearing the same after adding a tip after the fact as well as during creation.
And with the code supplied by @uwezi