CWindow Release Candidate 31

[José Roca]

With PowerBASIC the parameter is optional and a NULL is also being passed. The returned message does not make sense to me. It is not even listed in the list of possible errors in the MSDN documentation for the CreateDomain method.

[José Roca]

And CreateDomainEx also fails with the same error. These are the only two that have an string parameter in this interface, so it is my main suspect.

[José Roca]

I also have tried

Code Select Expand


   DIM ppEvidence AS IUnknown PTR
   m_pCorRuntimeHost->CreateEvidence(@ppEvidence)
   DIM hr AS HRESULT = m_pCorRuntimeHost->CreateDomain(@wszFriendlyName, ppEvidence, cast(ANY PTR, @pUnk))


and also fails.

Looks like the string parameter is the problem, but I have also tried passing a BSTR and even a CWSTR and a ZSTRING and it fails. I don't understand why.

[Paul Squires]

Have you been able to figure out the string problem? Problems like this must drive you crazy!    

[José Roca]

No. I have tried everything and always get the same error. Yet similar code works with PowerBasic. Everything else works, so we can use it using the default domain. Custom domains aren't indispensable, just convenient for some tasks.

Some time ago I had a problem to add OpenGL support to the graphic control. Some months later, I tried again and it worked. I can't tell you where was the problem, because I had discarded the code and started from scratch.

Meanwhile, I have been working writing wrapper functions to support Complex numbers. Instead of a class, this time I have used plain functions and use the Afx namespace to avoid conflicts.

Code Select Expand


#include once "AfxComplex.inc"

DIM cpx1 AS _complex = (3, 4)
DIM cpx2 AS _complex = (5, 6)
cpx1 = cpx1 + cpx2
print Afx.Cstr(cpx1)


There are a lot of math functions, most of which I have already checked that return the right results. The most complex functions are an adaptation of the ones from the GSL - GNU Scientific Library, which unfortunately is LGPL.

[Johan Klassen]

hello Jose Roca
just in case you need to have a look at complex functions implementation there's this library http://www.wolfgang-ehrhardt.de/misc_en.html#damath

License

(C) Copyright 2002-2017 Wolfgang Ehrhardt

Copying Conditions

This software is provided 'as-is', without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this software.

Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the following restrictions:

1. The origin of this software must not be misrepresented; you must not claim that you wrote the original software. If you use this software in a product, an acknowledgment in the product documentation would be appreciated but is not required.

2. Altered source versions must be plainly marked as such, and must not be misrepresented as being the original software.

3. This notice may not be removed or altered from any source distribution.

[José Roca]

Thanks for the link. I already have implemented a big amount of functions and, more important, I have checked that all of them work correctly. Don't know if I will add more. Math is not my forte.

[José Roca]

I'm replacing the GSL functions with translations of the .NET System.Numerics/System/Numerics/Complex.cs class (source code: https://github.com/Microsoft/referencesource/blob/master/System.Numerics/System/Numerics/Complex.cs ) and apparently the code for the Asin and Acos methods is reversed! I have checked results with GSL and from MATLAB examples, and Asin returns the expected results for Acos, and viceversa.

The reason of the replacement is because this .NET class as a MIT license, whereas GSL as a GPL license.

[José Roca]

And also differs in the sign of the imaginary part, + instead of - (according the other sources). Looks like they have got everything reversed. Anybody has the means to ascertain which source is right?

Code Select Expand


' ========================================================================================
' * Returns the complex arcsine of a complex number.
' The branch cuts are on the real axis, less than -1 and greater than 1.
' Example:
'   DIM z AS _complex = (1, 1)
'   z = AfxCArcSin(z)
'   PRINT AfxCStr(z)
' Output: 0.6662394324925152 +1.061275061905036 * i
' ========================================================================================
' ========================================================================================
' - NET 4.7 code:
' public static Complex Acos(Complex value) /* Arccos */
' { return (-ImaginaryOne) * Log(value + ImaginaryOne*Sqrt(One - (value * value))); }
' Note: Apparently, .NET has got the code for the Asin and Acos function revesed!
' It also returns -1.061275061905036 * i instead of +1.061275061905036 * i in the above example.
' ========================================================================================
PRIVATE FUNCTION AfxCArcSin (BYREF value AS _complex) AS _complex
   DIM ImaginaryOne AS _complex = TYPE<_complex>(0.0, 1.0)
   DIM One AS _complex = TYPE<_complex>(1.0, 0.0)
'   RETURN (-ImaginaryOne) * AfxCLog(value + ImaginaryOne * AfxCSqr(One - (value * value)))
   DIM z AS _complex = AfxCLog(value + ImaginaryOne * AfxCSqr(One - (value * value)))
   RETURN TYPE<_complex>(z.y, z.x)
END FUNCTION
' ========================================================================================


Code Select Expand


