This is WIERD

[J-G]

Missed an opportunity to optimize  Tan_X  as  Sin_X / Cos_X 

  I did think about it but only after I'd already written the proc..     I'll probably do that during a 'tidy up'.

But seriously, where are your variable definitions? What are their types? Which units does your program use? All these questions could be avoided by posting a compilable example 

You'll now see that I have in fact made the full code available  - - - -  but I doubt that how the variables are defined is of any real consequence.

[J-G]

D'Oh !

It would be beneficial if I'd posted a link to my site !!

www.crescentcomputing.co.uk/LAZ

[wp]

First of all, when you post your code on some external site it can be gone at any time, and any user coming across this thread will not be able to see it any more.

Second: your code is not compilable, your lpr file says that your projects depends on a unit tri which is not included. The easiest way to prepare a project for submission to the forum: Open the project in the IDE, select "Project" > "Publish Project" -- this creates a zip of the project files needed. Then upload the zip here under "Attachments and other options"; there is a size limit of 500 KB, but this should be more than enough since the "publish project" command automatically discards compiler-generated files, in particular the large executable.

[J-G]

You can tell that 'publishing' is not a thing I've needed  to do in the past 

No matter - the .Zip file is attached (105k)

I'll not be watching for the next 2½ hours - I have a rehearsal.

[MathMan]

@J-G

Unfortunately I don't have a cross compiler available, so I had to change the target from i386 to x86_64. My comment should be taken with a grain of salt due to that.

I looked at the generated assembly for 'Find_A' (the offending function). The calculations are identical and at the moment I'm at a loss to explain how this could yield different results for 'A' or 'D' from the source.

So either you have a side effect in your program (not an unreasonable assumption due to the way it is organised). Or the target architecture i386/win32 (which I cannot test) is doing something strange with this calculation.

Question: can / did you compile for a different target architecture (e.g. x86_64) and did the error persist?

Now I'm off for some time.

[Paolo]

What is this formula ?

Code: Pascal  [Select][+][-]

1. A := Sqrt( B2 + C2 - (2*B*C * Cos(alpha)))
2.  

If you erroneously did

Code: Pascal  [Select][+][-]

1. A := Sqrt( B*2 + C*2 - (2*B*C * Cos(alpha)))
2.  

This gives 0 for your input values

[emersonline]

Can confirm the problem for 32bit target. 64bit target works just fine. It's seems related to compiling optmizations. Testing this way it works on 32bit:

Code: Pascal  [Select][+][-]

1.        
2.         {$O-}
3.         D := Sqrt((b*b + c*c) - ((2*b*c) * cos_a))
4.         {$O+}
5.  

[tetrastes]

Cannot confirm for 32 bit fpc 3.2.4-RC1 and trunk from 2026/03/03.

[J-G]

What is this formula ?

Code: Pascal  [Select][+][-]

1. A := Sqrt( B2 + C2 - (2*B*C * Cos(alpha)))
2.  

If you erroneously did

Code: Pascal  [Select][+][-]

1. A := Sqrt( B*2 + C*2 - (2*B*C * Cos(alpha)))
2.  

This gives 0 for your input values

Certainly no error in that regard - for the sake of clarity I'll attach a .PNG showing the formula in 'normal' mathematical notation :

I could have done Sqrt(Sqr(B)+Sqr(C) . . . . .  of course.

[J-G]

Can confirm the problem for 32bit target. 64bit target works just fine.

Well that's a little 'comforting'  at least   

It's seems related to compiling optmizations. Testing this way it works on 32bit:

Code: Pascal  [Select][+][-]

1.        
2.         {$O-}
3.         D := Sqrt((b*b + c*c) - ((2*b*c) * cos_a))
4.         {$O+}
5.  

Doesn't change anything for me.

I've also tried c86_64 - both with and without the override but D returns ZERO in all states.

[J-G]

Hmmm . . . .

"Curiouser and curiouser!" cried Alice  !!!

I've now put in a single line to display the result from the [Find_A] proc.  (rather than using a Breakpoint)   -  both A & D -  and it now returns 5.19615 for both   ???? 

The only thing that I've done is test it with the Target CPU Family set at x86_64 and returned it to i386.

[emersonline]

I think we both made the same mistake: stoped the debbugin too soon. The cursor jump from the formula line to the end of the block, D still zero. But, steping again, it goes back to the formula and calculates correctly. I was stopping debbuging right after the cursor reached the end.

[J-G]

!!!  I think that you have found the reason @WP !!!

I did notice that I had inadvertantly missed the semi-colon - which as you note is not demanded before the [End]  but when I added the line to display the result on screen then the semi-colon did become imperative !

Adding the Debug Note therefore also made 'D' have a need for resolution - et Voila !

I did start this thread by suggesting that the action I was seeing was 'Wierd' 

I think that I'll go back to leaving the semicolon off (and comment out the Debug Note)  to see whether it makes 'D' return Zero again . . . .

[J-G]

!!!  I can confirm that without the (apparently not demanded) semi-colon,  'D' is NOT resolved so retains it's previously set value.

I can switch the result on and off simply by adding or omitting the semi-colon !

Notwithstanding the fact that I am well familiar with the principle of debugging, your detailed explanation @WP will no doubt be very useful to others who may come across this thread.

It is my custom to always use the semi-colon at the end of any statement - whether Pascal demands it or not - so this 'problem' only arose because I wasn't my usual fastidious self.

Thanks for all the input, I do hope that it proves useful to any new programmer that happens to come across this thread.


EDIT  -  What happened to @WP's post ??

[wp]

EDIT  -  What happened to @WP's post ??

I had deleted it after seeing emersonline's message which told me that my idea of the "optimized-away" expression with unused result was nonsense.