<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic SORMRQ fails erroneously when LDA &amp;lt; M in Intel® oneAPI Math Kernel Library</title>
    <link>https://community.intel.com/t5/Intel-oneAPI-Math-Kernel-Library/SORMRQ-fails-erroneously-when-LDA-lt-M/m-p/1071375#M22281</link>
    <description>&lt;P&gt;I've encountered a bug after updating from a fairly old (~2013) version of MKL to the latest version that SORMRQ now fails if LDA &amp;lt; M, even though the only stated constraint is LDA &amp;gt;= K.&lt;/P&gt;

&lt;P&gt;It seems to fail for any set of parameters where M &amp;gt; K/LDA.&lt;/P&gt;

&lt;P&gt;DORMRQ does not appear to experience this failure when the same parameters are used.&lt;/P&gt;

&lt;P&gt;For a specific example, using has parameters (SIDE='L', TRANS='T', M=256, N=251, K=251, LDA=251, LDC=256), I get the following for a work query (LWORK=-1):&lt;/P&gt;

&lt;P&gt;"Intel MKL ERROR: Parameter 7 was incorrect on entry to SORMRQ."&lt;/P&gt;

&lt;P&gt;I get the same thing when trying to call the function through the LAPACKE interface.&lt;/P&gt;

&lt;P&gt;This looks like a bug in MKL. Can anyone else confirm?&lt;/P&gt;

&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
    <pubDate>Mon, 16 Jan 2017 20:30:16 GMT</pubDate>
    <dc:creator>Paul_F_</dc:creator>
    <dc:date>2017-01-16T20:30:16Z</dc:date>
    <item>
      <title>SORMRQ fails erroneously when LDA &lt; M</title>
      <link>https://community.intel.com/t5/Intel-oneAPI-Math-Kernel-Library/SORMRQ-fails-erroneously-when-LDA-lt-M/m-p/1071375#M22281</link>
      <description>&lt;P&gt;I've encountered a bug after updating from a fairly old (~2013) version of MKL to the latest version that SORMRQ now fails if LDA &amp;lt; M, even though the only stated constraint is LDA &amp;gt;= K.&lt;/P&gt;

&lt;P&gt;It seems to fail for any set of parameters where M &amp;gt; K/LDA.&lt;/P&gt;

&lt;P&gt;DORMRQ does not appear to experience this failure when the same parameters are used.&lt;/P&gt;

&lt;P&gt;For a specific example, using has parameters (SIDE='L', TRANS='T', M=256, N=251, K=251, LDA=251, LDC=256), I get the following for a work query (LWORK=-1):&lt;/P&gt;

&lt;P&gt;"Intel MKL ERROR: Parameter 7 was incorrect on entry to SORMRQ."&lt;/P&gt;

&lt;P&gt;I get the same thing when trying to call the function through the LAPACKE interface.&lt;/P&gt;

&lt;P&gt;This looks like a bug in MKL. Can anyone else confirm?&lt;/P&gt;

&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Mon, 16 Jan 2017 20:30:16 GMT</pubDate>
      <guid>https://community.intel.com/t5/Intel-oneAPI-Math-Kernel-Library/SORMRQ-fails-erroneously-when-LDA-lt-M/m-p/1071375#M22281</guid>
      <dc:creator>Paul_F_</dc:creator>
      <dc:date>2017-01-16T20:30:16Z</dc:date>
    </item>
    <item>
      <title>I can confirm that (with</title>
      <link>https://community.intel.com/t5/Intel-oneAPI-Math-Kernel-Library/SORMRQ-fails-erroneously-when-LDA-lt-M/m-p/1071376#M22282</link>
      <description>&lt;P&gt;I can confirm that (after adaptation to MKL) the example at&amp;nbsp;http://www.nag.com/numeric/fl/nagdoc_fl25/html/f08/f08ckf.html works correctly in double precision and fails in single precision. In the latter case, the failure is accompanied by the message "Intel MKL ERROR: Parameter 7 was incorrect on entry to SORMRQ". Note that, in this example, LDA = M, and the work array WORK was already allocated to a size much larger than needed for SORMRQ because the same array is used as the work array for an earlier call to SGERQF.&lt;/P&gt;</description>
      <pubDate>Tue, 17 Jan 2017 00:53:00 GMT</pubDate>
      <guid>https://community.intel.com/t5/Intel-oneAPI-Math-Kernel-Library/SORMRQ-fails-erroneously-when-LDA-lt-M/m-p/1071376#M22282</guid>
      <dc:creator>mecej4</dc:creator>
      <dc:date>2017-01-17T00:53:00Z</dc:date>
    </item>
  </channel>
</rss>

