Início / coding / Perguntas / 79574581
Accepted
Jasper
Asked: 2025-04-15 15:29:04 +0800 CST

Fortran selected_real_kind e precisão dupla MKL

  • 772

Seguindo este guia de melhores práticas, tenho um módulo no meu código Fortran que define um tipo de precisão dupla,

module kind_parameters
    implicit none
    public
 
    ! Double precision real numbers, 15 digits, range 10^-307 to 10^307-1; 64 bits
    integer, parameter :: dp = selected_real_kind(15, 307)
 
 end module kind_parameters

Meu código, que usa esse tipo de precisão dupla para todas as operações de ponto flutuante, faz uso regular de MKL. Aqui, sempre uso a versão de precisão dupla das sub-rotinas MKL, ou seja, DGEMM e DSYEVD.

Não está claro para mim se meu tipo definido pelo usuário é consistente com o tipo de precisão dupla esperado pelo MKL. Em todos os meus testes até agora (com ifort/ifx), isso parece ter funcionado bem, mas existem armadilhas potenciais com minha maneira de fazer as coisas? Existe uma maneira melhor?

floating-point

1 respostas

  1. Best Answer

    Em teoria, pode ocorrer inconsistência se você estiver trabalhando em uma plataforma onde precisão dupla significa algo diferente do tipo de ponto flutuante duplo IEEE. Por exemplo, se o compilador, incluindo o compilador que compilou o MKL, estiver configurado para usar floats de 64 bits como o tipo padrão e 128 bits como double. Nesse caso, como Ian escreveu, não há nada de errado em usar kind(1.d0)para o seu tipo. A recomendação de estilo importante é usar uma constante nomeada para seus tipos ; como exatamente você define o valor da constante é menos importante.

    Se precisar de precisão dupla, defina-a como precisão dupla, como kind(1.d0); se precisar de compatibilidade com o C double, defina-a como c_double; se quiser armazenamento de 64 bits, defina-a como real64. Na prática, todos esses métodos normalmente darão o mesmo resultado. Você também pode usar selected_real_kind, mas, na minha opinião, ele não atendeu às expectativas e está praticamente obsoleto, apesar de não ser oficialmente. Neste ponto, discordo claramente da recomendação do fortran-lang.org. É minha opinião pessoal.

    • 3

relate perguntas