I open this topic for the snippets hatch and fill, as a place for further disussions.

You find these snippets and a corresponding example in the extension manager (online gallery).

Previous discussion can be found here.

---

Example of application

---

EllipticGears.sm (40 KiB) downloaded 162 time(s).

---

Graf1.smz (2 KiB) downloaded 122 time(s).

It's amazing how compact the code is!

Two types of shading

---

Reuleauxtriangle1.sm (34 KiB) downloaded 113 time(s).

Hi. From the orignal discussion:

Wrote

Fridel, thanks for revisiting the snippet and the performance issue. Quite odd for me: The fastest way seems to be direct element adressing without pre-allocation and avoiding stack(). See attachment. The speed-up is significant.

Please post any response to the new dedicated topic

I understand that stack or augment are bad strategies, but without pre-allocation is better than with pre-allocation? If it is, why is without pre that good. Seems to be to much faster than I can explain or understand.

Best regards.

Alvaro.

Wrote

I understand that stack or augment are bad strategies, but without pre-allocation is better than with pre-allocation? If it is, why is without pre that good. Seems to be to much faster than I can explain or understand.

Best regards.

Alvaro.

"memory allocation" vs "memory NOT allocation" is confusing to me.
Memory allocales itself from the construction. Visit the "Spot"
"stack" is very fast as being a vector operation. "augment" is slow
as not being a direct vector operation, but very fast within a program.
"hatch" creates a virtual matrix, a scalar matrix, i.e: a matrix at the
plot canvas. Same principle than plotting f(x) on the QuickPlot canvas.
Great construction, though I never used it. Watch it does not face infinity
governed by the N ... at infinity: it crashes Smath !

Jean

Forum Test Derivative.sm (11 KiB) downloaded 81 time(s).

Utilities Discrete Spot.sm (12 KiB) downloaded 84 time(s).

