Bibliographic record
Abstract
A better financial calculatorStudents of the mathematics of finance seem to be comfortable using calculators to evaluate formulas or numerical expressions. They are typically much less comfortable writing programs in BASIC (or C or Java etc.) even in situations where the calculator solution is tedious and a short program would do the job efficiently. Spreadsheet models, with an emphasis on formulas as opposed to programs, are quite a reasonable and intuitive tool. But spreadsheet formulas seem to be about cells rather than money, time, and interest rates.The ideal tool would be a better calculator. APL and J can be used in calculator mode and therefore should be marketable to students as advanced calculators ideally suited to financial mathematics. This is especially true now that APL and J can be run on a variety of palm-sized computers.This paper presents a few ideas on how students might use J in the mathematics of finance. The emphasis is on using J as a calculator that has lots of memory and can store and compute with arrays. Therefore data will be entered and expressions evaluated but no programs will be presented in the classroom. (However, two utility programs and a few names for J primitives will be used as noted in the next subsection.)J Definitions used in what followsThe J examples below are presented in the plain Courier font. Certain definitions are assumed and these are displayed in Courier italics. The definitions of these italicized functions are given in the Appendix at the end of the paper. In particular, frequent use is made of a dollar format function Df to display numbers in dollar currency format. When dates are part of the input data, the dayno function can be used to compute a day number.All examples in this paper (except for Example 7, which uses the sparse arrays of J version 4.04) can be done with versions of J going back (at least) to J FreeWare, version 3.02.
Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.
How this classification was reachedexpand
Full frame machine prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. The Gemma side is a direct model label for every work in the frame, read from the title-only record. The Codex side is a classifier learned from the 10,348 direct Codex labels and calibrated to design-weighted sample rates; fields without enough sample support carry no Codex call. Candidate is the union of the two sides; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels.
Distilled classifier scores by category (both heads)
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.001 | 0.011 |
| Meta-epidemiology (narrow) | 0.001 | 0.001 |
| Meta-epidemiology (broad) | 0.001 | 0.001 |
| Bibliometrics | 0.001 | 0.002 |
| Science and technology studies | 0.002 | 0.002 |
| Scholarly communication | 0.008 | 0.016 |
| Open science | 0.002 | 0.006 |
| Research integrity | 0.002 | 0.003 |
| Insufficient payload (model declined to judge) | 0.163 | 0.103 |
Machine scores (provisional)
The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.
Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.
score_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from itClassification
machine, unvalidatedMachine predicted; a candidate call from one source (direct Gemma or distilled Codex), not a consensus.
How this classification was reached, model by model and score by score, is at the end of the page under "How this classification was reached".