I'm going to write a modified version of MakeGraph by mike3

[JmsNxn]

Yes, for a vector of values:
  st=""; for(c=1,cols, st=Str(st, X[  c  ])); write(st);

or for a rows-by-cols array
  st=""; for(r=1,rows, st=Str(st,X[r,1]; for(c=2,cols, st=Str(st, ",",X[r,c])); st=Str(st,"\n"));   write(st); 

This should be considerably faster than all mathematical optimizations...
Perhaps a "strjoin()" on a vector of numerical values might even be faster than doing the loop of "for(c=1,cols, st=Str(st,",",<numerical value>))". You should test it.   


Moreover, the new "filewrite()" procedures do more-or-less make the above implicite (via caches in main-memory, while "write()" do the full procedure of looking whether the file exists, allocation of a write-string, looking where the file-pointer is, increase, write to the file-system, wait until received, closing the file descriptor etc etc.

I always use filewrite()

I was just using the broad term WRITE; as how the code works. And the math of whatever speed it takes to run WRITE.

I think you're going to be pleasantly surprised with my math speed ups, Gottfried. Don't write them off yet. I'm just explaining how the logistics of the code go. I do believe you are right. I can probably gain some speed by avoiding WRITE, and just writing strings of elements.

Give me a day or two. I swear the code I wrote is pretty fucking cool

[JmsNxn]

So much of this program is Mike3. I only added splines and data points to construct the same graph Mike3's program makes; just mathematically faster. Because solely it can gather less points.

I'd love for you to look at this code and tell me what you think. The explanation of the code, comes from Mike3's work. I have slightly adapted his notation for this rework. If you read the comments; it will all make sense.

I intend to write a read me soon.

But the main commands are:

func(z)

MakeGraph(WIDTH,HEIGHT,x0,y0,x1,y1,FILENAME, BLUR)

We have to perscribe a function func(z). And then, choose the WIDTH BY HEIGHT in PIXEL BY PIXEL. The value (x0,y0) is the top left corner, and (x1,y1) is the bottom right. The term FILENAME is a plain data file written in .PPM format. This is a basic Linux format--and an unencrypted format. Each value of hexadecimal puts a PIXEL in the file; it is unencrypted.

The value BLUR is my addition. And what I've done to make everything faster. The only condition to BLUR right now is that:

BLUR*WIDTH is a Natural number
BLUR*HEIGHT is a Natural number

0 < BLUR <= 1

And when BLUR = 1, we just run mike3's program. The explanations are in the program:



  MakeGraph.gp (Size: 9.36 KB / Downloads: 160)

[Gottfried]

But the main commands are:

func(z)

MakeGraph(WIDTH,HEIGHT,x0,y0,x1,y1,FILENAME, BLUR)

Hi James - ufff... the idea to replace the elementwise "write(' ',<color>);" by a rowwise "write(strjoin(rowvec_of_colors))" plus replacing "write()" by "filewrite()" does not gain much.

I expected something like needing only a quarter, fifth or tenth of time, but only could improve to about 3/4 (for 200x200) resp 56/95 (for 800x800) of time for the improved against your given routine (of course checked for the file-writing part alone!).            
I'm really surprised, because in my yearlong Pari/GP-experiences I *had* cases where the improvement by the better write-procedure was far better.            
Don't know what's going around; perhaps Pari/GP in its version 15.0 is already better than older versions in this hindsight - don't know. 

So unfortunately I cannot be of much help here...

Still wishing you more good good luck as before...  

Gottfried

[JmsNxn]

Hey, Gottfried!

That's not the speed up!!!!!!!!!!!!


The speed up, is if you need to graph 1000x1000 pixels. We only need to reference func(z), b*1000xb*1000 times for \(0 < b \le 1\). Rather than evaluating pixel by pixel. We only evaluate the function func(z) pixel block by pixel block!

So essentially.

If I take: func(z) = sin(z). And I want to make a 1000x1000 pixel graph. I have to evaluate func(z) 1000x1000 times; at each pixel.

Where, if we use my speed up. Set b = 0.5. Then I only need to evaluate func(z) 500x500 times. And still make a 1000x1000 pixel picture. Where I "spline" together the missing pixels.

There's no real speed up for func(z) = sin(z). Because sin(z) graphs so fast. But when we are taking a very complex tetration function it's time consuming to evaluate func!!!

Say that func(z) takes 1 second to evaluate. Then to run mike3's program, we need at least 1000x1000 seconds to graph. Where my speed up is 500x500 seconds.

Think of it as a lossy compression algorithm!!!!!

[Gottfried]

Hey, Gottfried!

That's not the speed up!!!!!!!!!!!!

(...)
Say that func(z) takes 1 second to evaluate. Then to run mike3's program, we need at least 1000x1000 seconds to graph. Where my speed up is 500x500 seconds.

Think of it as a lossy compression algorithm!!!!!

Hi James -

I see;
well I had made some suggestion before, and became critical of that yesterday, noticing finally, that the speedup expected does not occur, just a much smaller effect. So my suggestions came out to have little effect only. (But *that fact* is/was noticeable I think)

Just to check/see this detail - that has been the intention of my second post.    

- - - -

Of course: an interpolation-method whose reducing power goes into a quadratic formula (like yours) overpowers any optimization which has a linear reduction of time, no question.

[JmsNxn]

Hey, Gottfried!

That's not the speed up!!!!!!!!!!!!

(...)
Say that func(z) takes 1 second to evaluate. Then to run mike3's program, we need at least 1000x1000 seconds to graph. Where my speed up is 500x500 seconds.

Think of it as a lossy compression algorithm!!!!!

Hi James -

I see;
well I had made some suggestion before, and became critical of that yesterday, noticing finally, that the speedup expected does not occur, just a much smaller effect. So my suggestions came out to have little effect only. (But *that fact* is/was noticeable I think)

Just to check/see this detail - that has been the intention of my second post.    

- - - -

Of course: an interpolation-method whose reducing power goes into a quadratic formula (like yours) overpowers any optimization which has a linear reduction of time, no question.

Thanks gottfried!

The main point is that you can't even tell the difference; despite the fact we have used a quasi lossy compression formula. The eye cannot tell. But it goes way faster. And it's still accurate... enough!

When you're evaluating 2x2 pixels once instead of 1x1 pixels 4 times, and "splining" with a linear formula, they eye can't tell   And it's still accurate enough.

The only trouble is when tetration goes from a trillion trillion to zero in a flash. In that case, my speed up looks pixelated. But I can live with that, if I can make bigger graphs which are basically identical when everything is reasonable .

[JmsNxn]

Also, I don't believe this is a quadratic speed up. In theory it's pretty close. It's probably more like \(x^{2-\delta}\) where \(\delta\) is relatively small. But the more difficult the function we are graphing, the closer to quadratic it is. There's still some shit to iron out. But in a perfect world, it should basically be a quadratic speed up, which does a bit of compression on the fly....

[Gottfried]

Also, I don't believe this is a quadratic speed up. (...) which does a bit of compression on the fly....

Let me create a new, buddhistic, meme, on the fly: "if you can't compression, stay in compassion"  ( or so...)

[JmsNxn]

As the great irrationalist Pythoras said:

There are no such things as quadratics. For everything is irrational. Even within perfect geometry; everything is irrational.

I just made this up, but this is a lot of his cults philosophy around \(\sqrt{2}\)

\(x^{2-\delta}\) is it getting so close to a quadratic... Just like the Pythagorean search for the physical manifestation of a perfect right triangle........

[tommy1729]

As the great irrationalist Pythoras said:

There are no such things as quadratics. For everything is irrational. Even within perfect geometry; everything is irrational.

I just made this up, but this is a lot of his cults philosophy around \(\sqrt{2}\)

\(x^{2-\delta}\) is it getting so close to a quadratic... Just like the Pythagorean search for the physical manifestation of a perfect right triangle........

In nature everything is irrational whenever it can and "whenever it can " usually means involving conservation of energy and quantization.
And that is why we will never understand it.

Tom Raes