Re: changes; modularization

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi David,

I think a well-designed, clean and simple core with a good NN would be a good 
thing,

There is a possibility of incompatible clients and file-formats though, but 
that's perhaps not the end of the world.

Personally, I'm going to add a category label to each question. I'm not 
interested in turning categories on and off, but before I throw all my 
databases in one big file, I want to make sure I can untangle them in the 
future if I want to. 

For that, I'll probably go the way of an XML fileformat and converter scripts. 
This means I'll have to give up KMemaid's nice GUI to edit items, but that's 
the price I'll have to pay ;-)

Peter

PS: Perhaps If you really want to make a simple core, you should rip out all 
the item loading and saving code out of the core too, and leave it to the 
front-end how to store it. That way you have a nicely separated core which is 
independent of the storage method and of the UI, which is good thing from a 
software engineering point of view.

On Thursday 16 October 2003 03:49, David Calinski wrote:
> Hi all,
>
> I removed categories from the core. I was very unhappy about the way
> they were implemented, and I just can't stand so many complications for
> categories that are almost of no use.
> There have to be another, simpler way - e.g. front-end can use multiple
> databases.
>
> I also removed, in the core, possibility to use "Forced repetitions"
> mode.
> Let me explain why I consider this mode to be bad.
>
> I designed MemAid to be a tool that allows to MINIMIZE time
> spend on learning by allowing anybody to make repetitions on *the most
> optimal* days (when an information is close to forget).
>
> Now, late repetitons are evil, they destroy the most optimal flow of
> learning. But it's really hard to avoid them - IIRC even in the first
> MemAid version (0.0.1) I implemented a basic algorithm to cope somehow
> with such repetitions.
> Late repetitions are evil, but MemAid *MUST* be able to cope with them.
> No doubts about it.
> We all may be late with repetitions (we may be
> on holidays without computer, or just don't have time for repetitions on
> a day.)
>
> "Forced ahead-of-time repetitions" are second evil.
> But evil that this time can be easily avoided (and was not present in
> earlier memaid versions) - just by not offering this "feature" to user.
>
> Yes, MemAid since 0.4.0 can cope much much better (NOTE: better =/= very
> well) with repetitions that are not on the "right time" - ANN can learn
> from such cases and ANN can give better intervals on them. But such
> repetitions still makes a lot of complications in code (e.g. see
> beginning of void move() in the old core - to really fix it here we
> would have to use (and save in elements.* files) yet another variable to
> count ahead-of-time repetitions and complicate code in more places
> yet.), and not only in code, but also horrible complication in the
> learning flow.
>
> And the most important is that such forced repetitions are of no
> sensible use in a software designed to MINIMIZE time spend of learning
> to the absolute MINIMUM while keeping retention MAXIMAL.
> There are some rare cases when the "forced repetitions" would be
> useful though (e.g. making repetitions before going for longer holidays
> without computer), but it's easy to make such routines outside the core
> - if anyone wants this feature.
> I simply don't want it in the core.
>
> Now, there are *many important* things to be done in memaid.
> Training ANN and ANN can be yet improved to give better intervals,
> faster learn from user, etc. - *this* is my area of interest in memaid.
> I want to make it better tool in when it comes to most optimal
> repetitions. I don't care about things I won't use (categories or other
> fancy stuff that bloats code and don't make memaid anything better when
> it comes to the basic idea of memaid use).
> If anyone wants a categories or any other things - feel free to write a
> module for memaid core. I would like to see memaid more modularized.
> E.g. I plan to write a module for statistics (e.g. stats.c) that would
> have much more statistical functions. There can be modules for
> categories, etc.
> A front-end maybe won't use fancy statistics - then it
> won't use statistics module.
> An another front-end maybe won't use categories - then it won't use
> categories module. Etc.
> I don't agree to bloat the core with everything, the core has to
> be "simple as possible, but any simpler".
>
> I should earlier write about it... but only now I realized
> that many things in memaid development are recently going in a direction
> that I don't like at all.
>
>
> Dave
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> SourceForge.net hosts over 70,000 Open Source Projects.
> See the people who have HELPED US provide better services:
> Click here: http://sourceforge.net/supporters.php
> _______________________________________________
> Memaid-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/memaid-devel

- -- 
- ------------------------------------------------
Peter Bienstman
Ghent University, Dep. of Information Technology
Sint-Pietersnieuwstraat 41, B-9000 Gent, Belgium
tel: +32 9 264 34 45, fax: +32 9 264 35 93
WWW: http://photonics.intec.ugent.be
email: [email protected]
- ------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/jmC+4dgPAIjyquoRAj/0AJ9uinAd+KZC/IFilrc+XfpbYVydowCglfFv
A8SEk5yXa4Din3CPZhBd0UY=
=/eD7
-----END PGP SIGNATURE-----



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php