The MCP server and the terminal should offer dimensional analysis and shader source once #2292 and #2293 land

Aberta
  • Algo errado?
#2,298 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
18/100
Tipo de issue
Funcionalidade
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
csharp, shell
Domínio
api, tooling

Direção de pesquisa

Start in Core/Operations/Catalogue.cs and the CatalogueTest and OneShotTest suites, which define how catalogue entries reach the MCP server and the terminal. The work waits on #2292 (MathS.Dimensions) and #2293 (MathS.Shaders) being accepted, and it needs a library change to parse Dimension.ToString output back into a dimension. Done means four catalogue entries, two MCP tools with McpUnitTests coverage, and the OneShot.notOffered names in place.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

What you ran: amcli mcp on a build carrying #2292 (MathS.Dimensions) and #2293 (MathS.Shaders), branches feat/dimensional-analysis and feat/shader-source.

What it did: nothing; neither is there. Neither branch adds an entry to Core/Operations/Catalogue.cs (#1684), so the server's CatalogueTest and the terminal's OneShotTest stay green and nothing makes either surface keep up. AGENTS.md asks for both: "an operation the library offers by name is an entry of Core/Operations/Catalogue.cs", and the MCP server "has to expose what the release added".

What it should have done: once both are in a release:

1. Four catalogue entries, as queries:

entry calls
dimension MathS.Dimensions.Of(expr, dimensions)
dimensionless_groups MathS.Dimensions.DimensionlessGroups(variables, dimensions)
hlsl, glsl MathS.Shaders.Hlsl / Glsl(outputs, names)

The names are to agree on; #1019 item 16 asks for the library's own words. The shader entries are text in and text out already. The dimension entries need one addition in the library to be: reading a dimension back from the text Dimension.ToString writes (L M T^-2, L^(1/2), 1, with an ASCII spelling for Θ), so that a caller can pass g: "L T^-2".

On sequence, either each feature's pull request adds its entries with a Tools.NotOffered reason and an OneShot.notOffered name pointing here, which keeps every offered operation in the catalogue at every commit, or the pull request for this issue adds entries and surfaces together. The tests are built for the first, so I would do that.

2. Two MCP tools, each offering two entries, the way am_truth_table offers truth_table and satisfying_assignments:

  • am_dimensions: dimensions (name → dimension) and either formula or variables. For a formula: consistent with its dimension, inconsistent naming the subexpression and the two dimensions that disagree, or undetermined naming what is missing (an undeclared variable, a symbolic power of a dimensional base). For variables: the dimensionless groups. As a routing description: call it before trusting a physics formula you derived or transcribed; a term with the wrong units survives algebra that looks right, and sin(x) - sin(x) with x a length is inconsistent even though it simplifies to 0.
  • am_shader_source: language (hlsl or glsl), outputs (name → expression) and optionally names (variable → shader expression such as p.x). It answers the code, or declined with the node and the reason the library gives. As a routing description: call it to put a derivative or a closed form into a shader rather than transcribing it, which is where precedence, pow of a negative base and fmod against a floored mod go wrong. It computes what am_evaluate computes, except that since #2288 a compiled division by zero has no value, while on a GPU it is ±inf.

The README asks for a parameter on an existing tool first, then a prompt, then a tool. A dimensions parameter on am_parse fits the check, but not the groups, which take no formula. And a check that can fail reads better with its own status than inside the parse's warnings. am_to_sympy is the nearest relative of the shader tool, but its name and its answer are stable, and folding languages into it would change both.

Also:

  • The check-formula prompt gains a step: where the variables are physical quantities, call am_dimensions with their units before am_domain_check.
  • The README gets the two rows of its tools table and one known limit: a dimension's exponents are rational, so L^pi is inconsistent and a symbolic power of a dimensional base is undetermined.
  • Every library call goes through Guard.Run, and McpUnitTests drives both tools as a client does.
  • Neither needs to be preliminary: each answers what a released API answers.

3. The terminal. The four names go into OneShot.notOffered; one-shot commands can follow if wanted.

Depends on #2292 and #2293, which wait for Accepted. If only one is accepted, the other half of this drops. The milestone is the one that carries them (2.7.0 proposed there).

Linguagem predominante
C#
Estrelas
831
Forks
79
Merge médio
1h 12min
PRs com merge (30d)
518

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de ASC-Community/AngouriMath

Todas as issues de ASC-Community/AngouriMath

Issues semelhantes

Mais issues de C#

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.