Demo Data from SIGIR 2026 / reviewers in the wild / expert
Paul Stanford
dblp:264/5611
· DBLP profile ↗
2ranked-venue papers
0as first author
0since 2021 · last 1990
—ORCID · none
Domains — the database's venue-derived domains; a paper can count in several
Artificial intelligence and machine learning · 1Systems, architecture and hardware · 1
Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.
| Computer architecture, parallel and distributed computing, and storage systems
1 paper |
Electronic design automation · 100% |
Topics — the 1 heaviest of 2, each with the papers that count most for it
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Electronic design automation
design representation |
0.0 | 1 | 1989 | A Unified Design Representation Can Work · DAC 1989 |
| Year | Publication | Venue | Position |
|---|---|---|---|
| 1990 | A random walk in Hamming spaceabstractA description is given of the scatter code, a new technique for mapping sensor data into a form suitable for processing by associative neural networks. By overthrowing the assumption that the sensor mapping must preserve order in addition to closeness, a mapping can be generated that has much more capacity and flexibility than previous mappings. The first advantage is the practically limitless number of points in the new mapping, which eliminates the need to compress sensor information and lose resolution. The second advantage is the ability to control the radius of association in the mapped sensor data by varying the rate at which points in the Hamming space become orthogonal. The radius of association can be varied within the mapping to take advantage of special cases when information about the sensor or about the expected data point is known Derek Smith, Paul Stanford |
IJCNN | 2 |
| 1989 | A Unified Design Representation Can WorkabstractA unified design representation can work. This has always been considered impractical due to major problems of run time, space, tool interdependencies, and multiple representations. We have addressed these problems and found them tractable. We present our solutions to these problems, gained through the experience of developing the Droid design system. Paul Kollaritsch, Steve Lusky, Doug Matzke, Derek Smith, Paul Stanford |
DAC | 5 |