[Scilab-users] acos leads to complex values

classic Classic list List threaded Threaded
18 messages Options
Carrico, Paul Carrico, Paul
Reply | Threaded
Open this post in threaded view
|

[Scilab-users] acos leads to complex values

Dear All

 

I spent some time in looking for a mistake in my code ; finally I’ve found that the ACOS of a real vector leads to some complex values (???)

 

acos(Scar_P(:,1) ./ CM_x_CN(:,1))
 

(the formula worked so far)

 

 

I checked that the input values are correct:

-          Comprised between [-1; 1] using MIN and MAX

-          Composed only of real values using ISREAL (all the vectors are correct)

 

Thus I do not understand why complex values appear ?

 

May it come from the vectorization ?

 

Paul

 

 

 


_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
mottelet mottelet
Reply | Threaded
Open this post in threaded view
|

Re: acos leads to complex values

Le 29/01/2019 à 16:45, Carrico, Paul a écrit :

Dear All

 

I spent some time in looking for a mistake in my code ; finally I’ve found that the ACOS of a real vector leads to some complex values (???)

 

acos(Scar_P(:,1) ./ CM_x_CN(:,1))

Are your really sure, because we may have

--> x=-1-%eps
 x  =

  -1.


--> acos(x)
 ans  =

   3.1415927 - 2.107D-08i

S.


 

(the formula worked so far)

 

 

I checked that the input values are correct:

-          Comprised between [-1; 1] using MIN and MAX

-          Composed only of real values using ISREAL (all the vectors are correct)

 

Thus I do not understand why complex values appear ?

 

May it come from the vectorization ?

 

Paul

 

 

 


_______________________________________________
users mailing list
[hidden email]
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users


-- 
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
Carrico, Paul Carrico, Paul
Reply | Threaded
Open this post in threaded view
|

Re: [EXTERNAL] Re: acos leads to complex values

When I scroll to the list, the lowest (positive) value is 8.4E-08 (works fine) and no %eps .

 

How Can I check if %eps is in?

 

 

De : users [mailto:[hidden email]] De la part de Stéphane Mottelet
Envoyé : mardi 29 janvier 2019 16:50
À : [hidden email]
Objet : [EXTERNAL] Re: [Scilab-users] acos leads to complex values

 

Le 29/01/2019 à 16:45, Carrico, Paul a écrit :

Dear All

 

I spent some time in looking for a mistake in my code ; finally I’ve found that the ACOS of a real vector leads to some complex values (???)

 

acos(Scar_P(:,1) ./ CM_x_CN(:,1))

Are your really sure, because we may have

--> x=-1-%eps
 x  =

  -1.


--> acos(x)
 ans  =

   3.1415927 - 2.107D-08i

S.

 

 

(the formula worked so far)

 

 

I checked that the input values are correct:

-          Comprised between [-1; 1] using MIN and MAX

-          Composed only of real values using ISREAL (all the vectors are correct)

 

Thus I do not understand why complex values appear ?

 

May it come from the vectorization ?

 

Paul

 

 

 



_______________________________________________
users mailing list
[hidden email]
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users

 

-- 
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
mottelet mottelet
Reply | Threaded
Open this post in threaded view
|

Re: [EXTERNAL] Re: acos leads to complex values

It is the same if x is slightly > 1:

--> x=1+%eps
 x  =

   1.


--> acos(x)
 ans  =

   2.107D-08i

--> format(25); x
 x  =

   1.0000000000000002220446

Le 29/01/2019 à 16:55, Carrico, Paul a écrit :

When I scroll to the list, the lowest (positive) value is 8.4E-08 (works fine) and no %eps .

 

How Can I check if %eps is in?

 

 

De : users [[hidden email]] De la part de Stéphane Mottelet
Envoyé : mardi 29 janvier 2019 16:50
À : [hidden email]
Objet : [EXTERNAL] Re: [Scilab-users] acos leads to complex values

 

