Re: [Myfu-discuss] plans

[Jason P. <ja...@bo...>]

> Doing fun stuff sounds lots more, err, fun, than cleaning up utility
> code, so I agree with putting that on a back-burner.  The first fun
> thing I'd like to tackle is 3lp siqs.  I'm going to try to figure out
> what format relations need to be stored in in order to make use of the
> filtering code for that.  Jason or Jayson: any pointers as to where to
> look first?

The filtering code uses a filter_t structure to control setting up
and postprocessing the complete dataset, and a merge_t structure for
building up sets of relations. The code in gnfs/filter/filter.c uses these to
call the top-level functions in common/filter. Basically once you get
your relations into the algorithm-independent format, i.e. a packed list
of relation_ideal_t structures, the rest of the filtering code should
work unmodified for SIQS relations. Most of these structures are described
in common/filter/filter.h

> In other words, when we can show (through testing) that we have all of
> the capabilities of either program then it would be ok to release v1.0
> and start working here full time.  Thoughts?

I think the first thing we really need is workalike applications for
YAFU and Msieve, i.e. a yafu.c and msieve.c application that each call
the new library and have an interface identical to the old versions of
those tools. If the respective user communities don't see a difference
in the command-line applications, then we can do whatever we want to the
library internals and everyone's scripts will work the same, plus we can
all switch over to working on the new code without leaving the community
using the old projects.

This shouldn't be a big deal, I already have a demo.c that can be modified
to work with libmyfu, and I believe YAFU is in a similar situation.

> Here is another list of things to do, which probably don't need to
> happen before 1.0, but would be nice if they did as it would make
> Brian's job easier in the future:
> * removal of duplicate code
> * consistent usage of canonical structures everywhere in the code (e.g.,
> merging of msieve_obj_t, fact_obj_t, etc)
> * addition of flags, fields, etc., in the main structure (e.g., merged
> msieve_obj_t and fact_obj_t) to facilitate better/more customization of
> the factoring routines
> * flashy new features (3lp siqs, self-contained lattice sieve,
> threadpool library, ...)

Merging the canonical structures would get my vote for the first thing to
do, it will touch almost every file in the library and it will go a long
way towards making all the code feel like a single codebase.

jasonp