Unexpected behaviour of base::qr()$rank

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Unexpected behaviour of base::qr()$rank

Bernd Funovits
Hello,

I experienced some unexpected behaviour while determining the rank of
matrices (sometimes 1x1 matrices):
base::qr(matrix(1e-20))$rank returns 1 (incorrect)
base::qr(diag(c(1, 1e-20)))$rank returns 2 (incorrect)

Best regards,
Bernd

 > R.version
                _
platform       x86_64-w64-mingw32
arch           x86_64
os             mingw32
system         x86_64, mingw32
status
major          3
minor          4.0
year           2017
month          04
day            21
svn rev        72570
language       R
version.string R version 3.4.0 (2017-04-21)
nickname       You Stupid Darkness

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unexpected behaviour of base::qr()$rank

Uwe Ligges-3


On 22.06.2017 17:11, Bernd Funovits wrote:
> Hello,
>
> I experienced some unexpected behaviour while determining the rank of
> matrices (sometimes 1x1 matrices):
> base::qr(matrix(1e-20))$rank returns 1 (incorrect)
> base::qr(diag(c(1, 1e-20)))$rank returns 2 (incorrect)

Why do you believe this is incorrect?

0 != 1e-20

and 1e-20 is well representable without significant rounding errors given

 > .Machine$double.xmin
[1] 2.225074e-308


Best,
Uwe Ligges




>
> Best regards,
> Bernd
>
>  > R.version
>                 _
> platform       x86_64-w64-mingw32
> arch           x86_64
> os             mingw32
> system         x86_64, mingw32
> status
> major          3
> minor          4.0
> year           2017
> month          04
> day            21
> svn rev        72570
> language       R
> version.string R version 3.4.0 (2017-04-21)
> nickname       You Stupid Darkness
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unexpected behaviour of base::qr()$rank

Iñaki Úcar
2017-06-22 19:49 GMT+02:00 Uwe Ligges <[hidden email]>:

> On 22.06.2017 17:11, Bernd Funovits wrote:
>>
>> Hello,
>>
>> I experienced some unexpected behaviour while determining the rank of matrices (sometimes 1x1 matrices):
>> base::qr(matrix(1e-20))$rank returns 1 (incorrect)
>> base::qr(diag(c(1, 1e-20)))$rank returns 2 (incorrect)
>
>
> Why do you believe this is incorrect?
>
> 0 != 1e-20
>
> and 1e-20 is well representable without significant rounding errors given
>
> > .Machine$double.xmin
> [1] 2.225074e-308
>
>
> Best,
> Uwe Ligges

qr() has a tolerance argument which by default is tol=1e-07.

Regards,
Iñaki

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unexpected behaviour of base::qr()$rank

Uwe Ligges-3


On 22.06.2017 20:09, Iñaki Úcar wrote:

> 2017-06-22 19:49 GMT+02:00 Uwe Ligges <[hidden email]>:
>> On 22.06.2017 17:11, Bernd Funovits wrote:
>>>
>>> Hello,
>>>
>>> I experienced some unexpected behaviour while determining the rank of matrices (sometimes 1x1 matrices):
>>> base::qr(matrix(1e-20))$rank returns 1 (incorrect)
>>> base::qr(diag(c(1, 1e-20)))$rank returns 2 (incorrect)
>>
>>
>> Why do you believe this is incorrect?
>>
>> 0 != 1e-20
>>
>> and 1e-20 is well representable without significant rounding errors given
>>
>>> .Machine$double.xmin
>> [1] 2.225074e-308
>>
>>
>> Best,
>> Uwe Ligges
>
> qr() has a tolerance argument which by default is tol=1e-07.

But the tolerance is not about the size of the values! It is about the
reduction of the norm during the householder transformation. From the
sources <https://svn.r-project.org/R/trunk/src/appl/dqrdc2.f>


c     cycle the columns from l to p left-to-right until one
c     with non-negligible norm is located.  a column is considered
c     to have become negligible if its norm has fallen below
c     tol times its original norm....

Best,
Uwe Ligges