Le 29/01/2019 à 16:45, Carrico, Paul a écrit :

Dear All

 

I spent some time in looking for a mistake in my code ; finally I’ve found that the ACOS of a real vector leads to some complex values (???)

 

acos(Scar_P(:,1) ./ CM_x_CN(:,1))

Are your really sure, because we may have

--> x=-1-%eps
 x  =

  -1.


--> acos(x)
 ans  =

   3.1415927 - 2.107D-08i

S.

 

 

(the formula worked so far)

 

 

I checked that the input values are correct:

-          Comprised between [-1; 1] using MIN and MAX

-          Composed only of real values using ISREAL (all the vectors are correct)

 

Thus I do not understand why complex values appear ?

 

May it come from the vectorization ?

 

Paul

 

 

 



_______________________________________________
users mailing list
[hidden email]
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users

 

-- 
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet

_______________________________________________
users mailing list
[hidden email]
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users


-- 
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
Carrico, Paul Carrico, Paul
Reply | Threaded
Open this post in threaded view
|

Re: [EXTERNAL] Re: acos leads to complex values

Stephane pointed out on the issue : after calculation and prior to the Acos one, some values were “1.0000000000000002220446” leading to “acos = 2.107D-08i” ; in addition he suggested me to use something like “acos(max(-1,min(1,-1.0000000000000002220446)))” or “acos(max(-1,min(1,1.0000000000000002220446)))” … very smart J

 

Thanks

 

Paul

 

 

 

 

EXPORT CONTROL :
Cet email ne contient pas de données techniques
This email does not contain technical data

 

De : users [mailto:[hidden email]] De la part de Stéphane Mottelet
Envoyé : mardi 29 janvier 2019 16:59
À : [hidden email]
Objet : Re: [Scilab-users] [EXTERNAL] Re: acos leads to complex values

 

It is the same if x is slightly > 1:

 

--> x=1+%eps
 x  =

   1.


--> acos(x)
 ans  =

   2.107D-08i

 

--> format(25); x
 x  =

   1.0000000000000002220446

 

Le 29/01/2019 à 16:55, Carrico, Paul a écrit :

When I scroll to the list, the lowest (positive) value is 8.4E-08 (works fine) and no %eps .

 

How Can I check if %eps is in?

 

 

De : users [[hidden email]] De la part de Stéphane Mottelet
Envoyé : mardi 29 janvier 2019 16:50
À : [hidden email]
Objet : [EXTERNAL] Re: [Scilab-users] acos leads to complex values

 

Le 29/01/2019 à 16:45, Carrico, Paul a écrit :

Dear All

 

I spent some time in looking for a mistake in my code ; finally I’ve found that the ACOS of a real vector leads to some complex values (???)

 

acos(Scar_P(:,1) ./ CM_x_CN(:,1))

Are your really sure, because we may have

--> x=-1-%eps
 x  =

  -1.


--> acos(x)
 ans  =

   3.1415927 - 2.107D-08i

S.

 

 

(the formula worked so far)

 

 

I checked that the input values are correct:

-          Comprised between [-1; 1] using MIN and MAX

-          Composed only of real values using ISREAL (all the vectors are correct)

 

Thus I do not understand why complex values appear ?

 

May it come from the vectorization ?

 

Paul

 

 

 




_______________________________________________
users mailing list
[hidden email]
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users

 

-- 
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet



_______________________________________________
users mailing list
[hidden email]
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users

 

-- 
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
fmiyara fmiyara
Reply | Threaded
Open this post in threaded view
|

Re: [EXTERNAL] Re: acos leads to complex values

In reply to this post by mottelet

I think it would be interesting to include an input argument check in some functions prone to give complex results in limiting cases (such as acos or asin) so that if inside the domain (to within 1 %eps) where the output argument should be real the imaginary part is canceled. Something like this for scalars:

