Re: a slightly updated rpm spec file for Ger Hobbelt crm114 branch

On Sun, Feb 1, 2009 at 2:59 PM, Paolo <[email protected]> wrote:
> no? s**t :( ... what a shame. We ought to be there, every popular sw
> features a long list over there, the longest the more popular it is.
> It's for sw what facebook is for humans these days - if you'ren't (listed)
> in there and haven't your long (CVE) list of floobydust, you just
> don't exist - likewise for sw, no CVE entries? nobody's gonna talk about
> it.
> Really, CVE-like listing turns out to be (also) another marketing tool.
> What about putting in some easter-egg? some dbl-free()? some null-pointer?

Really? I always understood you'd rather /not/ show up there, unless
you'd like to present yourself as the proud creator of crummy
software. So /that/'s what I've been doing wrong all the time.

CVE list == facebook? Yes, verily. facebook for bucktooth fairies, that is.


> yeah, it'd be a pity that such a crm114, sitting there to crunch SM feeds
> and uncover the magic predictor(s), stumbles on an 'internal error' and
> swaps buy/sell actions ;)

Par example. Or you get a server stuck on a particular bit of data
because crm114 coredumps on it and you can't find out why, because
there's no error to be found anywhere. After all, errors are a
nuisance so the /best/ thing to do is ignore them. Ahhh, nice and
quiet. No error log anymore. Blisssss! (Or was that: kiss? Me
confused.)
Happy happy, joy joy.

> maybe the public is taking care of it? ;) - ie seems that lot of people feed
> many GB / day through crm114-powered filters; occasionally somebody catches
> some weird stuff in the logs and reports to the ML.

Or ditches the tool and moves on to the next. Bug reports sitting
around make that a very sensible move.




> The problem is, that - besides platform-dependent oddities - it's
> programmable, some are using it with just the basic LEARN+CLASSIFY,
> while others use complex crm scripts, so several levels (or classes) of
> errors add up. Not the most favourable situation to devise a robust test
> vectors set.

Testcoverage wise, maybe, but a good test series for the most common
use is already a big improvement over the crude 1-2 check.

>> libcrm114 is a real boon (language add-on!) as well as they don't need
>
> see Fidelis' approach ...

Yup.

> yes, and no: that's the old point of fully modularizing it, like the
> (now only) compile-time classifiers-list option - just add the crm-engine
> as module. But once you've torn it apart into its little components, it'll
> be a nice option among a host of others for experts, and little interesting
> for many others. Not everybody interested in stats/data mining/whatever
> grok some prg idiom, esp these days with abundant computing facilities; in
> this scenario, the stock crm114 is a small & fast, self-contained 1-stop
> solution for such tasks, and once you get reasonably used to crm, you can
> use it ~same way in a few platforms.

So? I don't hear an argument for file-based here. crm114 as it is
remains a wrapper (and primary sample application) around the core:
libcrm114, and then you have what you got before/now so you can go on
using that when you like/want, and the core is usable in a slew of
other domains as well. So it's still a 1-stop shop for those who like
it to be.
Besides, what's the problem with writing a mem+callback-based core
like that? Is it that hard? Nope. Take the current code and the
memory-based core is already in there: cut out the script and mmap
generics in each classify and learn function, dump then in an outer
call layer and you're it. All that remains is kick out the
fprintf(stderr) diag lines through a log callback and Bob's your
uncle. Feed it data piecemeal instead of fullsize at once like it gets
today? Doable, but then you'll need to fold the big honkin' outer loop
in each of those inside out and that may take a little more wits than
there's on call.


>> GerH is a fork. And apparently, that's official.
>
> there's nothing wrong with that.

Indeed. Though forks tend to cost more in the grand scheme of things
and I'd rather not have that. So be it.


-- 
Met vriendelijke groeten / Best regards,

Ger Hobbelt

--------------------------------------------------
web:    http://www.hobbelt.com/
        http://www.hebbut.net/
mail:   [email protected]
mobile: +31-6-11 120 978
--------------------------------------------------

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword