# Call LAPACK's ZHEEV directly

**URL:** <https://discourse.julialang.org/t/call-lapacks-zheev-directly/7305>\
**Category:** General Usage\
**Tags:** linearalgebra\
**Created:** [November 25, 2017, 2:33pm UTC](https://discourse.julialang.org/t/call-lapacks-zheev-directly/7305 "2017-11-25T14:33:08Z")\
**Posts on this page:** 1\
**Showing post:** 5

<div class="post-metadata">

**Author:** ![carstenbauer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/carstenbauer/32/4981_2.png) [@carstenbauer](https://discourse.julialang.org/u/carstenbauer)\
**Post date:** [November 25, 2017, 4:02pm UTC](https://discourse.julialang.org/t/call-lapacks-zheev-directly/7305/5 "2017-11-25T16:02:44Z")

</div>

> In Julia, it is more natural and convenient to use dispatch on the argument types rather than having multiple function names ala Fortran 77.

Sure, but `Base.LinAlg.LAPACK` provides wrappers to precisely those old Fortran routines and it might by highly unintuitive to not have those methods in there explicitly but hidden in dispatch logic (although more natural to Julia). If I search for ZHEEV I will probably not assume that it might be a differently dispatched version of SYEV which is only for real matrices in Fortran.

However, I agree that in general there shouldn’t really be a reason to call those functions. Nonetheless, I have to call `Base.LinAlg.LAPACK.gesvd!` explicitly in one of my codes, because `svdfact` is based on `Base.LinAlg.LAPACK.gesdd!` which is unstable in this particular usecase. Moreover, people switching to Julia might like having direct access to routines they are used to (but this is of course a thin argument).

---

_[View the full topic](https://discourse.julialang.org/t/call-lapacks-zheev-directly/7305)._