function y=acos1(x)
if  isreal(x)
    if -1<=x & x<=1
        y = real(acos(x))
    else
        y = acos(x)
    end
end
endfunction

However, I must say that acos(1-%eps) gives on my Scilab 6.0.1 (Windows 7, i7 processor) a result of

0.000000021073424255447,

being %eps

0.0000000000000002220446

I get no imaginary part. I guess there must be some dependency on the arithmetic engine.
 

Federico Miyara


On 29/01/2019 12:58, Stéphane Mottelet wrote:
It is the same if x is slightly > 1:

--> x=1+%eps
 x  =

   1.


--> acos(x)
 ans  =

   2.107D-08i

--> format(25); x
 x  =

   1.0000000000000002220446

Le 29/01/2019 à 16:55, Carrico, Paul a écrit :

When I scroll to the list, the lowest (positive) value is 8.4E-08 (works fine) and no %eps .

 

How Can I check if %eps is in?

 

 

De : users [[hidden email]] De la part de Stéphane Mottelet
Envoyé : mardi 29 janvier 2019 16:50
À : [hidden email]
Objet : [EXTERNAL] Re: [Scilab-users] acos leads to complex values

 

Le 29/01/2019 à 16:45, Carrico, Paul a écrit :

Dear All

 

I spent some time in looking for a mistake in my code ; finally I’ve found that the ACOS of a real vector leads to some complex values (???)

 

acos(Scar_P(:,1) ./ CM_x_CN(:,1))

Are your really sure, because we may have

--> x=-1-%eps
 x  =

  -1.


--> acos(x)
 ans  =

   3.1415927 - 2.107D-08i

S.

 

 

(the formula worked so far)

 

 

I checked that the input values are correct:

-          Comprised between [-1; 1] using MIN and MAX

-          Composed only of real values using ISREAL (all the vectors are correct)

 

Thus I do not understand why complex values appear ?

 

May it come from the vectorization ?

 

Paul

 

 

 



_______________________________________________
users mailing list
[hidden email]
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users

 

-- 
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet

_______________________________________________
users mailing list
[hidden email]
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users


-- 
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet


_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users




Avast logo

El software de antivirus Avast ha analizado este correo electrónico en busca de virus.
www.avast.com



_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
fmiyara fmiyara
Reply | Threaded
Open this post in threaded view
|

Re: [EXTERNAL] Re: acos leads to complex values

In reply to this post by mottelet

In this case it should be imaginary...

Federico Miyara


On 29/01/2019 12:58, Stéphane Mottelet wrote:
It is the same if x is slightly > 1:

--> x=1+%eps
 x  =

   1.


--> acos(x)
 ans  =

   2.107D-08i

--> format(25); x
 x  =

   1.0000000000000002220446

Le 29/01/2019 à 16:55, Carrico, Paul a écrit :

When I scroll to the list, the lowest (positive) value is 8.4E-08 (works fine) and no %eps .

 

How Can I check if %eps is in?

 

 

De : users [[hidden email]] De la part de Stéphane Mottelet
Envoyé : mardi 29 janvier 2019 16:50
À : [hidden email]
Objet : [EXTERNAL] Re: [Scilab-users] acos leads to complex values

 

Le 29/01/2019 à 16:45, Carrico, Paul a écrit :

Dear All

 

I spent some time in looking for a mistake in my code ; finally I’ve found that the ACOS of a real vector leads to some complex values (???)

 

acos(Scar_P(:,1) ./ CM_x_CN(:,1))

Are your really sure, because we may have

--> x=-1-%eps
 x  =

  -1.


--> acos(x)
 ans  =

   3.1415927 - 2.107D-08i

S.

 

 

(the formula worked so far)

 

 

I checked that the input values are correct:

-          Comprised between [-1; 1] using MIN and MAX

-          Composed only of real values using ISREAL (all the vectors are correct)

 

Thus I do not understand why complex values appear ?

 

May it come from the vectorization ?

 

Paul

 

 

 



