Home

Previous Entry | Next Entry

[Code Friday] Daherh?

  • Jul. 27th, 2007 at 1:10 AM
cat - after teo rus, bad post!, sleepy goth, crossroads, money, mikage: go deeper, treason and plot, raahhhr!, asuka, O RLY? YS RLY!, bitch please, Angry Young Meredith, fat bob's novel, rose window, space hog!, sup fruits, oh really?, me!, gunpowder, doom, needs head!, native habitat, dehydrated water, brave, serious
Ten journalpoints and a cookie to whoever can come up with the best justification for the following code:
  for( i=0; i<2; i++ ) 
  {
    Kd[i] = (double **)mxCalloc(str1len+1,sizeof(double *));
    for( j=0; j<str1len+1; j++ ) 
    {
      Kd[i][j] = (double*)mxCalloc(str2len+1, sizeof(double));
    }
  }
I can just see the office conversation now:

TEAM LEAD: Jones, you keep forgetting to malloc() your arrays and we end up with segfaults all over the place.
DEVELOPER: Not this time! I malloc()ed those sons-of-bitches twice!

([info]cipherpunk, I am reminded of the infamous "if (j == 17) j = 17;" from the early days of Djinni.)

ETA: Oh, nevermind, it's frickin' 1:30 in the morning and I failed to notice the declaration of Kd as double **Kd[2] earlier in the source, not to mention the subscript in the first line of the for loop. Good thing I hadn't fired it off to the Daily WTF, though really, it wouldn't have hurt anyone to put in an explanatory comment. Subscripts are easy to gloss over sometimes.
  • Mood: amused

Tags:

Comments

( Leave a comment )
[info]feonixrift wrote:
Jul. 27th, 2007 08:22 am (UTC)
I've got a sinking feeling that I've written that at least once...

Problem is, some functions absolutely insist on an array of arrays instead of a normal multi-dimensional. So I can actually see creating a set of 3 a-of-as, calloced. I just can't see making them doubles, unless... badly implemented unicode? No, too obscure...

Graphics! There's a place where you can have excruciating pain... Hardcoding the 3 but not the other two dimensions... Well, them calling the things strings goes back to the unicode theory, but .. it's something that inherently always has 3 attributes. I say it's an array of polygons for rendering, the 3 attributes are dimensions, and the reason for the arse-wise format is underlying graphics library calls.
| Reply | Thread
[info]feonixrift wrote:
Jul. 27th, 2007 08:26 am (UTC)
Also, I'm a fool at this hour. 2 not 3. Ugly little piece of work though.
| Reply | Parent | Thread
[info]maradydd wrote:
Jul. 27th, 2007 08:32 am (UTC)
I can see that making sense, though I have yet to write any graphics code more serious than the silly toy things I wrote in BASIC (and TI-BASIC!) in high school, lo these fifteen years ago. The snippet above involves sliding windows (for substrings) over exactly two documents, so it does actually make sense that there would be exactly two 2d arrays, assuming of course that one is constrained to C.

It's late. I should be asleep. But of course I'm not.
| Reply | Parent | Thread
[info]feonixrift wrote:
Jul. 27th, 2007 08:37 am (UTC)
I will be shuffling data structures in my dreams thanks to this. *grins* I should be asleep too, instead I'm scrolling through transit maps.
| Reply | Parent | Thread
[info]stevenagy wrote:
Jul. 27th, 2007 12:13 pm (UTC)
Justification is that the first line looks like a bunch of smiley face variatons. :-)
| Reply | Thread
[info]cassandrasimplx wrote:
Jul. 27th, 2007 01:51 pm (UTC)
Well... it does seem like it would make good subtitles for the flashvid I never got around to making.

Remember "The Llama Song"? Okay, now did you ever see "The Dalek Song"?

I always wanted to make "The Dalloc Song"...

"Malloc, malloc, FUCK!"

