diff options
| author | YurenHao0426 <Blackhao0426@gmail.com> | 2026-08-01 16:15:41 -0500 |
|---|---|---|
| committer | YurenHao0426 <Blackhao0426@gmail.com> | 2026-08-01 16:15:41 -0500 |
| commit | 08fd63b8fee62ccdc284380c9832900ee83f9ede (patch) | |
| tree | 53d49406a0b778e25c7604a7ae0fe5d2ecf15367 /logs/obj_large.log | |
| parent | 58b9c84dae293359f498fdf6afd533df5c9d3c25 (diff) | |
Retire the correlation gate: the shared spectrum governs recovery
A controlled truncation refutes the project's central go/no-go rule.
Projecting the recovering synthetic fields to rank r holds the field
correlation at 0.902-0.929 while recovery moves 6.2% -> 12.9% -> 95.6%
across ranks 4, 8, 16. A field past the supposed 0.9 threshold recovers
13%, so correlation neither predicts nor forbids recovery and the width
of the shared spectrum is what moves it.
The gate becomes a joint condition on correlation and shared width,
measured by principal angles against a scene-shuffled null. Neither
suffices alone: 18 shared directions at 0.508 fails, 11 at 0.902 fails.
With the old gate retired, natural data was finally searched: 0.0000
against 0.0039 chance. The old verdict was right, its reasoning was not.
Also closes route D by measurement. rho_IT ~ sqrt(4 log N / N) rises as N
falls, and at N = 16 through 96 the deepest state a strong searcher
reaches is deeper than the truth in 3/3 replicates at every size.
Free gains: eigenvalue-weighted projection over a wide basis with
128-dim text vectors takes the correlation 0.656 -> 0.716 and shared
width 10 -> 16. Hubness refuted as an inflation hypothesis.
Moving the per-image segmentation eigendecomposition onto the GPU cut
batch time from 130s to 1.9s.
Co-Authored-By: Claude <noreply@anthropic.com>
Diffstat (limited to 'logs/obj_large.log')
| -rw-r--r-- | logs/obj_large.log | 3 |
1 files changed, 3 insertions, 0 deletions
diff --git a/logs/obj_large.log b/logs/obj_large.log new file mode 100644 index 0000000..44fda9d --- /dev/null +++ b/logs/obj_large.log @@ -0,0 +1,3 @@ +Using a slow image processor as `use_fast` is unset and a slow processor was saved with this model. `use_fast=True` will be the default behavior in v4.52, even if the model was saved with a slow processor. This will result in minor differences in outputs. You'll still be able to use a slow processor with `use_fast=False`. +`torch_dtype` is deprecated! Use `dtype` instead! +
segment: 0%| | 0/313 [00:00<?, ?it/s]
segment: 0%| | 1/313 [00:33<2:54:15, 33.51s/it]
segment: 1%| | 2/313 [01:02<2:39:35, 30.79s/it]
segment: 1%| | 3/313 [01:35<2:43:37, 31.67s/it]
segment: 1%|▏ | 4/313 [03:41<5:56:15, 69.18s/it]
segment: 2%|▏ | 5/313 [05:25<6:59:54, 81.80s/it]
segment: 2%|▏ | 6/313 [06:43<6:51:46, 80.48s/it]
segment: 2%|▏ | 7/313 [07:37<6:05:24, 71.65s/it]
segment: 3%|▎ | 8/313 [08:40<5:50:37, 68.98s/it]
segment: 3%|▎ | 9/313 [09:35<5:27:25, 64.62s/it]
segment: 3%|▎ | 10/313 [10:33<5:16:19, 62.64s/it]
segment: 4%|▎ | 11/313 [11:46<5:30:23, 65.64s/it]
segment: 4%|▍ | 12/313 [12:45<5:19:20, 63.66s/it]
segment: 4%|▍ | 13/313 [13:49<5:19:01, 63.81s/it]
segment: 4%|▍ | 14/313 [15:20<5:59:27, 72.13s/it]
segment: 5%|▍ | 15/313 [17:25<7:16:35, 87.91s/it]
segment: 5%|▌ | 16/313 [19:18<7:52:16, 95.41s/it]
segment: 5%|▌ | 17/313 [21:20<8:30:07, 103.40s/it]
segment: 6%|▌ | 18/313 [23:31<9:09:44, 111.81s/it]
segment: 6%|▌ | 19/313 [25:46<9:41:50, 118.74s/it]
segment: 6%|▋ | 20/313 [28:00<10:02:23, 123.36s/it]
segment: 7%|▋ | 21/313 [30:04<10:01:04, 123.51s/it]
segment: 7%|▋ | 22/313 [32:13<10:06:32, 125.06s/it]
segment: 7%|▋ | 23/313 [34:50<10:50:35, 134.61s/it]
segment: 8%|▊ | 24/313 [37:17<11:06:29, 138.37s/it]
segment: 8%|▊ | 25/313 [39:40<11:11:26, 139.88s/it]
segment: 8%|▊ | 26/313 [41:26<10:20:42, 129.76s/it]
\ No newline at end of file |