_______________________________________________
users mailing list
[hidden email]
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users

 

-- 
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet

_______________________________________________
users mailing list
[hidden email]
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users


-- 
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet


_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users




Avast logo

El software de antivirus Avast ha analizado este correo electrónico en busca de virus.
www.avast.com



_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
mottelet mottelet
Reply | Threaded
Open this post in threaded view
|

Re: [EXTERNAL] Re: acos leads to complex values

In reply to this post by fmiyara


Le 29/01/2019 à 20:48, Federico Miyara a écrit :

I think it would be interesting to include an input argument check in some functions prone to give complex results in limiting cases (such as acos or asin) so that if inside the domain (to within 1 %eps) where the output argument should be real the imaginary part is canceled. Something like this for scalars:

function y=acos1(x)
if  isreal(x)
    if -1<=x & x<=1
        y = real(acos(x))
    else
        y = acos(x)
    end
end
endfunction

However, I must say that acos(1-%eps) gives on my Scilab 6.0.1 (Windows 7, i7 processor) a result of
Federico, you have to try 1+%eps or -1-%eps !

0.000000021073424255447,

being %eps

0.0000000000000002220446

I get no imaginary part. I guess there must be some dependency on the arithmetic engine.
 

Federico Miyara


On 29/01/2019 12:58, Stéphane Mottelet wrote:
It is the same if x is slightly > 1:

--> x=1+%eps
 x  =

   1.


--> acos(x)
 ans  =

   2.107D-08i

--> format(25); x
 x  =

   1.0000000000000002220446

Le 29/01/2019 à 16:55, Carrico, Paul a écrit :

When I scroll to the list, the lowest (positive) value is 8.4E-08 (works fine) and no %eps .

 

How Can I check if %eps is in?

 

 

De : users [[hidden email]] De la part de Stéphane Mottelet
Envoyé : mardi 29 janvier 2019 16:50
À : [hidden email]
Objet : [EXTERNAL] Re: [Scilab-users] acos leads to complex values

 

Le 29/01/2019 à 16:45, Carrico, Paul a écrit :

Dear All

 

I spent some time in looking for a mistake in my code ; finally I’ve found that the ACOS of a real vector leads to some complex values (???)

 

acos(Scar_P(:,1) ./ CM_x_CN(:,1))

Are your really sure, because we may have

--> x=-1-%eps
 x  =

  -1.


--> acos(x)
 ans  =

   3.1415927 - 2.107D-08i

S.

 

 

(the formula worked so far)

 

 

I checked that the input values are correct:

-          Comprised between [-1; 1] using MIN and MAX

-          Composed only of real values using ISREAL (all the vectors are correct)

 

Thus I do not understand why complex values appear ?

 

May it come from the vectorization ?

 

Paul

 

 

 



_______________________________________________
users mailing list
[hidden email]
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users

 

-- 
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet

_______________________________________________
users mailing list
[hidden email]
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users


-- 
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet


_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users




Avast logo

El software de antivirus Avast ha analizado este correo electrónico en busca de virus.
www.avast.com



_______________________________________________
users mailing list
[hidden email]
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
fmiyara fmiyara
Reply | Threaded
Open this post in threaded view
|

Re: [EXTERNAL] Re: acos leads to complex values

In reply to this post by mottelet

This is an improved version of the acos function with input argument check:
 
function y=acos1(x)
    // Check if components are real
    is_real = imag(x)==0;
    // Leave real-only components
    x1 = is_real.*x;
    // Check if components are real and belong to [-1, 1]
    in_domain = is_real & (-1<=x1 & x1<=1);
    // Imaginary part of acos(x) is accepted only if 
    // x does not belong to [-1, 1] 
    y = in_domain.*real(acos(x)) + (~in_domain).*acos(x);
endfunction

This works on vectors and arrays as well. Unfortunately i couldn't find a component-wise isreal() function, otherwise it would have been simpler!
 
Federico Miyara


