@theengineear

@choldgraf

Sounds all good. I can fix this all up now.
Did you push anything just now? I'm wondering why the tests are running after they looked finished.

I haven't (and won't) push anything now that this PR is up and running!

@Kully , GH seems to think you made different pushes.

Not sure if that's the case or not.

At any rate. I'll leave it to @Kully to fix-up/discuss as necessary. As long as tests are passing, This can 💃 into master whenever.

Thanks for all the help @choldgraf!

Not sure if that's the case or not.

I actually changed version.py once and tried to push but got an error, so I changed it back and tried again with success.

thanks for the help as well! I imagine that we'll need to make tweaks here and there, and can open (hopefully tiny) PRs as necessary.

@jackparmer any idea on whether the time to first plot can be improved on the JS side?

Also, once we get this working I can write some high-level functions to calculate facecolors based on neural activation and write a blog post of some sort if it's useful.

ps @theengineear where are those stacks in your profile picture? Reminds me of when I was a radio DJ back in college :D

ack crap - I missed one thing. I just noticed that the create_trisurf function still doesn't have a plot_edges argument. We should add that in and then pass it in the call to _trisurf. I can make a PR but it's a pretty simple fix if someone wants to just edit master.

ack crap - I missed one thing. I just noticed that the create_trisurf function still doesn't have a plot_edges argument. We should add that in and then pass it in the call to _trisurf. I can make a PR but it's a pretty simple fix if someone wants to just edit master.

I can do now. Besides, I forgot to switch dist_func to color_func ;)

ok cool :) I swear PRs are like emails...every time I send one off I have an "oh shoot I missed XXX" moment

A couple other random things:

1. The plot_edges argument should default to False IMO, not None, since it's a bool
2. We should let the user specify an array/list of rgb colors instead of color_func, in case they've got pre-computed colors (e.g., activation patterns relative to certain electrodes). Maybe just a quick isinstance(color_func, (np.ndarray, list)) then a check to make sure it's full of rgb strings. Or is that for another PR?

The plot_edges argument should default to False IMO, not None, since it's a bool

Okay, easy.

We should let the user specify an array/list of rgb colors instead of color_func, in case they've got pre-computed colors (e.g., activation patterns relative to certain electrodes). Maybe just a quick isinstance(color_func, (np.ndarray, list)) then a check to make sure it's full of rgb strings. Or is that for another PR?

You want both functionalities right? I think I can do this in the same PR.

Yeah I think it should be "check if the input is a list / array. if yes, then assert that it's the same length as simplices. Something like:

        if colors is None:
            # mean values of z-coordinates of triangle vertices
            mean_dists = tri_vertices[:, :, 2].mean(-1)
        elif isinstance(colors, (list, np.ndarray)):
            if len(color_func) != len(simplices):
                raise ValueError('If colors is array-like, '
                                 'it must be the same length as simplices')
            mean_dists = color_func
        else:
            # apply user inputted function to calculate
            # custom coloring for triangle vertices
            mean_dists = []

            for triangle in tri_vertices:
                dists = []
                for vertex in triangle:
                    dist = colors(vertex[0], vertex[1], vertex[2])
                    dists.append(dist)

                mean_dists.append(np.mean(dists))

around line 1536

Though note that we'll probably lose all the benefits of the optimization if someone gives a function, since it's a looping and appending to lists. It'd be faster to expect a function that takes an (n x 3) array and returns an array of shape (n,). That way the user could decide to optimize the function however they like. So you could just collapse that code to:

mean_dists = colors(tri_vertices)

(but I think that might be worth a different PR if it seems like people are often using that functionality...my guess is that people would often pre-compute their colors)

(but I think that might be worth a different PR if it seems like people are often using that functionality...my guess is that people would often pre-compute their colors)

Fair enough. Yes, let's make it a separate PR then.

I was a little confused by your penultimate message: mean_dists = colors(tri_vertices)

Is colors supposed to be the colors_func?

ah yeah, sorry...locally I've been just calling it colors since it is allowed to be a list or array.

Been spending the morning writing some activity functions too, so when the lighting is fixed it should look relatively purdy: