at3s

I tried in Delphi to make working a C++ sample (Character spacing in RichEdit control) but spacing does not change (doc.Selection.Font.Spacing).

I guess, Font.Spacing is deprecated but not sure.

Did someone something similar or can confirm it's not possible? 

1 hour ago, David Heffernan said:

Then I don't know why you asked if it was possible to do something that you were already doing.

I'm interesting in eigen tasks solving has been implemented in my project.

Since an implementation of Aberth–Ehrlich method was fail, I've implemented libopenblas.dll function calling.
And now I'm trying to implement Eigen library usage as you proposed.
But speed of calculation is a top priority requirement for me.

9 hours ago, David Heffernan said:

Possible. But I doubt it. I bet you are asking different questions, and not comparing like with like. 

I just trying to check if it's possible to find eigenvalues\eigenvectors using Eigen library so fast as libopenblas.dll does.

9 hours ago, David Heffernan said:

Quite simple to call libopenblas from delphi. I do just that.

I am as well.

2 minutes ago, David Heffernan said:

OK, I see. We'll, I don't really know. It seems odd because they use the same algorithm as I understand it. I imagine there is a good explanation. But there'd need to be more detail.  

I geuss the difference is because LAPACK is based on Fortran math.

And probably one of reason is Fortran is faster in calculations.

The other one could be difference in algorythm as well.

I'm interesting, if it's possible to call a Fortran function within the Delphi code like libopenblas.dll does?

15 minutes ago, David Heffernan said:

Your lapack call does not calculate eigen vectors. The eigen call does. 

Nope, it does.

Truth is that it doesn't compute "left" eigenvectors (vl array), but "right" yes (vr array).

2 minutes ago, David Heffernan said:

That would be surprising. I wouldn't want to comment without seeing what options you used when calling the functions.  

Actually I did not make a wrapper for Eigen library yet, but rather ran within the VC++ code:

Eigen::MatrixXcd A(n, n);
Eigen::ComplexEigenSolver<Eigen::MatrixXcd> es_c(A);

And simple calling of function from the libopenblas.dll within the Delphi:

LAPACKE_zgeev(101, 'N', 'V', n, a, lda, w, vl, ldvl, vr, ldvr);

It was tested for the same 150x150 matrix with the complex values.

VC++ ComplexEigenSolver: 19.0 s

Delphi LAPACKE_zgeev:          1.5 s
 

On 8/20/2020 at 10:10 PM, David Heffernan said:

ARPACK is recommended for extracting a small number of eigen vectors from a huge problem.

 

LAPACK has effective methods for extracting all solutions using a direct method. 

 

Neither are easy to use from Delphi. I have done so but it isn't for the faint of heart. Especially ARPACK. 

 

The famous C++ Eigen library is very capable though and easy to use. I'd suggest you wrap that in a DLL. 

 

Start in Matlab to prove that it can do the calculation sufficiently quickly for a typical matrix that you will work with. 

 

Then write a C++ program in Eigen to solve the same problems. Does that work effectively? 

 

Then, and only then, try to wrap it up to be called from Delphi. 

I've noticed that Eigen::ComplexEigenSolver works much slower for large matrices than LAPACKE_zgeev from OpenBLAS library.

2 minutes ago, mausmb said:

Hi,

 

You didn't specify the path. 

 

assests\internal is for deployment

 

TPath.GetDocumentsPath, 'db.s3db' is for PATH

 

br,

M

Well, I found solution. It was my bad.

I had

FDConnection.Params.OpenMode = omCreateUTF8

So changing it to omReadWrite rather is a solution.

9 hours ago, JDS2018 said:

Keep all The Query components in data-module, if you keep FDconnection and Query or table in another form this error gives, i had the same issue. so then i kept all tables in side Data-module , its work fine.

Thank you for your answer.

Unfortunately it didn't fix my issue.

Probably I have to describe more details here.

My SQLite database has predefined tables inside with the data.

It's added to deploy to an Android device into 'assets\internal'.

But when I did:

FDConnection.Connected := True;
FDQuery.Open; 

the application raised an exception [FireDAC][Phys][SQLite] ERROR: no such table: items.

But when I've added code below:

procedure Tdm.FDConnectionBeforeConnect(Sender: TObject);
begin
  {$IF DEFINED(iOS) or DEFINED(ANDROID)}
  FDConnection.Params.Values['Database'] :=
      TPath.Combine(TPath.GetDocumentsPath, 'db.s3db');
  {$ENDIF}
end;

procedure Tdm.FDConnectionAfterConnect(Sender: TObject);
begin
  FDConnection.ExecSQL('CREATE TABLE IF NOT EXISTS items (id INTEGER PRIMARY KEY, image_name TEXT, name TEXT)');
