XKCD was interesting today - Page 1
Forum section: electronics / general

author: DJPhil
author_rank: Frequent Contributor
timestamp: April 22, 2010, 12:39:52 am
content: I'm sure some of you have heard of the webcomic XKCD. Today's was a good one for electronics, and I thought you guys might enjoy it.http://www.xkcd.com/730/#I think my favorite bit was the arena.

author: GeoffS
author_rank: Unknown
timestamp: April 22, 2010, 01:01:09 am
content: I was going to make it but my local supplier is all out of flux capacitors

author: David
author_rank: Frequent Contributor
timestamp: April 22, 2010, 12:50:38 pm
content: That would make a nice t-shirt!

author: JoeB83
author_rank: Regular Contributor
timestamp: November 16, 2015, 06:25:36 am
content: Quote from: wilfred on November 16, 2015, 05:15:49 amThat's a good one.

author: AlfBaz
author_rank: Super Contributor
timestamp: November 16, 2015, 02:25:58 pm
content: hit random a few times and came across this... would been handy in that thread we had about using goto

author: free_electron
author_rank: Super Contributor
timestamp: November 16, 2015, 03:11:47 pm
content: I don't understand the fuss about the usage of 'goto'.even the most 'properly' constructed code will compile down to using JMP instructions. which is nothing more than a goto.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: November 16, 2015, 03:20:29 pm
content: Not necessarily true -- although I don't know of any languages which compile semantic constructs into e.g. function calls. That is, putting the inner braces of each execution path into their own functions. And by function, I mean, using CALLs instead of JMPs.But the higher level semantics are much more valuable than the machine code that implements it, at least for average development. In this post-computational-abundance world, the programmers' bandwidth is the limiting factor. (Well, almost. One would hope. Of course, more computing power always means bigger and slower high level libraries, or scripting languages. So...)And, that said, I would enjoy if assembler were designed with indentation in mind. Many (older?) assemblers won't even accept it -- they expect strict whitespacing. That makes it very hard to read and write structured code. Usually, big comment blocks are used.Tim

author: AndyC_772
author_rank: Super Contributor
timestamp: November 16, 2015, 03:24:52 pm
content: gotoxkcd

author: ECEdesign
author_rank: Regular Contributor
timestamp: November 16, 2015, 07:08:40 pm
content: Quote from: wilfred on November 16, 2015, 05:15:49 amIf you hover over the image on the website it says:"The last band of color indicates the snake's tolerance for being held before biting."

author: rolycat
author_rank: Super Contributor
timestamp: November 16, 2015, 07:59:13 pm
content: Yesterday's strip was good, and (somewhat) electronics related:The most powerful hand-held torch (flashlight) I could find is the X-LED XHP DualBeam, which the manufacturers reckon is 50,000 lumens.They are apparently working on a 1 million lumen LED light, but since this will consume 5 kW you probably won't be able to slip it in your pocket.

author: AF6LJ
author_rank: Unknown
timestamp: November 16, 2015, 08:58:27 pm
content: Quote from: DJPhil on April 22, 2010, 12:39:52 amBeen around for a long time but still funny as hell.

author: IanB
author_rank: Super Contributor
timestamp: November 16, 2015, 09:00:03 pm
content: Quote from: rolycat on November 16, 2015, 07:59:13 pmWell, put two 28 V power tool batteries in series and that will give you 56 V. Such batteries can comfortably supply 100 A, so there's 5 kW. More lantern sized than pocket sized perhaps, and it won't run for very long, but it would be cool on a dark night.

author: kfitch42
author_rank: Frequent Contributor
timestamp: November 16, 2015, 09:20:37 pm
content: Quote from: IanB on November 16, 2015, 09:00:03 pmA quick google told me that the Makita 28V battery is 3.0Ah. So, we are talking less than 2 minutes at 100 Amp. I am guessing these things aren't designed for continuous operation at 100A. So, hopefully they won't last long enough to heat up to thermal runaway...But, at least you will be able to see what you are doing while jump starting a big diesel truck:

author: tszaboo
author_rank: Super Contributor
timestamp: November 16, 2015, 10:39:39 pm
content: Quote from: free_electron on November 16, 2015, 03:11:47 pmBecause memory leak, and dinosaurs.BTW if you want bright flashlights, try them with Maxwell supercapacitor banks. 75V 1800A from something that fit into a backpack.

author: HackedFridgeMagnet
author_rank: Super Contributor
timestamp: November 16, 2015, 11:30:21 pm
content: Had this one on the fridge. My son was fascinated by it even though he was young and didn't know what SQL was.https://xkcd.com/1133/Is currently on the fridge:

author: suicidaleggroll
author_rank: Super Contributor
timestamp: November 16, 2015, 11:45:53 pm
content: In addition to the above, I like these ones:and

author: Delta
author_rank: Super Contributor
timestamp: November 17, 2015, 12:03:38 am
content: Quote from: AndyC_772 on November 16, 2015, 03:24:52 pmWell played, Sir.Well played!