On 29/01/2019 12:58, Stéphane Mottelet wrote:
It is the same if x is slightly > 1:

--> x=1+%eps
 x  =

   1.


--> acos(x)
 ans  =

   2.107D-08i

--> format(25); x
 x  =

   1.0000000000000002220446

Le 29/01/2019 à 16:55, Carrico, Paul a écrit :

When I scroll to the list, the lowest (positive) value is 8.4E-08 (works fine) and no %eps .

 

How Can I check if %eps is in?

 

 

De : users [[hidden email]] De la part de Stéphane Mottelet
Envoyé : mardi 29 janvier 2019 16:50
À : [hidden email]
Objet : [EXTERNAL] Re: [Scilab-users] acos leads to complex values

 

Le 29/01/2019 à 16:45, Carrico, Paul a écrit :

Dear All

 

I spent some time in looking for a mistake in my code ; finally I’ve found that the ACOS of a real vector leads to some complex values (???)

 

acos(Scar_P(:,1) ./ CM_x_CN(:,1))

Are your really sure, because we may have

--> x=-1-%eps
 x  =

  -1.


--> acos(x)
 ans  =

   3.1415927 - 2.107D-08i

S.

 

 

(the formula worked so far)

 

 

I checked that the input values are correct:

-          Comprised between [-1; 1] using MIN and MAX

-          Composed only of real values using ISREAL (all the vectors are correct)

 

Thus I do not understand why complex values appear ?

 

May it come from the vectorization ?

 

Paul

 

 

 



_______________________________________________
users mailing list
[hidden email]
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users

 

-- 
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet

_______________________________________________
users mailing list
[hidden email]
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users


-- 
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet


_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users




Avast logo

El software de antivirus Avast ha analizado este correo electrónico en busca de virus.
www.avast.com



_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users

Attached Message Part (196 bytes) Download Attachment
fmiyara fmiyara
Reply | Threaded
Open this post in threaded view
|

Re: [EXTERNAL] Re: acos leads to complex values

In reply to this post by mottelet

Stephane,

However, I must say that acos(1-%eps) gives on my Scilab 6.0.1 (Windows 7, i7 processor) a result of
Federico, you have to try 1+%eps or -1-%eps !

acos(x) with x > 1 is indeed imaginary, so there is no unexpected result.

However, I see now that it hadn't been said that in-domain arguments yielded complex results but -1 - %eps was the culprit.

But, for instance,

min([-1-%eps, -1-%eps*2/3, -1, -1+ %eps, -0.9]) >= -1  

is false (on my system), so the test performed by Paul Carrico would not succeed if there were a -1-%eps among the values of the vector.

Only when alpha*%eps  with alpha < 0.5 is the minimum the test is successful, but in such case acos() yields a value close to %pi, not a complex value

--> acos(-1 - 0.499*%eps)
 ans  =

   3.141592653589793100000

When alpha > 0.5 the test is not successful nor is the acos() real:

--> acos(-1 - 0.50000001*%eps)
 ans  =

   3.141592653589793100000 - 0.000000021073424255447i

(this is a binary rounding situation since %eps is 2^-52)

I think the original question is not completely solved. Why a number that is not smaller to -1 (asuming the min test is successful) yields a complex acos?