>
> Regards,
> Iñaki
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unexpected behaviour of base::qr()$rank

Iñaki Úcar
2017-06-22 20:31 GMT+02:00 Uwe Ligges <[hidden email]>:

>
>
> On 22.06.2017 20:09, Iñaki Úcar wrote:
>>
>> 2017-06-22 19:49 GMT+02:00 Uwe Ligges <[hidden email]>:
>>>
>>> On 22.06.2017 17:11, Bernd Funovits wrote:
>>>>
>>>>
>>>> Hello,
>>>>
>>>> I experienced some unexpected behaviour while determining the rank of
>>>> matrices (sometimes 1x1 matrices):
>>>> base::qr(matrix(1e-20))$rank returns 1 (incorrect)
>>>> base::qr(diag(c(1, 1e-20)))$rank returns 2 (incorrect)
>>>
>>>
>>>
>>> Why do you believe this is incorrect?
>>>
>>> 0 != 1e-20
>>>
>>> and 1e-20 is well representable without significant rounding errors given
>>>
>>>> .Machine$double.xmin
>>>
>>> [1] 2.225074e-308
>>>
>>>
>>> Best,
>>> Uwe Ligges
>>
>>
>> qr() has a tolerance argument which by default is tol=1e-07.
>
>
> But the tolerance is not about the size of the values! It is about the
> reduction of the norm during the householder transformation. From the
> sources <https://svn.r-project.org/R/trunk/src/appl/dqrdc2.f>
>
>
> c     cycle the columns from l to p left-to-right until one
> c     with non-negligible norm is located.  a column is considered
> c     to have become negligible if its norm has fallen below
> c     tol times its original norm....
>
> Best,
> Uwe Ligges

Oh, I apologise, I read the arguments section in the help page, but
not the asterisk down below. Then the result is ok. Sorry for the
noise.

Regards,
Iñaki

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unexpected behaviour of base::qr()$rank

Bernd Funovits
Thanks for the fast replies. There was a bug in
Matrix::rankMatrix(matrix(0)) which returned 1 (fixed by Martin Maechler
in the development version of Matrix) and I thought here is an issue
here too. Sorry for asking too quickly...

Best,
Bernd

Am 22.06.2017 um 21:41 schrieb Iñaki Úcar:

> 2017-06-22 20:31 GMT+02:00 Uwe Ligges <[hidden email]>:
>>
>> On 22.06.2017 20:09, Iñaki Úcar wrote:
>>> 2017-06-22 19:49 GMT+02:00 Uwe Ligges <[hidden email]>:
>>>> On 22.06.2017 17:11, Bernd Funovits wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> I experienced some unexpected behaviour while determining the rank of
>>>>> matrices (sometimes 1x1 matrices):
>>>>> base::qr(matrix(1e-20))$rank returns 1 (incorrect)
>>>>> base::qr(diag(c(1, 1e-20)))$rank returns 2 (incorrect)
>>>>
>>>>
>>>> Why do you believe this is incorrect?
>>>>
>>>> 0 != 1e-20
>>>>
>>>> and 1e-20 is well representable without significant rounding errors given
>>>>
>>>>> .Machine$double.xmin
>>>> [1] 2.225074e-308
>>>>
>>>>
>>>> Best,
>>>> Uwe Ligges
>>>
>>> qr() has a tolerance argument which by default is tol=1e-07.
>>
>> But the tolerance is not about the size of the values! It is about the
>> reduction of the norm during the householder transformation. From the
>> sources <https://svn.r-project.org/R/trunk/src/appl/dqrdc2.f>
>>
>>
>> c     cycle the columns from l to p left-to-right until one
>> c     with non-negligible norm is located.  a column is considered
>> c     to have become negligible if its norm has fallen below
>> c     tol times its original norm....
>>
>> Best,
>> Uwe Ligges
> Oh, I apologise, I read the arguments section in the help page, but
> not the asterisk down below. Then the result is ok. Sorry for the
> noise.
>
> Regards,
> Iñaki

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Loading...