Strange results from operator overloading

[bruppel1]

So I'm running the following line of code:
panel.centroid = (panel.plist(1).point + panel.plist(2).point + panel.plist(3).point) / 3.0

.centroid and the .point items are derived types of "vector" which are just a collection of 3 reals (x,y,z).
I've defined vector_add and vector_div_real functions and I've assigned them to the + and / operators.
I've run the debugger and it appears that all of these functions are properly called, and when I step through the functions, the correct values are found. However, at the end of the day, panel.centroid is assigned crazy values (0 or numbers on the range of D+127). The expected values are on the order of x=300, y=0, z=15.

If I add parentheses around the entire set of statements on the right side of the "=" sign, the correct value is assigned to panel.centroid.

Can someone explain this?

Am I supposed to overload the assignment (=) statement? When I started working with derived types it looked like assignments from an object of one type to another of the same type just worked without requiring a definition. Also, the .point items are pointers (plist is an array of a type that contains a pointer to .point). I've seen an article on the internet that says you have to watch out with assignments using operator overloading and pointers.

Thanks,
Ben

[Steven_L_Intel1]

Can you show us a test case? You are correct that intrinsic assignment of derived types is automatically defined. The general approach you are using should work, at least from what I read of your description. However, a sample is worth 10,000 words.

[jimdempseyatthecove]

Ben

panel.centroid = (panel.plist(1).point + panel.plist(2).point + panel.plist(3).point) / 3.0
if((panel.centroid .eq. 0.0_8) .or (panel.centroid .gt. 1000.0_8) then
write(*,*) panel.plist(1).point, panel.plist(2).point, panel.plist(3).point
write(*,*) panel.centroid
endif

What happens?

[bruppel1]

Quoting - jimdempseyatthecove

Ben

panel.centroid = (panel.plist(1).point + panel.plist(2).point + panel.plist(3).point) / 3.0
if((panel.centroid .eq. 0.0_8) .or (panel.centroid .gt. 1000.0_8) then
write(*,*) panel.plist(1).point, panel.plist(2).point, panel.plist(3).point
write(*,*) panel.centroid
endif

What happens?

Hi Jim,
The compiler is complaining because the .eq. operator isn't defined for vectors. I can define it, is that what you were looking to check or were you trying to check something else?

Thanks!

[bruppel1]

Quoting - Steve Lionel (Intel)

Can you show us a test case? You are correct that intrinsic assignment of derived types is automatically defined. The general approach you are using should work, at least from what I read of your description. However, a sample is worth 10,000 words.

Hi Steve,
It will take a lot of carving up of code but I'll try to upload something once I get past a deadline this week.
A test case would include a working portion of the program which exhibits the bug, right?
Thanks,
Ben

[Steven_L_Intel1]

Yes - a small (if possible) but complete program that shows the bug.

[bruppel1]

Ugh, so I went back and forth a few times, and found that it wasn't neccessarily the parentheses.
My procedure was to change the parens, hit f5, get to a conditional breakpoint, step into the code.
It appears that by just changing the parentheses, I was unable to change the outcome at will, so something else possibly changed the outcome and I assumed it was the parentheses change.

I shut down the IDE and restarted it, and also rebuilt the solution. I tried doing this with and without the parentheses, and it hasn't changed the outcome (I am getting the right number now). Now I'm at a point where I can't do anything to get the bug to show up again. Again, all I've done is reboot the IDE, rebuild, and change the parens (in any order).

Do you think there is any significance to the fact that sometimes my objects in the Locals panel have random icons? (sometimes they look like a bunch of shapes in a tree, somtimes they are blue diamonds, sometimes they are pink)

[Steven_L_Intel1]

Blue and pink diamonds? Very strange.

[bruppel1]

Quoting - Steve Lionel (Intel)

Blue and pink diamonds? Very strange.

I'm sorry, maybe I'm not communicating clearly. The shapes are like boxes viewed from an angle, which I would call a diamond. I think this is a metaphor for an "object" in the visual language of the IDE. In the "Locals" window where variables are listed, I think normal variables get a blue box, and derived types (collections of variables) get a branch of objects icon, and I suspect that pink boxes are for pointers. My original point was that It seemed like the IDE would randomly mix and match what icons it is using for what between debug runs. I brought it up because I was wondering if my IDE was messed up, between this and the seemingly random errors in calculations. I installed the latest update, maybe that will help.

[Steven_L_Intel1]

I have never seen any differentiation of items in the Locals window along the lines of your description. Casn you attach a screen shot?

[bruppel1]

Quoting - Steve Lionel (Intel)

I have never seen any differentiation of items in the Locals window along the lines of your description. Casn you attach a screen shot?

Here you go.

[jimdempseyatthecove]

Although it looks cute, it is a waste of valueable horizontal screen space. The [+] should be sufficient to give you the hint that this is an object (not to mention the {...} on thr right).

Jim Dempsey

[Steven_L_Intel1]

Oh - I had never really noticed those before. They're added by Visual Studio.