' ========================================================================================
' * Returns the complex arccosine of a complex number.
' The branch cuts are on the real axis, less than -1 and greater than 1.
' Example:
'   DIM z AS _complex = (1, 1)
'   z = AfxCArcCos(z)
'   print AfxCStr(z)
' Output: 0.9045568943023814 -1.061275061905036 * i
' ========================================================================================
' ========================================================================================
' - NET 4.7 code:
' public static Complex Asin(Complex value) /* Arcsin */
' { return (-ImaginaryOne) * Log(ImaginaryOne * value + Sqrt(One - value * value)); }
' Note: Apparently, .NET has got the code for the Asin and Acos function revesed!
' It also returns +1.061275061905036 * i instead of -1.061275061905036 * i in the above example.
' ========================================================================================
PRIVATE FUNCTION AfxCArcCos (BYREF value AS _complex) AS _complex
   DIM ImaginaryOne AS _complex = TYPE<_complex>(0.0, 1.0)
   DIM One AS _complex = TYPE<_complex>(1.0, 0.0)
'   RETURN (-ImaginaryOne) * AfxCLog(ImaginaryOne * value + AfxCSqr(One - value * value))
   DIM z AS _complex = AfxCLog(ImaginaryOne * value + AfxCSqr(One - value * value))
   RETURN TYPE<_complex>(z.y, z.x)
END FUNCTION
' ========================================================================================


[José Roca]

Another problem with the sign in the arctangent function.

Code Select Expand


' ========================================================================================
' * This function returns the complex arctangent of a complex number.
' The branch cuts are on the imaginary axis, below -i and above i.
' Example:
'   DIM z AS _complex = (1, 1)
'   z = AfxCArcTan(z)
'   PRINT AfxCStr(z)
' Output: 1.017221967897851 +0.4023594781085251 * i
' ========================================================================================
' ========================================================================================
' - NET 4.7 code:
' public static Complex Atan(Complex value) /* Arctan */
' {
'    Complex Two = new Complex(2.0, 0.0);
'    return (ImaginaryOne / Two) * (Log(One - ImaginaryOne * value) - Log(One + ImaginaryOne * value));
' }
' Note: It returns -0.4023594781085251 * i instead of +0.4023594781085251 * i, so I have
' needed to use a workaround.
' ========================================================================================
' ========================================================================================
PRIVATE FUNCTION AfxCArcTan (BYREF value AS _complex) AS _complex
   DIM ImaginaryOne AS _complex = TYPE<_complex>(0.0, 1.0)
   DIM One AS _complex = TYPE<_complex>(1.0, 0.0)
   DIM Two AS _complex = TYPE<_complex>(2.0, 0.0)
'   RETURN (ImaginaryOne / Two) * (AfxCLog(One - ImaginaryOne * value) - AfxCLog(One + ImaginaryOne * value))
   DIM z AS _complex = AfxCLog(One - ImaginaryOne * value) - AfxCLog(One + ImaginaryOne * value)
   z /= 2 : DIM temp AS DOUBLE = z.x : z.x = z.y : z.y = temp
   RETURN z
END FUNCTION
' ========================================================================================


[Johan Klassen]

hello Jose Roca
I downloaded your AfxComplex and it agrees with pari/gp
however the functions in your last posts give wrong result, is AfxClog giving the right result?
note: I changed the call to AfxClog to Clog because AfxClog is not posted.

[José Roca]

Forget the previous code. I have fully reworked the module to get rid of the GSL code beause the GNU Scientific Library has a GPL license. Some of the new functions are based in code from Complex.cs class for .NET, that uses the more permissive MIT license. I also have changed the naming convention and removed the namespace to make the module fully independent of my framework (as soon as you use some open source code, you risk to "contaminate" all the rest of your code).

It seems to be working fine, although apparently the .NET code for Acos and Asin, that I have used in the AfxCArcSin and AfxCArcCos functions, seems to be reversed, so I have swaped it. These two functions and Atan (code used in AfxCArcTan) also return a wrong sign, so I have used a workaround.

[Johan Klassen]

there's a problem with AfxClog

Code Select Expand


dim as _complex y, x=(1,1)
y=AfxCexp(x)
y=AfxClog(y)
print y.x, y.y '-> 1             0.5707963267948967

I think the culprit is atan2, if you swap the arguments it seems to work, but then the other function are broke, perhaps this was the cause of your problems all along.

[José Roca]

Yes, AfxCLog is wrong. I will have to fix it and then recheck all the other functions that use it. I was surprised of such a "bug" in a .NET class and thought that I was missing something. Thanks very much for spotting it.

[José Roca]

> perhaps this was the cause of your problems all along.

Yes, that was it. It was I who was reversing the result, not the .NET class. It has been an easy fix because I had the original code remed just before the workaround code, so I only have needed to unrem it and remove the other code. I didn't notice the bug in AfxCLog because, unfortunately, with the values that I used to test it the result was right.