Which was a really long way to go to explain why your code fits so nicely with it... Hope you enjoyed the ride.
| Reply | Thread
[info]cloakedwraith wrote:
Jul. 27th, 2007 03:11 pm (UTC)
So MxCalloc is MATLAB's calloc, though I'm not sure if that helps. It looks like you're preparing to do some analysis where you're working with pairwise combinations of str1's characters and str2's characters ... some form of hasing or differencing or regression analysis involving running averages, it's hard to say. You might be comparing two different algorithms, which is why you have kd[0] and kd[1]. It occurred to me that they might not be strings at all, since sizeof(char) is 1, and it's a common technique to use char strings to represent byte streams. I think they are string representations of something, though, because the strlen{1,2}+1 reeks of null-terminator.
| Reply | Thread
[info]cloakedwraith wrote:
Jul. 27th, 2007 03:14 pm (UTC)
"hasing" should be "hashing" ... I apparently can't type at 8 AM.
| Reply | Parent | Thread
[info]ilcylic wrote:
Jul. 27th, 2007 04:21 pm (UTC)
Heh. Good! I puzzled my way through it before I read your ETA, and was thinking to myself: "I dunno, it looks ok to me..." and wondering what was wrong with me. :)
| Reply | Thread
[info]cipherpunk wrote:
Jul. 27th, 2007 05:19 pm (UTC)
While you're busy whapping yourself over the head with a halibut as your penance for misreading the code, let me rant a moment about Type I, Type II and Category errors.

A Type I error is a false positive. "Oh, this code is just fine!" the coder says, even while there's God knows how many stack smashes present in the code.

A Type II error is a false negative. "Aaaah! You've malloced those blocks twice!"

A Category error is born from misunderstanding the dimensions of the problem so fundamentally that you are incapable of making real Type I or Type II errors. "Sure, C is a perfectly good language for systems programming..."

The older I get, the more I realize C is an albatross around the neck of systems programming... and such an albatross that not even C++ is much of an improvement. (C++ with an explicit "do not ever use the C subset without a damn good reason" is a major improvement. Unfortunately, most self-styled C++ programmers are really C programmers who are padding their résumes.)

Seriously. C is a language that makes the wrong details clear and obscures the right details. That's why you got dinged there--not because you made a Type II error so much as the fact that C is a Category error.
| Reply | Thread
[info]vatine wrote:
Jul. 27th, 2007 06:26 pm (UTC)
C is perfectly fine, as long as you know exactly what you're doing and never, ever, let your guard down. This describes an amusingly small proportion of programmers. It's OK when bashing at bits, but these days I find that I tend to write my bit-banging code in Common Lisp, because frankly it is better-suited for it.

It took me maybe 3-4 hours, total, writing code that read PCAP files, decoded from Ethernet down to TCP, UDP or specific ICMP, though I cheat and don't check the cheksum, I probably should, but...). Likewise, writing CL code that decoded the data files emitted by cflowd, at a speed that was within a factor of 1.5 of C, took me "a few hours" (I definitely spent more time testing the code, speed-testing and packaging than I did on coding).
| Reply | Parent | Thread
[info]cipherpunk wrote:
Jul. 27th, 2007 06:39 pm (UTC)
Sure, but by that logic, Assembly is perfectly fine, too.

I prefer definitions of "fine" that mean "I can worry about the parts of the problem space that need human intelligence and insight, and let the environment worry about all the other crap."

For me, my two preferred languages today are Python and Common LISP. (I started out in the pre-CL days, so forgive me my anachronistic capitalization.) CL has some major problems when it comes to creating distributable images, which means I mostly work in Python.
| Reply | Parent | Thread
[info]vatine wrote:
Jul. 27th, 2007 07:45 pm (UTC)
Assembly is perfectly fine with the same provisio as C. Most people let their guard down at times and are usually less sure of the standard than a perfectly implemented compiler and it's fine only as long as they never relax and know the standard to the T (and ideally every single exception in all compilers that will ever compile their code).

I used to do Python at work, since it was (in general) faster to get working code than C and (most important) easier for co-workers to maintain Python than CL. The flowd-decoder was in CL, but that was because Python wasn't fast enough (neither on decoding the data nor stuffing ito databases nor doing analysis on the data afterwards). I guess a decent Python-compiler could've done the trick.

Hm. I think I started coding lisp before CL, too (XLisp 1.7, back in 1988-or-so, onoy started coding C in 1990-or-so, but I had pre-existing Pascal-damage).
| Reply | Parent | Thread
[info]cipherpunk wrote:
Jul. 27th, 2007 08:14 pm (UTC)
Depends on how you define "before CL", I guess. ANSI X3J13 began meeting in 1986, but the language wasn't standardized until 1992. I predate X3J13; I started on Symbolics LISP machines in 1982.

Hell of a long, strange trip. :)
| Reply | Parent | Thread
[info]vatine wrote:
Jul. 27th, 2007 09:36 pm (UTC)
Had I gone to uni at a normal age instead of half a decade later, I would've had even chances starting with Interlisp-D.
| Reply | Parent | Thread
( Leave a comment )