Spaces:
Running on Zero
Running on Zero
Commit History
6 days ago
-
Report the sites the cutoff rejected, instead of nothing Running
Feedback from a reviewer: running INS and IAPP found no alternative reading frames, and they guessed the missing ribosome-profiling data was the reason. It is not. Scored down to 0.0005 on held-out folds, those two transcripts contain four sites in total -- the two annotated starts, an in-frame INS N-truncation at 0.0037 and an IAPP 3'UTR ORF at 0.0008. Nothing in another frame registers at all. The model looked and said no. The UI gave no way to tell those two stories apart, so every run now scores down to a floor of 0.0005 whatever cutoff is set, and the rejected sites are listed in their own tab with the best one quoted under the funnel. Same work for the model; an empty result now carries its own evidence. Adds IAPP as a fourth example (chr12, fold 3) and says plainly in the app and the README that a near-zero score is the model's prior, not a missing input. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>c357a0a -
Replace examples with ones that show where the model actually fails
The old set (INS, TYK2, ACTB) returned nothing but canonical starts at the default cutoff, so the demo opened on an empty result and ACTB earned its place only as a negative control the others already provided. Running validated non-canonical ORFs through the model gives a sharper finding than "it only finds canonical starts", which was wrong: MIEF1 upstream ORF 70 aa 0.674 found, outranks the canonical ATF4 uORF2 59 aa 0.303 found HOXB-AS3 peptide 53 aa 0.000892 missed TYK2 uORF 8 aa 0.000038 missed ATF4 uORF1 3 aa 0.000044 missed Sensitivity tracks ORF length, not whether the start is canonical. ATF4 is the controlled case: both uORFs sit in the same 282 nt leader, 99 nt apart, and the 3 aa one is invisible despite a textbook Kozak context. That matters because microproteins are short by definition, so the model loses sensitivity exactly in the regime this project is about. It is also fairer to the tool, w…fc30842
9 days ago
-
Score each example on a fold that held out its chromosome
The demo ran everything on fold 0, whose test set is empty, so it scores any chromosome including ones it trained on. INS (chr11), TYK2 (chr19) and ACTB (chr7) are all in fold 0's training set. The tool warns about this at runtime, but the warning is buried in the log. Re-running each gene on a fold that excluded its chromosome (TYK2 on 3, INS and ACTB on 4) shows the leakage is worth about +/-0.06: canonical starts score 0.889-0.985 held out versus 0.944-0.965 on fold 0. So the model does generalise on canonical starts, which is fair to report. The headline finding survives and is now defensible. On fold 3, with chr19 never seen, the validated TYK2 uORF at position 186 scores 0.000038 against 0.984922 for the canonical start in the same transcript, roughly 26,000x. At the default cutoff the model now proposes only the three annotated starts and nothing non-canonical at all. Updates the README numbers, adds a section on choosing a fold, and spells out the per-example folds in the UI…0e84302 -
Fall back to CPU when the GPU path fails
The ZeroGPU path was the one branch never exercised locally -- every test ran with TRISTAN_ACCELERATOR=cpu, which takes the subprocess route. It contained a real bug: _resolve_entrypoint() ran unconditionally, so the in-process path raised if the `tis_transformer` console script was not on PATH, even though that path drives main() directly and never needs it. Rather than just fixing that, make prediction degrade instead of failing. The GPU is attempted first where there is one, and any failure falls back to the subprocess CPU route, which is the tested one. On inputs this size CPU takes seconds, so there is no reason for a GPU problem to take the Space down. Both failures are reported together if neither works, so the next report is actionable. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>dfc65a6 -
Chain TIS prediction to epitope prediction end to end
Extends the Space from a single-model wrapper into the full pipeline the collaboration proposal describes: sequence -> TIS Transformer -> ORF typing -> MHCflurry -> candidate peptides All three stages are existing, openly-licensed tools. MHCflurry (Apache-2.0) is used rather than NetMHCpan, whose academic licence forbids redistribution and so cannot be hosted. Verified against the installed package rather than the docs, which were wrong in ways that mattered: - The FASTA-path CSV schema differs from the documented h5/GTF one. The score column is `output`, not `tis_transformer_score` -- so the previous tidy() matched no column and the cutoff slider and sorting silently did nothing. - TIS_pos is 1-based; everything here is 0-based. The conversion lives in one named function because an off-by-one shifts every reading frame and still yields a plausible protein. - Weights ship inside the wheel, so there is no download to warm. - --start_codons defaults to near-cognate (.*TG$…5278136 -
run model
fe26600 -
initial commit
Verified signaturec4ce6c8