David Heffernan

1 minute ago, at3s said:

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

I'd be astounded if that was not the case. Eigen has a very good reputation. Certainly for basic matrix arithmetic performance is excellent. And I'd be astonished if it could not match openblas for eigensolves.

1 minute ago, at3s said:

I am as well.

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

14 minutes ago, at3s said:

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

That isn't it. 

14 minutes ago, at3s said:

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

Not true. C++ compilers can perform just as well. 

15 minutes ago, at3s said:

The other one could be difference in algorythm as well.

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

16 minutes ago, at3s said:

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

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

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. 

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

2 hours ago, at3s said:

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

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

1 hour ago, Mike Torrettinni said:

Aha, but if each type requires different attribute values, each type has to have it's own attribute. That's how I understand your example and documentation, but have no actual experience with attributes, yet.

Unless all of your enumerated types have the same names, it seems like you'd have to provide names for each type. 

10 minutes ago, Mike Torrettinni said:

Yes, you are right. For a few minutes I was excited about the possibility 🙂

You have misunderstood me. The attribute is independent of the type. Therefore it can be used with any type. 

18 minutes ago, Mike Torrettinni said:

If I have 10 different types, would I still need to defined 10 different Attribute classes:

As you can see from the code, the attribute class is called NamesAttribute and is independent from the type. Otherwise the whole thing would be pointless. 

I do this;

  [Names(
    'Curvature',
    'Bend angle'
  )]
  TPreBendSpecifiedBy = (
    pbsCurvature,
    pbsBendAngle
  );

and then I can write:

Assert(Enum.Name(pbsCurvature) = 'Curvature'))

Of course this requires some library code behind it, but it's pretty convenient.

I can’t see past

// must call all functions, defeat short circuit evaluation
aVal := A();
bVal := B();
cVal := C();
Result := aVal or bVal or cVal;

I don’t care for temporarily disabling short circuit evaluation. I’d rather have the predictability of one rule for expression evaluation. Mix and match adds an impedance to understanding for the reader. 

6 hours ago, Mike Torrettinni said:

OK, now that I know I can't create helper on TXMLNode.GetAttribute(name😞 string to work with .ToInteger, I can add GetAttributeAsInteger, like this

Yes. This is what I said in my earlier comments. 

The helper is on the node. So you’d need to call vNode.ToInteger(‘Id’). I think you could do with a better name for the helper function.

You have to pass the attribute name to the helper function. Also, don't call GetAttribute twice. Store the return value in a local variable. 

3 hours ago, at3s said:

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

Is it possible to use them in Delphi code?

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. 

4 hours ago, Mahdi Safsafi said:

For the same reason why anybody should think that your comment is constructive

It wasn't aimed at the OP. It was aimed at all the misleading posters who guessed and speculated. In my opinion it is those posts that are harmful to the OP's chance of progress. 

This topic requires knowledge of numerical methods for solving eigenproblems. Most of the posts have not lived up to that. 

Why does anybody think that all this guessing would be useful? Does anybody have much experience of success when guessing?

Solving eigen problems is a very challenging numerical problem.  Does anybody really believe that good solutions arise from guesswork?

I am frankly embarrassed by this thread.

1 hour ago, Anders Melander said:

If that isn't practical

It is practical. It is routine to solve eigen problems for systems of thousands of variables.

@Kas Ob.It's pointless trying to argue about making the wrong solution work. 

4 minutes ago, Kas Ob. said:

Have a look here 

https://lemire.me/blog/2020/06/26/gcc-not-nearest/

 

Means even one compiler can generate code and produce different result with different compile settings !

So yes there is chance that FPC is doing better or worse, as OP asked for thoughts for brainstorming, so i provided some thoughts,

 

Take as example "floating-point numbers are not associative" (from that article) which not so many knows and might not need to care even, it doesn't matter that much per one value, but in the case of Aberth method it will accumulate and slide far from the right value, and i am not saying associative property is the problem, no, many things can go south.

Try other compilers isn't going to make any difference here. Other compilers will face the same problems.

I am reasonably confident that the correct way forward is to use the right tool for the job. And root finding of the characteristic polynomial is not the way to find eigenvalues on a finite computer.

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. 

3 hours ago, Mahdi Safsafi said:

Mention a study, benchmark or a formal statement that claims your words. 

I don't need to. I'm not the one making the claim that all huge memory allocations should be made using VirtualAlloc. It's you that is making that claim.

8 hours ago, David Schwartz said:

So you put it in a try...except

Well not necessarily. Typically you let exceptions float upwards to be handled by some high level exception handler. 

7 hours ago, Mahdi Safsafi said:

Obviously soon or later, a system paging will work and starts to swap pages from memory to disk. 

Not obvious at all. Usually you allocated memory because you wanted to use it.

If you've swapped the entire block to disk then bringing a couple of pages back is the least of your worries. Solve your problem by avoiding swapping in the first place.

Nothing you have said, in my view, supports your claim that all allocation of huge blocks should be done using VirtualAlloc.

3 hours ago, Mahdi Safsafi said:

Are you saying that the benchmark from the article is not enough ?

I don't see any benchmark to support the assertion that all allocation of huge blocks should be done using VirtualAlloc.

Can you point to it. 

5 hours ago, Mahdi Safsafi said:

I also recommend that you read the above article. It will change your mind about when to call it "Premature optimisation" and when not !

A valid benchmark from a real world program would make me consider what I said.