OK... I failed to do it in my head, but worked it out in text below then checked it in Excel ... and still was wrong so made I the needed corrections (2 errors compounded) to my text So... I'm dumber than a 19th century schoolboy, but it was a fun exercise any way. I used to do all my math in my head before we had pocket calculators (yes I'm an old fart) I need to do more of this kind of thing to get that back. 0 times 10 is 0 plus 100 is 100 1 times 11 is 11 plus 110 is 121 plus 100 is 221 2 times 12 is 24 plus 120 is 144 plus 221 is 365 3 times 13 is 39 plus 130 is 169 plus 365 is 4 carry the 1 and 2 plus 1 for 3 carry the 1 and 3 plus 1 plus 1 is 534 4 times 14 is 56 plus 140 is 196 plus 534 is 0 carry the one and 2 plus 1 for 3 carry the one and 5 plus 1 plus 1 is 7 for 730

It's still relevant! In fact I've been looking for a copy of this! I'm a manufacturing engineer in the automotive industry. It's impossible to get people to keep their hands to themselves. If you put a button on something, someone's going to poke it just to see what it does. Knobs are worse! In fact at one time I disconnected the wires from a speed control knob and wired in a plain old resistor so it would run at the correct speed. Left the knob in place, the operators continued to adjust it from shift to shift certain they could produce more parts with their settings. (upstream operation had a fixed cycle time) Now with PLC's we can eliminate most buttons and knobs, but you still have to prevent access to sensitive settings. Passwords get written on the panels or shared, physical keys end up in known locations etc. We've gotten to a point now where we have to control access by employee ID badge.

Please clarify your question... you had said you have mastering parts of known diameters. If this is the case then yes getting the angle is simple if your looking for the angle between the sensor direction and the center of the object. You can find this angle for each sensor, but you can never know anything about where the sensor is positioned around the objects being measured without another point of reference.

This seems very simple unless I'm not understanding the question? BTW... your either saying circumference when you're actually meaning diameter, or you need to find the diameter from the circumference C=D*PI All you're asking for is the angle of each measuring device vector relative to the center of the cylinders, "NOT" the position of the measuring device. It becomes a simple triangle problem... so what do you know? You know the lengths of all 3 sides of each triangle (one for each sensor). 1.) The first two are the radii of the cylinders, you know this ahead of time (diameter/2) 2.) The third length is the difference between the 2 measurements from the individual sensor Knowing the three lengths, and being unconcerned with orientation/position you simply trig out the 3 angles of the triangle.

Thank you Dave, While frustrating, your advice is not at all unexpected and is much appreciated.

Bill, Thank you for your posts! I did find the "learn the language" response frustrating, mainly because if math can be coded to run on a computer (and in the case of fractals MUST be run on a computer) how and why is the Greek even helpful? That being said, I can work through the Greek and figure out how to get it into code form. In my reply to that post I admitted my best hope is to spend the $60 and just buy the book. I truly appreciate the links you provided and have been using those resources as much as possible. I used to spend a lot of time on fractal forums back when I was wrote a raytracer for 3D flame fractals.

Thanks Dave, Maybe I should have been more clear, I can decipher the Greek however it's very painful, I read code much better than symbolic. If as you say symbolic is the only way to get there I can do that. I have had some success generating Kleinian fractals in 3D, but the Googleable information always seems to be incomplete. I guess I'm going to have to break down and buy a copy of "Indra's Pearls" it's just hard to justify the $60 price tag.

I'm a C# programmer who loves fractals! I've spent days trying to figure out the math behind Kleinian group fractals with no success. There are a lot of Mandelbulb3D parameter sets available (as well as UltraFractal, Fragmentarium and other fractal applications) But I really want to understand the math itself, and the parameter sets really don't help Here are a couple of beautiful examples: https://www.deviantart.com/sabine62/art/Tentacle-653134425[^] https://www.deviantart.com/schmiegel/art/Kleine-Abschnitte-659324989[^] I've found a lot of scientific articles on Mobius transformations, spherical reflection, and elaborate sounding stuff like "Quasi-Fuchsian", but it's bits and pieces here and there. I can find and have figured out how to calculate the curvature of a new circle tangent to 3 other circles, but not how to calculate the center-point of the new circle. I've about worn google out I think.... does anyone know of a good resource for how to create these fractals in language for a programmer who's not a mathematician? I know I can do the math with the right resources to learn it, I just can't read symbolic math (i.e. Greek symbols) Thanks in advance! Don [Irrelevant link deleted]

OriginalGriff wrote:

I tend to see what I meant to write, rather than what I did

Yup that's me! As an answer: I haven't gone further in the thread, but at first glance the FALSE comes from comparing 2 different instances, where the TRUE result is comparing the same instance to itself? Fix: the first comparison is not necessary

As a manufacturing engineer AND application developer, I would compare code to machine design. What I explain to tooling and equipment suppliers is, if your quote has design (code) charges we (the customer) own the design making it proprietary to us the customer. If you the supplier want to own the design (code) specify in your quote that the design is proprietary and show me, that we the customer, are not paying for design time.

To the original post... I'm so sorry to hear your dilemma, I've never gone to college or even taken a course on programming other than the SAMS "Learn Java in 21 days" book. I can highly recommend this book, from that base starting point I've gone on to learn C#, SQL, VB, js and many other tools. Learning to program is basically learning to think logically, nothing more. Language and syntax are tools, but they do you no good unless you can break down a problem into logical steps. Once you know the steps you can find the syntax. I will also say understand why you want to write programs, in my case my hobby is art and graphics (3D), but I wanted to do things that the applications available couldn't do, or wouldn't let me do. So I started writing my own programs, when I was finally able to do the things I wanted... I was hooked! My career took a completely different path, I became a machinist, then tool maker, got into CAD, then 3D CAD, started designing machines and processes, then became a manufacturing engineer. Along the way, as I needed to solve problems or analyze data, and the available tools (software) wouldn't do what I needed, guess what.... I made my own. I give you all of this because "why program" is a bigger question than how. Find a problem to solve, then figure it out. "Figure it out" is a matter of patience and tenacity more than knowledge or skill. Start small and simple then expand on that a little at a time. I'll be happy to help explain variables, OOP, and loops, and anything else you may need if you decide you really want to learn programming, but you first have to answer the question of "Why program" for yourself.

Every job, whether or not it is coding or something else like building industrial machinery (I do both), comes with this issue. The key is not to complain. Constructive criticism comes in many forms, but the way you do it will determine how you come across. Bear in mind, I often forget these tips myself 

• First don’t single out specific instances, but look for common practices that can be improved. “Each programmer does their class naming differently”

• Rather than point out what’s wrong, provide systemic solutions. “Should we develop a common naming convention?”

• State your solutions as a question whenever possible, “do you think this would work?”

• Acknowledge what’s good about the problem code “This is great at consolidating the information, but if we restructure the data this way…, it would be easier to understand.”

• Do the work to fix the problem, then share/explain what you did and why you did it.