Featured request

[bsquared]

This thread is for feature/change requests. Keeping them more visible might even help them get done faster .

I won't bother extracting current requests from the giant yafu thread, but I am currently tracking several:

+ enable starting yafu from a different directory (note: manage files relative to binary rather than current dir?)
+ reduce screen output on poly selection phase (or use a -switch for it)
+ SNFS polynomial generation
+ loops and ifs in the command interpreter
+ prime proving
+ ggnfs and ecm in better threadpool

If I missed any or if you have anything else to suggest, add it here.

[LaurV]

• reduce screen output on poly selection phase (or use a -switch for it)

It disappeared in the former version, but appeared back in the last. Scrolling the dos prompter is a slow operation, taking some computing cycles that would be better used to look for more polys

[c10ck3r]

Copy/paste-ability? Thanks for consideration!

[Mr. Odd]

SNFS polynomial generation

[bsquared]

Originally Posted by c10ck3r

Copy/paste-ability? Thanks for consideration!

That's a function of your OS, not of YAFU. See posts 126 through 133 here for how to do it in a dos command window, if that's what you are using.

[EdH]

In the direction of offering instead of requesting, would there be any interest in a Windows GUI front end for YAFU?

I'm toying with the idea of creating something similar to AliWin2 for Aliqueit. It would basically allow you to choose what you want YAFU to accomplish via edit boxes and buttons. This would allow for Windows Copy/Paste and such things as clicking a button to edit the ini file or to run tune, etc.

I'm not saying I could turn this out really soon or that it would be professionally done, but if there is interest I would at least look into it.

OTOH, if there is little interest or if bsquared thinks it might cause more headaches running down future troubles, I'll place it on an unlit burner far back from the pilot light.

[LaurV]

@EdH: Some people would like a windoze interface or wrapper. Why not? A wrapper could be easy to write (that is, just a series of tabs and buttons and clicking them would call yafu with some parameters, this does not imply modifying yafu in any way). Eventual call to notepad (or your favorite text editor) to edit the ini file or to add/remove numbers to factor in batch files for yafu running in batch mode.

But all this can be achieved with a little effort without any graphical I/F. In fact most of the users like the flexibility of the command-line prompt. I will always prefer to have a file-manager like NortonCommander (or Ghisler's TotalCommander, which I am using right now) instead of windows explorer (one of the most stupid programs I know!! please remark the lowercase) and one of the reasons is exactly the presence of the command line interface in the former. So, all the things mentioned in the first paragraph could be achieved ok, without a real graphic interface. Printing in textboxes would be quite slow too, and you would need to cut on the output. I think yafu's interface is quite ok as it is.

What is missing is some loops and ifs in the command interpreter, and if you can implement that, your time would be better used. And don't tell this to bsquared, please! otherwise he will throw his shoe after me!

[bsquared]

Originally Posted by EdH

In the direction of offering instead of requesting, would there be any interest in a Windows GUI front end for YAFU?

...

OTOH, if there is little interest or if bsquared thinks it might cause more headaches running down future troubles, I'll place it on an unlit burner far back from the pilot light.

I can't judge interest, maybe others will respond, but as long as you are willing to work fairly independently of me, I'm all for it. Not that I'm trying to distance myself from it, just trying not to create extra work for myself .

BTW, I've thought about this before, but never took it on for one reason or another. One reason is that every time I thought about it I immediately saw opportunity for a multitude of neat bells/whistles that would have been far too time consuming to implement.

Not trying to discourage you... Go for it if it is interesting to you!

As a matter of curiosity, what would you use to create the GUI? Something cross-platform like Qt or tcl/tk, or would it be a windows only thing?

[bsquared]

Originally Posted by LaurV

And don't tell this to bsquared, please! otherwise he will throw his shoe after me!

.

[bsquared]

Originally Posted by LaurV

• reduce screen output on poly selection phase (or use a -switch for it)

It disappeared in the former version, but appeared back in the last. Scrolling the dos prompter is a slow operation, taking some computing cycles that would be better used to look for more polys

This stuff is generated by msieve, so its not really something I can control. I've added it to the list anyway, to keep visibility on it.

[LaurV]

Originally Posted by bsquared

That's a function of your OS, not of YAFU. See posts 126 through 133 here for how to do it in a dos command window, if that's what you are using.

After I clicked on your "here" and read a couple of posts about the balance between ecm and siqs (mixed in that discussion) some stupid idea came into my mind: would it be possible to start ecm and siqs in the same time on a multithreaded machine? For example if I have 4 threads in the preferences. Then two threads would start ecm, and another two siqs. After "a while", the two threads doing ecm will stop and switch to siqs. This "a while" is setable from the ini file, in fact is what the "ecm_qs_ratio" parameter was doing in the former version. The trouble with that one was that it could not be easy measured. One wouldn't know how long siqs would take (the number of relations is known, but the time needed to get a relation is not). With my idea, the measurement can be done much accurately and it will save some time by optimizing the time spend into the ecm phase. For example, the ecm_qs_ratio=0.3. We have 4 threads and we know how many relations siqs has to find, say 80k. There will be two threads doing ecm until a number x of relations was found. This would take X time. Then all 4 threads would look for the other 80k-x relations, which would take Y time. There is a simple formula to minimize the total time, staying into the 0.3 given ratio of ecm-time-spent. Of course meantime the ecm can find a factor and the time spent for siqs is wasted, but this is less then the time wasted for ecm in the cases a factor is not found and siqs can find relations faster then expected. Does it make sense? O is all gibberish?

In the past I did many tests with plan=light against plan=normal. Occasionally I used plan=deep but for siqs-factorable cofactors it was never necessarily to go deep with the ecm, only for nfs-factorable composite it made sense to do it. Usually a "light" ecm and siqs was faster per total numbers factored, and only rarely would the "normal" ecm find factors missed by "light" ecm.