Setting starting values for vector variable bridges
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
- 38/100
Direção de pesquisa
Comece com src/Bridges/Variable/set_map.jl por volta das linhas 182-192 e leia como FlipSignBridge lida com valores iniciais. Rastreie o ciclo de vida da bridge por meio de final_touch e, em seguida, compare se o armazenamento em cache deve ficar na bridge ou em BridgeOptimizer. Considera-se concluído quando mapas lineares não diagonais puderem definir valores iniciais vetoriais de forma consistente.
Escrita pelo modelo de indexação a partir do texto da issue.
Descrição
This is working for FlipSignBridge since it just multiply by -1 but for a linear map that is not diagonal, we cannot set the starting values variable by variable.
We would need to cache the vector of starting values in the bridge and then do the linear map in final_touch.
Alternatively, this caching could be done by BridgeOptimizer to simplify the job of each bridge but that caching isn't needed for FlipSignBridge so it could be a waste.
- Linguagem predominante
- Julia
- Estrelas
- 506
- Forks
- 103
- Merge médio
- 1d 1h
- PRs com merge (30d)
- 9
Preparar o ambiente
Este projeto não oferece contêiner de desenvolvimento, Dockerfile nem guia de contribuição, então a configuração fica por sua conta: comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de jump-dev/MathOptInterface.jl
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
jump-dev/MathOptInterface.jl#3113 ·
Mantenedores costumam responder em até 1 dia
-
[Bridges] MultirowChange in set_map.jl drops zero coefficientsTalvez já em andamento @odow assumiu há 6 dias. Aberta
jump-dev/MathOptInterface.jl#3106 · 2 comentários · 1 responsável ·
Mantenedores costumam responder em até 1 dia
-
Precision loss in Hessian computationTalvez já em andamento @blegat assumiu há 7 dias. Aberta
Dificuldade 5/5 Mais de uma semana Facilidade para iniciantes 15/100
jump-dev/MathOptInterface.jl#3104 · 11 comentários ·
Mantenedores costumam responder em até 1 dia
-
Layer instantiatorAberta
Dificuldade 5/5 Mais de uma semana Facilidade para iniciantes 35/100
jump-dev/MathOptInterface.jl#2986 · 3 comentários ·
Mantenedores costumam responder em até 1 dia
-
Dificuldade 5/5 Mais de uma semana Facilidade para iniciantes 25/100
jump-dev/MathOptInterface.jl#2969 · 2 comentários · 1 reação ·
Mantenedores costumam responder em até 1 dia
Todas as issues de jump-dev/MathOptInterface.jl
Issues semelhantes
-
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 83/100
JuliaMath/Polynomials.jl#647 ·
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 74/100
OpenSourceAWE/SymbolicAWEModels.jl#431 ·
Mantenedores costumam responder em até 1 dia
-
Make PDAQP an optional extraAberta
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 66/100
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 75/100
JuliaArrays/StaticArrays.jl#1365 ·
-
`@fastmath` reductions are 2–5× slower: no `neutral_element` for `Base.FastMath.max_fast` and co.Aberta
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 86/100
JuliaGPU/GPUArrays.jl#833 ·
Mantenedores costumam responder em até 1 dia