Older blog entries for chaoticset (starting at number 16)

My SO and I were discussing the *ahem* "future" of my attempts at getting IT work. We discussed the possibility of setting myself up as a small business within the next 4-9 months. (This would bring a lot of advantages, but I'm still sussing out the disadvantages, which include tax issues and whatnot.)

One of the surprising things that fell out of her mouth was "...and we can look at getting Greg certified for some stuff..."

Now, I'm Greg, and I haven't been thinking seriously about getting certified for anything, frankly. I asked her what she thought I should get certified for, and she rattled off a couple of things -- Java (whatever that's called), A+ possibly, a couple MS operating systems, etc.

Now, while I'm not really opposed to the idea, I am curious. Anybody have any definitive statement on whether or not certification convinces anybody but the people who give the certifications that you're any good?

Realistically, is it financially worth it, or would I be better off taking the money it costs to get certified on X and throwing that into paying myself to learn about X (once, of course, there's money to pay myself with)?

She also talked about getting certified for some stuff herself, but it would all be financial stuff -- tax preparer, etc. -- so it makes sense. The financial world is rife with certification this and qualified that, and it would make a lot of sense. (It would also help me learn how to write financial packages. Someday, I'd like to be able to write a drop-in replacement for, say, Quickbooks. That would make me really, really happy for reasons that -- if they aren't obvious to you -- would probably make no sense.)


As part of the New Crazy Idea (which I have no name, notions, etc. for as of yet) I'm building a Pretty Random Content generator (PRC generator, if you will).

What's it do? Not a whole lot. Not really a generator, now that I think about it -- it's a retrieval device. It's going to browse randomly within a nonrandom set of things and build concept maps out of what it finds. I haven't the faintest notion what the hell I'll be doing with this, except that it will be very crackfuelled.

Well, I've spent a big pile of time away from here. Unfortunately, it's mirrored in my relative lack of actual development.

I've hit a big stumbling block with the fuzzy module, so I shelved it for a little while. Good news -- the game matrix solving module I wanted to write ages ago is now within my grasp! I've finally comprehended the general method for solving games outlined in _The Compleat Strategyst_ and can attempt to code it.

Once it's in place (inefficient though it will be for very large matrices), I can look at optimizations. Probably the major one will be removing what appear to be crappy strategies for each player if obviously crappy strategies are there. (The analysis for that will probably get prohibitively complex quick.) Another one could be a reduction in resolution (rounding off a lot of the numbers and then caching results would help if there's a whole lot of values to run.)

Anyways, it's good news. On the bad side of things, I have no real chance for employment.

How often does one find themselves working on multiple projects at once, leaving some for a time (even weeks or months) before touching them again?

I'm trying to find out if I feel okay with the idea, or if it's some sort of slippery slope to slackerness.

Okay. Some time with a pad of paper and some Dew has produced the following rough outline of subroutines:

  1. included -- takes the incoming value and returns firing rules and percentages of inclusion in a hash
  2. fire -- takes that hash and returns the graph points for the resulting rule intersection

I'm already working out a sub called get_midpoint that takes an incoming set of graph points and produces the X value of the vertical line that would divide the shape defined by the set of graph points into two equally large shapes.

Those three combined will take the value from a set of firing rules to a graph to a final scalar value.

More math. I have a solution for the midpoint that involves a whole bunch of odd terms and whatnot, so I have to find some slightly more advanced algebra resources to determine how to resolve that to one side clean, one side icky but solvable.

Frustration about the math model is building, and I'm going to log off and spend some time with my old friend pen and paper to work the kinks out and get the proper formulas translated into Perl.

This math model may be wrong, it may be totally wrong, it may be completely counter to what Kosko meant when he wrote the damn thing, but by Chao it is going to sing and dance when I code it up.

Okay, despite every worst effort on my part I've managed to locate the heart of this thing. It's the curve-calculator that I'm about to write, and was previously an ucky thing that deviated behavior based on the number of incoming points.

Translation: I've started to work on the general method that will actually work, instead of the hacky-specific method that didn't really work at all.

I'm demoralized but I'm going to fix things later today.

The new "average" is going to be the midpoint in terms of area, the bisecting point, instead of what had previously appeared to be correct (which was the point where the curve is "average").

I wish I wasn't such a math doofus sometimes...


Apparently I have botched the implementation of this model so badly OR I have misunderstood the model to the point that this thing is, as stands, completely unusable.

My worst nightmare is true -- I've modified things so that right-triangle rules can be handled the same way as isosceles triangle rules, but there's one firing position that produces a curve well above the average.

This can't be right. It's got to be half the volume on each side, otherwise these results can't possibly exist in some cases. Having said that, I'm going to recode it tomorrow that way.

7 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!