Using stack, if you have a vector, lets says, [x,y,z], then stack(t,[x,y,z]) must to force to push z from 3th plate to 4th, y from 2nd to 3th, ... for finally, put t at first place. And that's can take a very long time.
Preallocating is when you say "let's V:=matrix(20,1)", and then just work defining V[1, V[2 ... etc. If you found that don't need all 20 numbers, just can use submatrix. But if you don't preallocate V, but use V[1 ... V[20, and program work fast, who is preallocating must to be SMath, and that's isn't very efficient for the general cases. Or have some pointer very good for handle that matrices, and I don't know C at that level.

In your example, "Utilities discretes", it is suposed that defining U:=matrix(N,1), and same for V, must to be faster than having U:=0 and then use U[i

Best regards.

Alvaro.

It is supossed that second algorithm must to be faster than your's, but it isn't.

Best regards.

Alvaro.

See you tomorrow Alvaro.

That nice application of "hatch" is worth for "typesetting"

Jean

Wrote

I understand that stack or augment are bad strategies, but without pre-allocation is better than with pre-allocation? If it is, why is without pre that good. Seems to be to much faster than I can explain or understand.

Much faster than what? Please provide an example to discuss.

Wrote

Preallocating is when you say "let's V:=matrix(20,1)", and then just work defining V[1, V[2 ... etc. If you found that don't need all 20 numbers, just can use submatrix. But if you don't preallocate V, but use V[1 ... V[20, and program work fast, who is preallocating must to be SMath, and that's isn't very efficient for the general cases. Or have some pointer very good for handle that matrices, and I don't know C at that level.

It's a common practice in libraries to pre-allocate some space for any container. Without this, it would be very inefficient to manage memory. Further, re-allocation strategies on the low level are quite efficient, because they either use % of current size to grow (typical are 2x or golden ratio), or linked lists that don't need reallocation at all. SMath doesn't need to do that itself, because it's .NET that does that for it. And it's VERY efficient for general cases.

Wrote

It is supossed that second algorithm must to be faster than your's, but it isn't.

Well, your slower second time could be explained like this:
pre-allocation in SMath is high-level operation, and it simply adds one additional high-level (slow) operation.

And it could explain something, if not one little thing ... actually it doesn't matter.
SMath calculation time is very volatile, and it's hard to measure time reliably, even doing multiple comparisons/calculations. E.g., processor temperature, that raises towards second calculation, may cause it to slow down to prevent overheating (contemporary systems do that). Some memory leaks in SMath may cause slow-down of all subsequent calculations (and when the sheet is done calculation, .NET garbage collection may clean it up, so recalculation shows the same picture).

Here is a screenshot that shows that your "second" calculation, put first, outperforms original.

Alvaro, Mike: thanks for entertaining technical matters, very educative.

Though the "algo style" existed in Smath before I joined the team, it
was not elegant and in some ways not visible. As you can see, in the
attached, there is one less "augment" in ... pts(data,spec) compared to
plotG(vx,vy,char,size,color) decreasing the computing time by a factor
of 12 on my testing over 1000 points. You may have better suggestion(s).
For sure welcome in the experiment room .

Jean

Forum Compute Test Points Fill.sm (17 KiB) downloaded 81 time(s).

Inst_Segment Partial Random.sm (38 KiB) downloaded 78 time(s).

Wrote

Wrote

I understand that stack or augment are bad strategies, but without pre-allocation is better than with pre-allocation? If it is, why is without pre that good. Seems to be to much faster than I can explain or understand.

Much faster than what? Please provide an example to discuss.

Than I can explain or understand. Sorry, have not examples of that.

Wrote

It's a common practice in libraries to pre-allocate some space for any container. Without this, it would be very inefficient to manage memory. Further, re-allocation strategies on the low level are quite efficient, because they either use % of current size to grow (typical are 2x or golden ratio), or linked lists that don't need reallocation at all. SMath doesn't need to do that itself, because it's .NET that does that for it. And it's VERY efficient for general cases.

Thanks for the explanation, now I understand why mkraska says "The fastest way seems to be direct element adressing without pre-allocation". Because preallocating is with a high level instruction, and then is slow. Even I have the doubt about why NET pre-allocat V:=0 as matrix when user define that as scalar. I suposse that default SMath types are complexes, not matrices.

So, for the best practices book in SMath, which is best? Never preallocat? Or there are some size when NET take more time than SMath because the NET pre-pre-allocation (the jus't in case one) isn't enough big?

Best regards.

Alvaro.

Wrote

now I understand why mkraska says "The fastest way seems to be direct element adressing without pre-allocation". Because preallocating is with a high level instruction, and then is slow.

No, I tried to show this. One single allocation instruction's duration is null, zero, nothing. You will be unable to notice it in any measurements in SMath. Martin was not correct. I will say it once more: one method (assigning 0 and then addressing elements) is not faster than the other.

Quote

Even I have the doubt about why NET pre-allocat V:=0 as matrix when user define that as scalar. I suposse that default SMath types are complexes, not matrices.

No, it "allocates" a scalar (very fast) once, and then re-allocates a vector with a sensible pre-allocated size (very fast) once.

Quote

So, for the best practices book in SMath, which is best? Never preallocat? Or there are some size when NET take more time than SMath because the NET pre-pre-allocation (the jus't in case one) isn't enough big?

I prefer always preallocating when I know the size. It won't hurt. Its "overhead" of high-level instruction is the same as of the assigning 0 and then re-allocating. In a function, it will not make any difference until the system preallocation size is exceeded, and then, when the function will handle big matrices, it will give you (insignificant, if any) performance gain.

Like this Alvaro in my own words,

Mathcad up to 11 [my last version up to may 30 that PT deactivated all Single User Edition]
Mathcad XY plot is on "pica" [from recollection 8 pixels] thus the imposibility to equally size
two graphs in height/width. Smath plots on the canvas pixel. Each time it reaches a pixel it
calculates the ordinate value and plug the color, thus finally tracing the function. This porocess
is very fast, but at the kernel level and not accessible to user. To get an export trace then you
must create a vector of discrete values in the number of points as you wish.

Martin program is very crafty ! Instead of hatching by creating each vertical bar manually, it
creates the same as manual but adjustabe in 'N' and between the two plots in question. His argument
of the plot is f,g,x.1,x.2,N in hatch(f,g,x.1,x.2,N), just like asking to plot 'x' in ln(x).
So, 'f,g,x.1,x.2,N' is purely "scalar" in the sense of a vanishing iterator once done the plotted
value on the Smath QuickPlot.

As you remember from Mathsoft Collaboratory, so much I loved Mathcad 2D ...
... so much Smath QuickPlot produces more convenient graphs. OK, some missing features but monkeys
survive with bananas only, is it ? On the hatching demo [attached next post], if you plot points
the hatching looks blank. Not at all, they are all there but not joining because the points confuse
on each plot trace.

Jean

... the hatching demo

2DPlots Hatch Demo.sm (8 KiB) downloaded 92 time(s).

... works as expected !



Maths Tangent.sm (18 KiB) downloaded 92 time(s).

My versions for fill and hatch.
Have a nice day.
Alvaro.

FillRnd.sm (44 KiB) downloaded 97 time(s).

Only the first module works. The ones "if/else" do not in Smath 5346
The first module is fully compatible with Maxima X_Y plot, i.e:
traces color, symbols, hatching color ... great for publishing.
Martin scalar hatching is slightly faster, not to account in project.
Your module [Alvaro] is great for extracting a particular bar but
couldn't add to the plot ???

Tanks, Jean




2DPlots Hatch Demo [Martin, Alvaro].sm (23 KiB) downloaded 89 time(s).

Wrote

Only the first module works. The ones "if/else" do not in Smath 5346

Well, works fine in last nightly build, but you're right, in others don't. I try to modify, but have a lot of issues. For instance, attached seems to work in last portable version, but can take a very long time for fill(phi(2), ...) , I suspect for some problem with the lele function. I'm interested in that function and rfill because rows of G are proportional to double integral of the functions f,g.

About the original fill function, it is a very nice job, but I prefer to define x range and Nx, Ny as number of points, instead of define the entire box x1,x2,y1,y2. But that's is ok for double integrals.

Best regards.

Alvaro.

File not found.File not found.