Piet Souris

hi Francesca,

have a look at your 'mouseClicked' method. Depending on your flag, you are adding a rectangle, a circle and a line to your Collections. So, your three Collections all increase with one shape. Therefore, if you have 4 rectangles, you also have four circles and four lines. I'm not sure what your intention is, but maybe you can clear all of your collections, whenever you detect that a new figure is selected.

Campbell Ritchie wrote:(...) but I can still see problems.

You describe another way of doing things, but you do not mention the problems. What are they?

It is always tricky to compare floats with doubles, or even two doubles. For instance, Math.abs(-65.4) == Math.abs(65.4) gives false.

Use some small tolerance in the comparison.

Yes, but that does not solve the general problem. A very simple solution, when you have Java 9+, is to replace
Main app = ...
with
var app = ...
and let Java determine what the exact type of 'app'is (strangely enough my NetBeans won't show that type).

Yes, I noticed the reference... otherwise I would have called it 'AbelsSum'. I learned this trick when I was 11, in primary school, and I seem to recall the teacher mentioned Abels.... well, memory can play tricks on you.

A bad name for the class....    

Why do you specify 8 points when you only need 5 of them?

And I must repeat my advice: put the base points in the xy-plane, and the top some point with a positive z-coordinate, it is then very easy to visualize what figure you are building.

For instance: if you look at your 5 unique points, with all the minus and plus coordinates, it is very hard to see if these form indeed a square pyramid. I tried to skech these points to the best of my abilities, but I could not detect any square pyramid (though my sketch abilities are very limitied, to say the least).

So, instead, let
A = (1, 1, 0)
B = (-1, 1, 0)
C = (-1, -1, 0)
D = (1, -1, 0)
T = (0, 0, 1)

then it is immediately clear what figure you are defining.

The triangles will be: ABC, BCD, ABT, BCT, CDT, DAT, giving the indices array
[0, 1, 2, 1, 2, 3, 0, 1, 4, 1, 2, 4, 2, 3, 4, 3, 0, 4]

And then for the normals: it is clear that for the triangles in the base (ABC and BCD) the normal would be (0, 0, -1). For ABT we have that the normal of ABT is (0, 1, 1) (why?). For triangle BCT we have the normal (-1, 0, 1), CDT gives (0, -1, 1) and DAT the normal (1, 0, 1) (not normalized). If we number these vectors 0 to 4, we get the indices array
[0, 0, 0, 0, 0, 0, 1, 1, 1, 2, 2, 2, 3, 3, 3, 4, 4, 4]

And finally: it might be that specifying a triangle as 0, 1, 2 will give the triangle some other properties that when specified (0, 2, 1). I don't know the software you are using, check it to be sure.

Succes!

But not half as strange as these coderanch folks

hi Anduena,

how did you get the normals in the code in your opening post?

An advice for you: with these four - or five point figures, keep at least one triangle in the xy-plane, that is much much more clear than working with all these minusses in the coordinates..

In general: if you have the vectors (a1, a2, a3) and (b1, b2, b3) and you want to calculate a vector that is perpendicular to both (assuming these vectors are independant), then you can calculate the so called outproduct (or crossproduct as it is called in English). That vector is the vector(a2 * b3 - a3 * b2, a3 * b1 - a1 * b3, a1 * b2 - a2 * b1). The direction of this vector is according to a so called right-handed system: if you move the fingers of you right hand from vector first to vector second, then the direction of that normal is the direction your thumb is pointing to. Sounds complicated, but that direction is important to get the lighting correct. More about that later.

Now: look at the code in your opening post. We had the point A = (1, 1, 1), B = (1, -1, -1) and C = (-1, 1, -1). The triangle ABC has two directional vectors AB and BC. We calculate these:

AB = A - B = (1, 1, 1) - (1, -1, -1) = (0, 2, 2)
BC = B - C = (1, -1, -1) - (-1, 1, -1) = (2, -2, 0).

Takiing the crossproduct (that vector with a2b3 - a3b2 et cetera) we get the vector (4, 4, -4), and if we normalize it, we get the vector 1 / sqr(3) * (1, 1, -1).

This is the normal in point B, for the triangle ABC. And orf course A and C have the same normal.

And we do the same for the vertices of the other triangles. So, for ABC we have the normal indices 0, 0, 0. Et cetera.

As I said, the direction in which the normal points is important, since it should point to the outward of the triangle. The lighting formulas can then determine which sides are enlightend.

Now, with all those minusses and plusses in your coordinates it is hard to say which direction is the correct one: the one calculated from the crossproduct, or the one that points in the other direction.
So, check your theory about normals, it is a very important aspect.

Lets consider the square pyramid. Let the base be A = (0, 0, 0), B = (2, 0, 0), C = (2, 2, 0) and D = (0, 2, 0). The top T = (1, 1, 1). So we know that the normal in B must point downwards, in the negative Z-direction.

Lets do the calculation for point B:
AB = A - B = (-2, 0, 0)
BC = B - C = (0, -2, 0)

and so the normal = (0, 0, 4) or normalized (0, 0, 1). But this vector poins in the positive direction of the Z-axis, while we should have it pointing in the negative Z-diection. So we take (0, 0, -1)
and the points A and C have that same normal.

In short: I don't know what theory you have gotten sofar, but it is important to get a good grip on what is says. I hope this summation gives a little insight in the world of 3D modelling and lighting.

Of course... I apologize for my silly question  

Interesting, but not easy. And the question is: is it worthwhile? Can you make an implementation?

I was inspired by Mike's clever use of two LongStreams, getting rid of the modulo 3 business.
So I thought: why not combine it with my jumps in the index?

Doing so and comparing the sum with Mike's sum, I noticed that the sums were off, totally off. I spent a lot of time searching for the problem, and finally it became clear that my jump in the index was wrong. I did:
LongStream.iterate(0, i -> i <= 1_000_000, i -> i += i % 1_000 == 199 ? 201 : 1)
and that jump is okay when i is 199, 3199, 6199 et cetera, but not when i is 1198. I guess learning modulo arithmatic was a (int) long time ago....

So I fixed that, and compared running times against Mikes running times.
For MAX = 1_000_000, Mikes way is faster, but for MAX = 1_000_000_000, my way was 6 times as fast. I looked for mistakes, but couldn't find one. Anyone an idea?

The code I used was:
public class GaussSum {        public static void main(String... args) {                long MAX = 1_000_000_000;        var start = System.currentTimeMillis();        var sum = LongStream.concat(LongStream.iterate(1L, i -> i <= MAX, i -> i + jump(i)),                                    LongStream.iterate(2L, i -> i <= MAX, i -> i + jump(i)))            .sum()        ;        var end = System.currentTimeMillis();        System.out.println("took: " + (end - start) / 1000. + " seconds");        System.out.format("%,d%n", sum);        System.out.println("*********************************");                start = System.currentTimeMillis();        sum = LongStream.concat(LongStream.iterate(1, i -> i <= MAX, i -> i + 3),                                LongStream.iterate(2, i -> i <= MAX, i -> i + 3))            .filter(GaussSum::check)            .sum()        ;        end = System.currentTimeMillis();        System.out.println("took: " + (end - start) / 1000. + " seconds");        System.out.format("%,d%n", sum);    }        private static boolean check(long i) {        var d = ((int) i / 100) % 10;        return d != 2 && d != 3;    }        private static long jump(long i) {        var dif = i % 1000;        return dif == 197 ? 204 :               dif == 198 ? 204 :               dif == 199 ? 201 :                              3        ;    } }

All the credits to Rob, but you're welcome!

I ran this code on my 9 year old laptop with an I3 processor:
var start = System.currentTimeMillis(); var sum = LongStream.iterate(0, i -> i <= 1_000_000, i -> i += i % 1_000 == 199 ? 201 : 1) //    .parallel()    .filter(i -> i % 3 != 0)    .sum() ; var end = System.currentTimeMillis(); System.out.println("sum is: " + sum); System.out.println("duurde: " + (end - start) / 1000. + " seconden");
And it took under 0.1 seconds. The parallel version took twice as long.

You're welcome!

It IS in the code that Eleni shows. It is the line:
System.out.printlnArrays.asList(temps);
That line (with missing parentheses) is within the body of the loop, so that is why you see what you see.

Another thing to improve is that now all the arrays are printed on one line, instead of each array on its own line.