[QUOTE=R.D. Silverman;530222]4,3,427-. It doesn't show any curves at B1 = 1G. Indeed, I don't see any listings
that have B1 = 1G[/QUOTE]

The audience can ignore this remark. I just realized they you must have "normalized"
my curve counts.

[QUOTE=R.D. Silverman;530228]The audience can ignore this remark. I just realized they you must have "normalized"
my curve counts.[/QUOTE]

Personally I would prefer that trials simply get reported "as run" [i]without[/i]
attempting to "normalize" for other digit sizes.

YMMV

9-5,535M (SNFS)
[code]
3981518625751198077603235065772048118316566245197680512999197752491
15762689243927937618317396796163722473026927805474806442756904618262886979283697317273646535376418312555037787192691
[/code]

[QUOTE=R.D. Silverman;530234]Personally I would prefer that trials simply get reported "as run" [i]without[/i]
attempting to "normalize" for other digit sizes.

YMMV[/QUOTE]

That's a reasonable thing to prefer. Indeed, there was a time when I shared the same preference. The biggest problem with normalizing the curve counts is that it loses information. With the original raw data, one can calculate the exact probabilities of factors of various sizes being left behind, and one can always generate the normalized version for comparison. By contrast, if all one has is the normalized data, then there's no way to go the other way and generate the original raw data.

However, what I discovered over time was that:

1) The normalized counts are almost always more useful. If you have raw counts at a variety of (possibly non-standard) B1 values, it takes some work to figure out how "deep" the number has been searched. If you want to compare the work done on different numbers, you can tell what you need to know at a glance with the normalized counts. If you want to know whether a number has been "done" to a given level (e.g. t55), that too is something you can tell at a glance with the normalized counts. And these kinds of questions form the vast majority of what I really want from the data.

2) Calculating probabilities from the normalized data is still reasonably useful, though it is certainly less accurate, as we've both already stated. Even with the inaccuracy, it still gives the important big-picture view of how much work a number has had, and a reasonable consequent probability of factors of various sizes still remaining. I.e. it's inaccurate, but it's not [I]that[/I] inaccurate.

Of course, it would be possible to keep the raw data and have it available for display, but also have the normalized data available for display by just generating it on demand. I have not done this only because of the hassle involved. If someone wants to volunteer to set that up, I am happy to consider incorporating it. Of course, it would only be useful for future ECM work; I no longer have the original raw data for ECM work done up to now.

(I would never have been able to incorporate the raw data for the work you did on the first 5 holes, for the simple reason that you never gave me the relevant details. All you told me was that you were doing/had done a t55 on each of those numbers.)

[QUOTE=jyb;530286] I.e. it's inaccurate, but it's not [I]that[/I] inaccurate.[/QUOTE]As in THHGTTG, it does at least make the reassuring claim, that where it is inaccurate it is at least definitively inaccurate.

[QUOTE=xilman;530310]As in THHGTTG, it does at least make the reassuring claim, that where it is inaccurate it is at least definitively inaccurate.[/QUOTE]

Ah, if only I could be definitive in my inaccuracy. But even in this it falls short. :sad:

[QUOTE=jyb;530286]

(I would never have been able to incorporate the raw data for the work you did on the first 5 holes, for the simple reason that you never gave me the relevant details. All you told me was that you were doing/had done a t55 on each of those numbers.)[/QUOTE]

All you had to do was ask........:smile:

9-5,535L (SNFS)
[code]
42910559209837540001325065788249457034535824019238072494223171711
4661551086289530312063176338902605267796239032951953807035890439923364971420499320322792969480784221284720078645640801
[/code]

12+5,705M (SNFS):
[code]
72903077382671962888469255333023309944640415569308811
2029464997512676612864344126626267306297316094689975148720371115918601624107110343128941788784803074155503666748436104789042652058089272506471
[/code]

5+2,438 (SNFS)
[code]
18844950447654324758941719583763162090175013420048958310514346125501
3414168510765676608077769143438728446627677724905779454581305772110065915505501626085239449563207803377035564597241
[/code]

6+5,393 (SNFS)
[code]
277075447320436327479302596211725697063732372338322663927599
1502414979784029228349425408355552550381274983496233615811647925874393055182109580795925187620686158416858715694847867
[/code]