Here it is on Github
https://github.com/C0rymcg/HSP

Just like yours, it uses [0-1] to describe the h s and p values

RGB is handled by the functions as being integers within [0-255] (although that would be easy to change if needed)

I also included a demo html file that shows the results of these functions nicely.

Partly yes... In my demo there is some simple shading on the top and bottom edge of the image just to make it look pretty.

So when it renders, I use the gradient array and HSPtoRGB(), to get R, G, B values, and multiply those by a value between 0 and 1 chosen with y

Yes, you understand correctly!

You can simplify the loop further, now, by replacing the P setting in the HSPtoRGB function call to "0.5" instead of "lerp(0.2,0.5, bright)"
Then you won't need Bright to be defined at all, and it will stay at 0.5 perceptual brightness.

"Lerp" is short for "Linear Interpolation" and was only included to quickly add that shadowing effect.

...
Can you describe the idea of HSP gradients ?
...

I've had to think about this... First of all, I'd say that a regular gradient is a series of colors where some or all of the properties that define those colors change gradually and consistently over that series.

This is similar to what you said, but I don't normally think of a gradient as necessarily needing one aspect of the color series to stay the same. As long as the changes are not sudden, and don't show obvious acceleration or deceleration, it fits my idea of a gradient.

With this in mind I'd say that an HSP gradient is a type of  gradient (or color series) where the defining properties are chosen to represt how humans see color, rather than by how our devices display it.
The result is that gradients in this colorspace (Or any good perception-based colorspace) will look more natural and convincing as gradients, and less "Computer generated"

This makes sense. I find it's often necessary to limit either S or P in order to get nice looking results, since the function will quickly reach the limits of our monitors' color gamut if these values are both high.
While it's often nice to have bright and saturated colors, I think a properly chosen mix or blend is even nicer.

It looks like your graph is reflecting this... in the first one you have hue set to 1 or 0, so the result is red, and it can ramp in intensity up to 1 without showing limtiations.
But in your second example you have a different value for S, I'm guessing, and you can see R reach full intensity before B can, which results in that bend in Y at around p = 0.65... That would correspond to a visually detectable change in the gradient for a human viewer, too, although it may be quite subtle.

So that would be an example of where high brightness, even when saturation is at 0.5, would reveal the inability of our monitors to display certain HSP gradients.
(Of course, there are limitations in every colorspace, theoretically... in RGB, our monitors can't display any color that has a channel brighter than 255, for example... The difference here is just that HSP is a little bit more limited than RGB for certain hues)

There is actually quite a bit of literature on this topic. Relevant buzzwords: "color calibration" should lead to information on the limitations of the various display devices. "Color correction" is about different color spaces and mapping between them. "Tone mapping" is about making the best of the limitations of a given display device.

I found it surprising how deep that particular rabbit hole is, compared to our thoughtlessness when we talk about color in everyday life.

(Bonus buzzword: "tetrachromacy" .)

https://www.frontiersin.org/articles/10.3389/fnhum.2011.00060/full?fbclid=IwAR3iRLyZ6_ORjdqwRZOFIHM-ikvdzXhPmZm4w59QMPBJjOvtHVj2f-Rg71w

Perceptual and physiological responses to Jackson Pollock’s fractals

I want to leave this program here:

Can you post image ?

new Sine, LSine, LSineExp maps:

https://gitlab.com/adammajewski/color_gradient