An why it does in some systems and not in others? (Assuming Paul's report is accurate)

There is another situation where this happens, when an fft is performed on a real signal, then filtered in the frequency domain and then the ifft is applied. The result should be real, but sometimes there are small imaginary parts.

In this case there is a reason, complex exponentials are used in the algorithm so arithmetioc errors may not completely cancel out because of arithmetic and precision issues.

Federico Miyara



Avast logo

El software de antivirus Avast ha analizado este correo electrónico en busca de virus.
www.avast.com



_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
mottelet mottelet
Reply | Threaded
Open this post in threaded view
|

Re: [EXTERNAL] Re: acos leads to complex values


Le 29/01/2019 à 23:10, Federico Miyara a écrit :

Stephane,

However, I must say that acos(1-%eps) gives on my Scilab 6.0.1 (Windows 7, i7 processor) a result of
Federico, you have to try 1+%eps or -1-%eps !

acos(x) with x > 1 is indeed imaginary, so there is no unexpected result.

However, I see now that it hadn't been said that in-domain arguments yielded complex results but -1 - %eps was the culprit.

But, for instance,

min([-1-%eps, -1-%eps*2/3, -1, -1+ %eps, -0.9]) >= -1  

is false (on my system), so the test performed by Paul Carrico would not succeed if there were a -1-%eps among the values of the vector.

Only when alpha*%eps  with alpha < 0.5 is the minimum the test is successful, but in such case acos() yields a value close to %pi, not a complex value

--> acos(-1 - 0.499*%eps)
 ans  =

   3.141592653589793100000

logical, since

--> -1 - 0.499*%eps == -1
 ans  =

  T

--> acos(-1 - 0.499*%eps)==%pi
 ans  =

  T

S.


When alpha > 0.5 the test is not successful nor is the acos() real:

--> acos(-1 - 0.50000001*%eps)
 ans  =

   3.141592653589793100000 - 0.000000021073424255447i

(this is a binary rounding situation since %eps is 2^-52)

I think the original question is not completely solved. Why a number that is not smaller to -1 (asuming the min test is successful) yields a complex acos?

An why it does in some systems and not in others? (Assuming Paul's report is accurate)

There is another situation where this happens, when an fft is performed on a real signal, then filtered in the frequency domain and then the ifft is applied. The result should be real, but sometimes there are small imaginary parts.

In this case there is a reason, complex exponentials are used in the algorithm so arithmetioc errors may not completely cancel out because of arithmetic and precision issues.

Federico Miyara



Avast logo

El software de antivirus Avast ha analizado este correo electrónico en busca de virus.
www.avast.com



_______________________________________________
users mailing list
[hidden email]
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
Christophe Dang Ngoc Chan Christophe Dang Ngoc Chan
Reply | Threaded
Open this post in threaded view
|

Re: {EXT} Re: [EXTERNAL] Re: acos leads to complex values

In reply to this post by fmiyara

Hello,

 

> De : Federico Miyara

> Envoyé : mardi 29 janvier 2019 21:36

> 

> This is an improved version of the acos function with input argument check:

 

I would personally write it in the following way:

 

function y=acos1(x)

    // Check if components are real

    // Check if components are real and belong to [-1, 1]

    absx = abs(x);

    in_domain = (imag(x)==0) & (-1<=absx) & (absx<=1);

    // Imaginary part of acos(x) is accepted only if

    // x does not belong to [-1, 1]

    y=acos(x);

    y(in_domain) = real(y(in_domain));

endfunction

 

Regards

 

--

Christophe Dang Ngoc Chan

Mechanical calculation engineer

 

 

Public

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error), please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
fmiyara fmiyara
Reply | Threaded
Open this post in threaded view
|

[Scilab-users] Unexpected END OF FILE

In reply to this post by mottelet

Dear all,

I'm trying to read data from a file (in this case a wave file) with the following code (Scilab 6.0.1)
fid = mopen('g:\Mis documentos\Ondas\440Hz_0.2s.wav', 'r')
mseek(0, fid)
h = mgeti(1000,'uc',fid)
I should get a vector with 1000 unsigned 1 byte integer components but I end with only 164 entries. Viewing the file with an hex viewer, the last correctly read data are

34 3E 34 3E

(decimal 52 62 52 62)

Then the following data and further data

1A 3D 1A 3D  ...

are not read at all. No warning like having reached EOF. By the way, the repeated pairs are because it is a stereo file with identical left and right channels.

The same happens changing the way the file data are to be decoded. Seems to get stuck when 1A or 1A 3D appears.

Any idea of what may be going on and how to solve it?

Federico Miyara

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users

440Hz_0.2s.wav (53K) Download Attachment
Antoine ELIAS-2 Antoine ELIAS-2
Reply | Threaded
Open this post in threaded view
|

Re: Unexpected END OF FILE

Hello Frederico,

On Windows, you should open your file in binary mode, with "rb".
--> fd = mopen("440Hz_0.2s.wav", "rb");
--> h = mgeti(1000, "uc", fd);
--> size(h)
 ans  =
   1.   1000.

--> dec2hex(h(1:5))
 ans  =
!52  49  46  46  84  !

Regards,
Antoine
Le 30/01/2019 à 23:02, Federico Miyara a écrit :

Dear all,

I'm trying to read data from a file (in this case a wave file) with the following code (Scilab 6.0.1)
fid = mopen('g:\Mis documentos\Ondas\440Hz_0.2s.wav', 'r')
mseek(0, fid)
h = mgeti(1000,'uc',fid)
I should get a vector with 1000 unsigned 1 byte integer components but I end with only 164 entries. Viewing the file with an hex viewer, the last correctly read data are

34 3E 34 3E

(decimal 52 62 52 62)

Then the following data and further data

1A 3D 1A 3D  ...

are not read at all. No warning like having reached EOF. By the way, the repeated pairs are because it is a stereo file with identical left and right channels.

The same happens changing the way the file data are to be decoded. Seems to get stuck when 1A or 1A 3D appears.

Any idea of what may be going on and how to solve it?

Federico Miyara

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users


_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
fmiyara fmiyara
Reply | Threaded
Open this post in threaded view
|

Re: Unexpected END OF FILE


Antoine,

Thank you VERY MUCH!

That works. Is there a fundamental reason why not specifying binary fails somewhere? Some sort of EOF code that may present itself randomly according to file content?

Regards,

Federico


On 30/01/2019 20:07, Antoine ELIAS wrote:
Hello Frederico,

On Windows, you should open your file in binary mode, with "rb".
--> fd = mopen("440Hz_0.2s.wav", "rb");
--> h = mgeti(1000, "uc", fd);
--> size(h)
 ans  =
   1.   1000.

--> dec2hex(h(1:5))
 ans  =
!52  49  46  46  84  !

Regards,
Antoine
Le 30/01/2019 à 23:02, Federico Miyara a écrit :

Dear all,

I'm trying to read data from a file (in this case a wave file) with the following code (Scilab 6.0.1)
fid = mopen('g:\Mis documentos\Ondas\440Hz_0.2s.wav', 'r')
mseek(0, fid)
h = mgeti(1000,'uc',fid)
I should get a vector with 1000 unsigned 1 byte integer components but I end with only 164 entries. Viewing the file with an hex viewer, the last correctly read data are

34 3E 34 3E

(decimal 52 62 52 62)

Then the following data and further data

1A 3D 1A 3D  ...

are not read at all. No warning like having reached EOF. By the way, the repeated pairs are because it is a stereo file with identical left and right channels.

The same happens changing the way the file data are to be decoded. Seems to get stuck when 1A or 1A 3D appears.

Any idea of what may be going on and how to solve it?

Federico Miyara

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users



_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users


_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
mottelet mottelet
Reply | Threaded
Open this post in threaded view
|

Re: Unexpected END OF FILE

Hello Frederico,

We just fixed it for Scilab 6.0.2, see 


S.

Le 31 janv. 2019 à 01:20, Federico Miyara <[hidden email]> a écrit :


Antoine,

Thank you VERY MUCH!

That works. Is there a fundamental reason why not specifying binary fails somewhere? Some sort of EOF code that may present itself randomly according to file content?

Regards,

Federico


On 30/01/2019 20:07, Antoine ELIAS wrote:
Hello Frederico,

On Windows, you should open your file in binary mode, with "rb".
--> fd = mopen("440Hz_0.2s.wav", "rb");
--> h = mgeti(1000, "uc", fd);
--> size(h)
 ans  =
   1.   1000.

--> dec2hex(h(1:5))
 ans  =
!52  49  46  46  84  !

Regards,
Antoine
Le 30/01/2019 à 23:02, Federico Miyara a écrit :

Dear all,

I'm trying to read data from a file (in this case a wave file) with the following code (Scilab 6.0.1)
fid = mopen('g:\Mis documentos\Ondas\440Hz_0.2s.wav', 'r')
mseek(0, fid)
h = mgeti(1000,'uc',fid)
I should get a vector with 1000 unsigned 1 byte integer components but I end with only 164 entries. Viewing the file with an hex viewer, the last correctly read data are

34 3E 34 3E

(decimal 52 62 52 62)

Then the following data and further data

1A 3D 1A 3D  ...

are not read at all. No warning like having reached EOF. By the way, the repeated pairs are because it is a stereo file with identical left and right channels.

The same happens changing the way the file data are to be decoded. Seems to get stuck when 1A or 1A 3D appears.

Any idea of what may be going on and how to solve it?

Federico Miyara

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users



_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users


_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
mottelet mottelet
Reply | Threaded
Open this post in threaded view
|

Re: Unexpected END OF FILE

Le 31/01/2019 à 07:27, Stéphane Mottelet a écrit :
Hello Frederico,

We just fixed it for Scilab 6.0.2, see 


S.

I mean, the doc says that binary mode for writing or reading is the default but it was not the case under Windows, where *text* mode was the default, and in this mode char of hex code 1A is EOF (in binary EOF is just a condition not a char).

S.


Le 31 janv. 2019 à 01:20, Federico Miyara <[hidden email]> a écrit :


Antoine,

Thank you VERY MUCH!

That works. Is there a fundamental reason why not specifying binary fails somewhere? Some sort of EOF code that may present itself randomly according to file content?

Regards,

Federico


On 30/01/2019 20:07, Antoine ELIAS wrote:
Hello Frederico,

On Windows, you should open your file in binary mode, with "rb".
--> fd = mopen("440Hz_0.2s.wav", "rb");
--> h = mgeti(1000, "uc", fd);
--> size(h)
 ans  =
   1.   1000.

--> dec2hex(h(1:5))
 ans  =
!52  49  46  46  84  !

Regards,
Antoine
Le 30/01/2019 à 23:02, Federico Miyara a écrit :

Dear all,

I'm trying to read data from a file (in this case a wave file) with the following code (Scilab 6.0.1)
fid = mopen('g:\Mis documentos\Ondas\440Hz_0.2s.wav', 'r')
mseek(0, fid)
h = mgeti(1000,'uc',fid)
I should get a vector with 1000 unsigned 1 byte integer components but I end with only 164 entries. Viewing the file with an hex viewer, the last correctly read data are

34 3E 34 3E

(decimal 52 62 52 62)

Then the following data and further data

1A 3D 1A 3D  ...

are not read at all. No warning like having reached EOF. By the way, the repeated pairs are because it is a stereo file with identical left and right channels.

The same happens changing the way the file data are to be decoded. Seems to get stuck when 1A or 1A 3D appears.

Any idea of what may be going on and how to solve it?

Federico Miyara

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users



_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users


_______________________________________________
users mailing list
[hidden email]
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users


-- 
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
fmiyara fmiyara
Reply | Threaded
Open this post in threaded view
|

Re: Unexpected END OF FILE


Stéphane,

> I mean, the doc says that binary mode for writing or reading is the
> default but it was not the case under Windows, where *text* mode was
> the default, and in this mode char of hex code 1A is EOF (in binary
> EOF is just a condition not a char).
>

Thank you for crlarifying. Now I completely understand the issue!

Regards,

Federico



---
El software de antivirus Avast ha analizado este correo electrónico en busca de virus.
https://www.avast.com/antivirus

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users