Feynmann lifeguard riddle graphical representation Physicist Richard Feynman though of a very interesting riddle:

Imagine you are a lifeguard at the side of the beach and there is a child drowning in the water. (You must cross both sand and water to get to him)
Which route would you take to go to the child and save him?

Not a straight line1 because in the sand you move faster than in the water so the advantage of staying a larger percentage of the trip on the sand outweighs the disadvantage of having a longer trip (straight line is shortest) up to a certain point.
How to get an intuition about the shape of such route?
I wrote a simple visualization with modifiable parameters to get an intuitive feeling for different start positions and sand/sea speed ratios, here is an example (yellow is sand, blue is sea):

I am interested in all kinds of suggestions, here is the code:
from tkinter import *

LIFEGUARD_Y = 100
CHILD_Y = 350
SAND_SPEED = 3 # SEA_SPEED = 1
WIDTH = 500
HEIGHT = 500

def distance(a, b):
    return ((a[0] - b[0])**2 + (a[1]-b[1])**2)**0.5

def total_time(lifeguard_y, child_y, midpoint_y,sand_speed=SAND_SPEED):
    sand_len = distance( (lifeguard_y, 0), (midpoint_y, WIDTH//2) )
    sea_len = distance( (midpoint_y, WIDTH//2), (child_y, WIDTH) )
    sand_time = sand_len / sand_speed
    sea_time  = sea_len / 1
    return sand_time + sea_time

def find_optimal_midpoint_y(lifeguard_y, child_y,sand_speed=SAND_SPEED):
    return min(range(0, 500), key=lambda y: total_time(lifeguard_y, child_y, y, sand_speed))
    
def show_situation():
    master = Tk()

    master.title(&quot;Feymann lifeguard route problem&quot;)
    w = Canvas(master, width=WIDTH, height=HEIGHT)
    w.pack()


    l = Label(master, text=&quot;Lifeguard Y&quot;)
    l.pack()
    
    lifeguard_y_w = Scale(master, from_=0, to=HEIGHT, orient=HORIZONTAL)
    lifeguard_y_w.pack()

    l = Label(master, text=&quot;Child Y&quot;)
    l.pack()

    child_y_w = Scale(master, from_=0, to=HEIGHT, orient=HORIZONTAL)
    child_y_w.pack()

    l = Label(master, text=&quot;Sand Speed / Sea Speed ratio&quot;)
    l.pack()

    sand_speed_w = Scale(master, from_=1, to=3, resolution=0.1, orient=HORIZONTAL)
    sand_speed_w.pack()

    
    w.create_rectangle(0, 0, WIDTH//2, HEIGHT, fill=&quot;yellow&quot;)
    w.create_rectangle(WIDTH//2, HEIGHT, WIDTH, 0, fill=&quot;blue&quot;)
    
    def draw_optimal_route():
        w.create_rectangle(0, 0, WIDTH//2, HEIGHT, fill=&quot;yellow&quot;)
        w.create_rectangle(WIDTH//2, HEIGHT, WIDTH, 0, fill=&quot;blue&quot;)

        midpoint_y = find_optimal_midpoint_y(lifeguard_y_w.get(), child_y_w.get(), sand_speed=sand_speed_w.get())

        w.create_line(0, lifeguard_y_w.get(), WIDTH//2, midpoint_y)
        w.create_line(WIDTH//2, midpoint_y, WIDTH, child_y_w.get())

    b = Button(master, text=&quot;GO&quot;, command=draw_optimal_route)
    b.pack()

    mainloop()

if __name__ == &quot;__main__&quot;:
    show_situation()

1 A straight line only in the trivial and non-realistical case where sand-speed = sea-speed such as for a bird.
Bonus Physics Note: Light behaves the same way as this perfect lifeguard because it always chooses the fastest path.
Don't use wildcard imports

Change from tkinter import * to import tkinter as tk, and then prefix all tk classes and variables with tk. (eg: tk.Frame(...)).

One reason is that PEP8 discourages wildcard imports. Also, by using the prefix your code becomes more self-documenting. 

One problem I see people make is that they import * from both tkinter and ttk. Since both of them have many classes with the same name (Button, Entry, etc), it becomes impossible to know which is being used without remembering which the order of the imports. If you change the order of the imports you could break many lines of your code. 

You don't use ttk here, but if you get in the habit of using wildcard imports, eventually it will cause you problems. 

Name your main function main

This is largely personal preference, but I think it helps to name your main function main, and place it at the top of the file. When I was scanning your code, it wasn't until I got down to literally the last line in the file that I knew which function was called first. 

Use an object-oriented architecture

Python objects are easy to use, and make writing GUI code much easier. I recommend writing all tkinter programs with classes and objects. There's a stackoverflow question that covers this: Best way to structure a tkinter application

Separate widget creation from widget layout

I personally find it easier to write, maintain, and understand code when the widget creation is separate from widget layout. That is, instead of doing "create widget; layout widget; create widget; layout widget", do "create widget; create widget; layout widget; layout widget". I usually do the grouping by parent (eg: create all children of a parent widget, then layout those children, then go to the next, and so on)

When all of your widgets are in the root it's not quite as important as when you have multiple areas in your GUI that are independent, but even with everything sharing the same parent, grouping them together makes that more apparent. 

For example:

l = Label(master, text="Lifeguard Y")
lifeguard_y_w = Scale(master, from_=0, to=HEIGHT, orient=HORIZONTAL)
l = Label(master, text="Child Y")
child_y_w = Scale(master, from_=0, to=HEIGHT, orient=HORIZONTAL)
l = Label(master, text="Sand Speed / Sea Speed ratio")
sand_speed_w = Scale(master, from_=1, to=3, resolution=0.1, orient=HORIZONTAL)

l.pack()
lifeguard_y_w.pack()
l.pack()
child_y_w.pack()
l.pack()
sand_speed_w.pack()


Use explicit options to pack

You are relying on default values for all of your pack statements. While those defaults likely won't ever change, it makes your code a bit easier to read and your intent more obvious if you're explicit about where you expect the widgets to go. 

l.pack(side="top")
lifeguard_y_w.pack(side="top")
l.pack(side="top")
child_y_w.pack(side="top")
l.pack(side="top")
sand_speed_w.pack(side="top")


Consider the effect of resizing the window on your design

Your program doesn't handle resizing very well. It's not terrible, but it could be better. For example, as a user I would expect the yellow/blue area to expand to fill the top part of the window when I make the window larger, but it doesn't. I also don't expect to have the buttons chopped off if I make the window smaller; instead, I expect the yellow/blue area to shrink. It's also fairly common for an "OK" button to stick to the bottom, which it doesn't. 

You can use options to the geometry managers (pack, place, and grid) to control this. There's no single solution to making it work, it all depends on what you want to have happen when the window is resized. However, the first step usually involves designating a "hero" widget that will grow and shrink with the window. Most GUIs have such a thing, typically it's a text or canvas widget.