at3s

Sure. Here is a unit: unit uRichEdit; interface uses System.SysUtils , Winapi.Windows , Vcl.ComCtrls , Winapi.RichEdit , tom_TLB ; type TRichEditHelper = class helper for TRichEdit private class function reGetTextDocument(RichEdit: TRichEdit): ITextDocument; public class function reSpacing(ARichEdit: TRichEdit; ASpaces: Integer): Boolean; end; implementation { TRichEditHelper } class function TRichEditHelper.reGetTextDocument( RichEdit: TRichEdit): ITextDocument; var re: IUnknown; begin if RichEdit.Perform(EM_GETOLEINTERFACE, 0, LParam(@re)) = 0 then begin Result := nil; Exit; end; re._AddRef; if not Supports(re, ITextDocument, Result) then Result := nil; end; class function TRichEditHelper.reSpacing(ARichEdit: TRichEdit; ASpaces: Integer): Boolean; var doc: ITextDocument; spacing: Single; begin doc := reGetTextDocument(ARichEdit); doc.Selection.Start := 0; doc.Selection.End_ := Length(doc.Selection.Text); doc.Selection.Font.Spacing := ASpaces; end; end. and its using: TRichEdit.RichEditSpacing(reSample, 10); You have to import 'tom' type library.

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?

I've implemented Aberth–Ehrlich method for finding all roots of polynomial (actually it's one of steps of eigenvalues finding). It works very well with the degree less or equal 25. But when degree is larger, my Delphi calculations begin to fail. In both cases speed of calctions is acceptable (< 1 sec). I'm quite sure it's because an accumulation of errors of very small and very large numbers during calculations. For an algorithm needs I've developer TComplex = record … end; structure based on Double. The same result I got when the base data type is Extended. I'm quite sure the problem is not an algorithm, because when I've updated TComplex to use MPArith multi precision library rather, I got exactly the same results as Octave and Matlab programs - so I assume they are correct. But in this case time of calculation is veeery slooow (more than 20 min) because MPArith works with the memory rather. So my questions are: Do you know how to bypass multi precision issue in Delphi? Do you think, if I'll port realization of calculation to another programming language (f.e. C++, C# or any other), I'll have no problem with the precision of calculations? Sure, I'll have to wrap it into dll to call within the Delphi code. Did you already fixed a similar issue related to multi precision (maybe other more fast library)? Any thoughts are welcome.

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.

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

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?

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

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

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

Well, I found solution. It was my bad. I had FDConnection.Params.OpenMode = omCreateUTF8 So changing it to omReadWrite rather is a solution.

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?

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?

Are you sure about dynamically linked GPL? Based on my research in the web, it's not so clear. Or I'm wrong?

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.

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.