No problem! "I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!

I initially thought you'd miscounted and it was 11, not 13! :-D "I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!

Stefan_Lang wrote: maybe he's working in the software department? Ah, so he gets computer breaks and coffee breaks! <jealous as Hell> What a cushy number! </jealous as Hell> I wanna be a eunuchs developer! Pass me a bread knife!

We have a winner!

Because that would be an ambiguity in one of the few places where ambiguity would break the system. By and large, C# is really good about supporting abstractions. One of the main reasons for this is that the whole thing is underpinned with stringent structural rules in terms of where and how code is loaded. These rules, which include namespace definitions, make the entire idea of dynamic module loading work without a bunch of odd checks and locks. An ambiguous namespace definition would break this system. Do I want System.Timers or System.Threading.Timers? The APIs are different, so if I load one ambiguously, I'd need to do some type checks before using anything from it an likely set aside some buffers and concurrency control while making the determination and loading the code. Or I can just type: using System.Threading.Timers; Side note: ReSharper automatically detects namespace issues and can automatically correct them for you. "Never attribute to malice that which can be explained by stupidity." - Hanlon's Razor

Well it wouldn't take much to stump me, but I would be highly impressed if you managed to stump the regulars for a whole three days! I look forward to your attempts :-D

Luck of the draw I guess - it was probably a very close thing. Good clue though! Sent from my Amstrad PC 1640 Never throw anything away, Griff Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!

It was: @walterhevedeich I think he forgot ... he can be up tomorrow then ... :laugh: Sent from my Amstrad PC 1640 Never throw anything away, Griff Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!

Thufferin thuccotash, me too! I wanna be a eunuchs developer! Pass me a bread knife!

"Danger, Will Robinson, Danger!" Sent from my Amstrad PC 1640 Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!

He/she forgot to mention that this is about setting the baudrate.

While PI = math.asin(1) * 2 may be mathematically correct, it's probably not the most accurate representation of π you could create. It depends upon the arcsine function implementation. You might get lucky in case they shortcut the value for an argument of 1, and simply return the library's value of π. If not, they're going to do the arcsine calculation using a numerical method that will approximate something close to π. In other words, it would be more precise if the library simply gave you its value of π. For casual calculations, the difference may not matter. If you're doing a simulation, having your value of π off by a couple bits could have long-term consequences. Software Zen: delete this;