end;

FDQuery opens properly.

It seems, that database file was not deployed to the Android device.

What I did wrong?

Few months ago I prepared small demo application used FireDAC SQLite connection on an Android system.

And it worked fine in an application built in Delphi 10.3.

Then I updated Delphi to 10.4.

And now I got:

Project xxx.apk raised exception class ESQLiteNativeException with message ''. 

and after that:

[FireDAC][Phys][SQLite] ERROR: no such table: items.

Even table 'items' exists in the database file and I did not any changes in sources.

Anyone had the same issue?

1 hour ago, Fr0sT.Brutal said:

AFAIK even the strictest GPL allows dynamic linking without the burden of opening your code

Are you sure about dynamically linked GPL?

Based on my research in the web, it's not so clear.

Or I'm wrong?

dll is a wrapper of MPL 2.0 C++ library.

Can I use this dll in my commercial project (an executable dynamically calls a function of dll)?

Will users be able to request sources of this dll only or all my whole project?

10 hours ago, David Heffernan said:

If your goal is to find eigenvalues then you should use a dedicated library for that. There are a good few about that can handle matrices with sizes in the thousands.

 

It sounds like you are trying to find roots of the characteristic polynomial. This is not a robust approach.  

Can you please suggest libraries for the eigenvalues\eigenvectors finding?

Is it possible to use them in Delphi code?

Here is part of my sources where is a main calculation:

    var
	  j: SmallInt;
	  nTmp, nDiv, nRootsValueOfFunction, nRootsValueOfDerivative: TComplex;
...
	function _GetValueOfFunction(ACoeff: TEquation; AValue: TComplex): TComplex; // calculate value of function F
	begin
	  Result := ACoeff.GetValueOfFunction(AValue);
	end;

	function _GetValueOfDerivative(ACoeff: TEquation; AValue: TComplex): TComplex;
	begin
	  Result := ACoeff.GetValueOfDerivative(AValue); // calculate value of derivative of function F (F')
	end;
...
	for i:= 0 to Pred(mxRoots.Cols) do
	begin      
      if not arrExcited[i] then // is not a "root" yet
      begin
        // calculate denominator
        nTmp := 0;
        for j := 0 to Pred(mxRoots.Cols) do
          if j <> i then
          begin
            nTmp := nTmp + 1 / (mxPrevRoots[0, i] - mxPrevRoots[0, j]); // mxRoots - array of root candidates; mxPrevRoots - array of "previous" root candidates
          end;
        nDiv := mxPrevRootsValueOfFunction[0, i] / mxPrevRootsValueOfDerivative[0, i]; // F/ F'
        mxRoots[0, i] := mxPrevRoots[0, i] - nDiv / (1 - nDiv * nTmp); // current calculated root value
        nRootsValueOfFunction := _GetValueOfFunction(_Self, mxRoots[0, i]); // calculate value of function F in mxRoots[0, i]
        nRootsValueOfDerivative := _GetValueOfDerivative(_Self, mxRoots[0, i]); // calculate value of derivative of function F (F') in mxRoots[0, i]
        if
          (nRootsValueOfFunction = 0)
          or
          ((mxRoots[0, i] - mxPrevRoots[0, i]).Abs <= AMistake) // detect that previous and actual roots values changed less than input error
        then
        begin
          arrExcited[i] := True; // array of Boolean; True - root is found
          Inc(iRootsCnt); // total amount of found roots
        end;
        else
        begin
          mxPrevRootsValueOfFunction[0, i] := nRootsValueOfFunction;
          mxPrevRootsValueOfDerivative[0, i] := nRootsValueOfDerivative;
        end;
	  end;
    end;

Probably someone will tell me what could be wrong here.

I'll try to compile my code in FPC, but I did not have experience with it and not sure if it's compilable there.

1 minute ago, Anders Melander said:

Yes they both suffer from floating point rounding errors. The fact that the exact error values differ doesn't make any difference. All compilers will suffer from this as the imprecision is inherent in the nature of floating point precision. Higher precision will make the error smaller but there will still be errors.

 

As David points out the only way to avoid that is to use another algorithm. If that isn't practical then one might try to implement with an arbitrary precision library.

I'm not agree. As I mentioned above, when I used MPArith library and tested matrice 50x50, I got exactly the same result as Octave (did not test in Matlab, but there is not differences in eigenvalues results).

I also thought, I did something wrong in initial roots defining (based on Gershgorin circles).

But when I got that result with MPArith, I was convinced the problem is not in algorithm realization.