author: rs20
author_rank: Super Contributor
timestamp: November 17, 2015, 12:21:06 am
content: Quote from: NANDBlog on November 16, 2015, 10:39:39 pmIronically, I have a soft spot for goto in one particular usecase:preventingmemory leaks on error conditions (athough I don't use it in this situation professionally, and I generally abhor goto in every other case). Example:Code:void main() {FILE* f1 = fopen( ... );if (f1 == NULL) {printf("Failed to open f1\r\n");return;}Object a = makeObject();if (a == NULL) {printf("Failed to make a\r\n");goto finalize_f1;}...if (nasty.error()) {printf("Ouch\r\n");goto finalize_a;}...finalize_a:a.finish();delete a;finalize_f1:fclose(f1);}Obviously in this case the Object could have been allocated on the stack; but it's more the problem of issuing cleanup method calls like close() -- which may well delete objects internally. Of course more featured languages have things like thedeferblock, which is one of many ways to avoid this pattern.

author: IanB
author_rank: Super Contributor
timestamp: November 17, 2015, 12:43:15 am
content: Quote from: rs20 on November 17, 2015, 12:21:06 amIn C++ the RAII pattern can be used to good effect where resource cleanup should happen for all exit paths including errors and exceptions.

author: rs20
author_rank: Super Contributor
timestamp: November 17, 2015, 12:45:33 am
content: Quote from: IanB on November 17, 2015, 12:43:15 amIndeed, I really like RAII, although it's not available in pure C of course. I've been meaning for a while to see what the overhead for using C++ on AVR is...

author: Delta
author_rank: Super Contributor
timestamp: November 17, 2015, 01:22:48 am
content: I'm just learning C, so don't have a clue, but...I fully understand that abusing goto can result in awful spaghetti code, but the "thou shalt not us goto under any circumstances" mantra seems almost cult-like!

author: JoeO
author_rank: Frequent Contributor
timestamp: November 17, 2015, 01:27:09 am
content: Quote from: Delta on November 17, 2015, 01:22:48 amC code can be written without using GOTOs.

author: Maxlor
author_rank: Frequent Contributor
timestamp: November 17, 2015, 02:31:52 am
content: Quote from: Delta on November 17, 2015, 01:22:48 amYou can break the rules once you've mastered them, but not before. It's neither a mantra nor cult-like, it's just something meant to preserve as much global sanity as possible.

author: Delta
author_rank: Super Contributor
timestamp: November 17, 2015, 02:53:10 am
content: Quote from: JoeO on November 17, 2015, 01:27:09 amI'm sure it can be written without using a lot of things! So surely that's not a reason by default.I have read a fair bit about this on stackexchange and other sites, and it seems that people will go to (pun not intended, sorry) extreme lengths, writing convoluted code, just to avoid a goto! That's when it seems to me like more dogma than engineering!

author: Delta
author_rank: Super Contributor
timestamp: November 17, 2015, 02:54:27 am
content: Quote from: Maxlor on November 17, 2015, 02:31:52 amI am looking forward to that day!

author: IanB
author_rank: Super Contributor
timestamp: November 17, 2015, 03:26:27 am
content: Quote from: Delta on November 17, 2015, 02:53:10 amOne of the most important things about good code is that the algorithm and logical flow should be clear to a human reader. Inappropriate use of goto's can go against this, which is why goto's are frowned upon. If an occasional goto is used in a clear and logical way, for example to jump to an error handler, then that should not be seen as a problem.

author: Delta
author_rank: Super Contributor
timestamp: November 17, 2015, 03:45:27 am
content: That's my understanding, Ian. But it seems a lot of people think that goto should categorically not be used, at all, ever. That's what seems daft to me.

author: hamster_nz
author_rank: Super Contributor
timestamp: November 17, 2015, 04:08:14 am
content: Quote from: IanB on November 17, 2015, 03:26:27 amI pretty much agree a 'goto' is a special tool for a special case. Could it be that source code has inherently one-dimensional aspects to them (the flow of the program counter / instruction pointer through the code, the way the call stack works), and a goto works against this mind set by allowing unstructured jumps?I've never seen anybody say that flowcharts are bad, as they allow you to draw arrows across logical boundaries, maybe they need a rule that you should never 'cross the streams'?Neither in formal state transition diagrams, where you can jump between arbitrary states however you see fit. When you convert a FSM to code you basically end up with spaghetti.I definitely remember the "no goto" rule being around in the early 80s in the time of structured BASICs, PASCAL and COBOL... Maybe a lot of it is hangover from old languages where your GOTOs used the line number as the target for jump, rather than a label. Those days were really nasty - if you renumbered code you could shoot yourself in the foot sooooo badly. These days the destination for a goto is has limited scope, and so at least it has a bit of structure to it.One C coding standards I had to follow in the 90s recommended this construct for processing errors:Code:void some_func(void){do {if( ! something_that_might_error() ) /* e.g. malloc or fopen() */break;if( ! something_else_that_might_error() )break;<do the real work>return 1; /* Success */} while(0);<error handling code>return 0; /* Failure */}It was a poor man's way of exception handling, or abusing C to give 'goto' like functionality without actually using the word.Anyhow - just idle musings rather than me saying anything of any value.

author: suicidaleggroll
author_rank: Super Contributor
timestamp: November 17, 2015, 02:49:51 pm
content: Quote from: Delta on November 17, 2015, 02:53:10 amGo spend a week debugging/flowcharting an old FORTRAN 77 research code written by a scientist. You'll light your hair on fire and run out of the building screaming before you make much headway, but from then on every time you see or write the words "goto" or "common" in any program in any language, it will give you a mild case of PTSD.Using one here or there for error handling/cleanup is fine, but it's too easy to fall into their "lazy" trap and start using them WAY too liberally, which ultimately ends up making the code nearly impossible to read or debug. It's best to just avoid them altogether, at least until you have a good grasp of the damage they can cause and know ways you can avoid them while maintaining readability.