Lazarus

Announcements => Third party => Topic started by: glorfin on July 17, 2020, 11:26:07 pm

Title: LMath new version (LMath and Components 0.5)
Post by: glorfin on July 17, 2020, 11:26:07 pm
New version of LMath library (further development of DMath from Jean Debord).
Here are most important changes.
This document describes what is new in LMath compared to DMath:
https://sourceforge.net/projects/lmath-library/files/DOC/LMath05/New_in_LMath.pdf/download (https://sourceforge.net/projects/lmath-library/files/DOC/LMath05/New_in_LMath.pdf/download)

The library may be downloaded from Sourceforge:
https://sourceforge.net/projects/lmath-library/files/LMath/lmath_and_components_0_5.zip/download (https://sourceforge.net/projects/lmath-library/files/LMath/lmath_and_components_0_5.zip/download)

Note, that this is still beta-version. Bug reports and suggestion for the development will be greatly appreciated.

Title: Re: LMath new version (LMath and Components 0.5)
Post by: chenyuchih on July 18, 2020, 03:23:00 am
Nice, and thanks for your development/maintenance.

I require math library often, especially in regression, matrix operation and digital signal analysis. About ten years ago I tried ALGLIB, another powerful math library, but the license made me give up and now they even don't provide pascal/delphi source anymore. I did write some functions for my need. Those functions just work correctly but lack of optimization badly, the speed performance is so-so. Maybe LMath is the lamp that could light up my way.

BTW, I am curious about the calculation of fourier transform. Is there any plan to implement the DFT, which doesn't constrain sample number to power of 2, with some high efficieny algorithms such as Cooley-Tukey?

Best Regards,
ChenYuChih
Title: Re: LMath new version (LMath and Components 0.5)
Post by: glorfin on July 18, 2020, 04:53:47 am
Thank you for the interest! I hope, the library will be useful. Look at lmLineAlgebra, lmRegression and maybe lmSpecRegress.
Quote
Is there any plan to implement the DFT...
Well, not in the near future, though I'll mean your request. However, my main interest is electrophysiology, and I work usually in time domain. So, rather one-two new filters can be expected than Fourier transform.

But if somebody would like to implement them, I will gladly include them into the library.
And, speaking about future development, large part of the algorithms for the library was translated from Fortran. Different schema of matrix storage in Pascal (rows first) makes these algorithms fairy slow. One thing which probably should be done, is optimization of them for Pascal. Again, if anybody has interest.
Title: Re: LMath new version (LMath and Components 0.5)
Post by: avra on July 19, 2020, 11:02:45 pm
Thank you!

I am mostly interested in linear programming, curve fitting, polynomials, path finding and fft/ifft.
Title: Re: LMath new version (LMath and Components 0.5)
Post by: VTwin on July 20, 2020, 07:45:10 pm
Many thanks! I have been using dmath for many years, and have recently switched to lmath. I use linear equation solving, eigenvectors, curve fitting, function minimization, some statistics and fourier.

At this point I have written my own library of vector and matrix routines with operator overloading, but they are specific to my needs and may not be optimized. I am therefore very pleased to see that lmath is being developing as a general purpose, and well organized, math library. 

Would be possible to add one package that includes all of lmath? I have, for example, one program that uses 8 of the lmath packages, one that uses 9, and a third that uses 10, all of which I maintain on 3 platforms.

Thanks again.

Title: Re: LMath new version (LMath and Components 0.5)
Post by: glorfin on July 21, 2020, 07:37:54 pm
Thank you!

As for optimization, it is not a strong side of DMath/LMath either. In fact, it is quite slow. In part because many algorithms were transtaled from Fortran and are optimized for "columns first" arrays, in part because clarity was preferred over optimization.
Title: Re: LMath new version (LMath and Components 0.5)
Post by: glorfin on August 14, 2020, 01:51:03 am
Would be possible to add one package that includes all of lmath?

Added LMath-lpk to Trunk. Now it is possible to import LMath.lpk instead of every small package.

In addition, I committed there two missing units from llmMathUtils (thank to bug report from Avra) and corrected a minor error in  uGauss (lmSpecregress).
Title: Re: LMath new version (LMath and Components 0.5)
Post by: avra on August 14, 2020, 08:10:21 am
Would be possible to add one package that includes all of lmath?

Added LMath-lpk to Trunk. Now it is possible to import LMath.lpk instead of every small package.

In addition, I committed there two missing units from llmMathUtils (thank to bug report from Avra) and corrected a minor error in  uGauss (lmSpecregress).
Very nice. Thank you! 
Title: Re: LMath new version (LMath and Components 0.5)
Post by: Alextp on August 14, 2020, 08:11:27 am
I added a wiki page!
https://wiki.freepascal.org/LMath
Title: Re: LMath new version (LMath and Components 0.5)
Post by: glorfin on August 14, 2020, 09:24:12 am
I added a wiki page!
https://wiki.freepascal.org/LMath
Oh, many thanks! I schould have done myself, but was too lazy.

Title: Re: LMath new version (LMath and Components 0.5)
Post by: avra on August 14, 2020, 09:47:16 am
I see that as in dmath, in lmath we also have simple 'u' prefix for many units. I do not think that is enough any more. I have IDE duplicate file conflicts with utypes and usimplex units because I also have these exact named units in code that I use. I will rename my units as a quick fix, but there is a problem if any of the units of all other Lazarus authors contain units with the same names. Since naming was pretty generic, probability for that is quite high. There is also a problem with dmath package having the same named units. Right now, if both lmath and dmath are installed in IDE, which utypes.pas will be used when you use one or the other package? To avoid such confusion, and to let old projects work with dmath without having to uninstall lmath, we will need to differentiate lmath units from dmath. I guess that dotted namespacing for all units could be a solution. Something simple as 'lm' in lm.types.pas, or even finer gradation if needed like lm.integrals.gausleg.pas, lm.integrals.trap.pas, lm.regression.fft.pas lm.regression.spline.pas.

https://www.freepascal.org/docs-html/ref/refse112.html

Just my 2 cents.
Title: Re: LMath new version (LMath and Components 0.5)
Post by: wp on August 14, 2020, 10:06:31 am
if both lmath and dmath are installed in IDE
Is "installation" needed at all? Do these packages contain designtime code? I don't think so. In the package options mark them as "runtime" so that they cannot be installed.

Also make sure that, if you work with Lazarus trunk, the option "Maximize compatibility of package file" in the package options is set -- otherwise the package is not readable by Laz 2.0.10 and older.

What is the difference between lmath.lpk and lmath_all.lpk?
Title: Re: LMath new version (LMath and Components 0.5)
Post by: Zoran on August 14, 2020, 10:25:00 am
Is "installation" needed at all?

Actually, according to first note in Changes from DMath (https://wiki.freepascal.org/LMath#Changes_from_DMath):
Quote
Naming of packages and units made more systematic. Now names of all units begin from u (for example, uTypes)
the unit names are changed from those in DMath.

Anyway, "utypes" and similar names are too probable to be used in some other package, Avra is probably not the only one who has it in his projects.

So, it would really be better to prefix unit names with "LMath".
Title: Re: LMath new version (LMath and Components 0.5)
Post by: avra on August 14, 2020, 10:35:08 am
if both lmath and dmath are installed in IDE
Is "installation" needed at all?
I install no-design-time packages simply to let IDE know where to look for it's units. That is a nice Lazarus improvement over Delphi search path editor. The problem is when I install package A having unit abc in one dir, and then install package B having unit abc with the same name but different content. IDE will not like it, and probably report famous PPU problem. There is also a slim, but existing chance that my project will need both packages A and B, so which abc will be referred? That's why I advocate for unique unit names. At one moment I was even thinking of creating a tool that will scan all fpc, lazarus, and installed components directories and report duplicate names so component authors could be alerted, but did not catch time yet.

What is the difference between lmath.lpk and lmath_all.lpk?
I could not find lmath_all.lpk in trunk.
Title: Re: LMath new version (LMath and Components 0.5)
Post by: avra on August 14, 2020, 10:41:18 am
according to first note in Changes from DMath (https://wiki.freepascal.org/LMath#Changes_from_DMath):
Quote
Naming of packages and units made more systematic. Now names of all units begin from u (for example, uTypes)
the unit names are changed from those in DMath.
I have just checked and usimplex, uround, unlfit, utypes and many, many other units are in both dmath and lmath. Actually, 118 units out of 122 files in OPM's dmath directory have 'u' prefix.
Title: Re: LMath new version (LMath and Components 0.5)
Post by: Alextp on August 14, 2020, 10:50:47 am
>So, it would really be better to prefix unit names with "LMath".

I support it.
Title: Re: LMath new version (LMath and Components 0.5)
Post by: wp on August 14, 2020, 11:03:48 am
I install no-design-time packages simply to let IDE know where to look for it's units.
You don't have to. I simply compile the package, I think it's even enough to just open the lpk file in the package editor. Then the unit path is known to the IDE and you can add the runtime package to the requirements of your project. FPSpreadsheet works exactly this way.

Working with runtime packages helps to keep the IDE slimmer. And it avoids the naming conflicts. But of course, I think too that a "u" prefix is not specific to identifiy the LMath units. I'd prefer an "lm" prefix for all LMath files (I hate dotted unit names...), the package should be renamed with a Pkg suffix, like lmGenMathPkg.lpk. And since these are breaking changes you should also take the opportunity to replace these ugly names: ULineAlgebra --> ULinearAlgebra or ULinAlgebra, UPolinoms --> UPolynomials. Moreover I see that the LMath directories are labeled with inconsistent casing: in some of them, the "u" is uppercase, in others it is lowercase -- this is a pain in case-sensitive OSs. CamelCase is fine with me, but please be consistent.

I could not find lmath_all.lpk in trunk.
Sorry, my fault - I had created this package by myself some time ago when I did my first tests with lmath.
Title: Re: LMath new version (LMath and Components 0.5)
Post by: avra on August 14, 2020, 11:18:58 am
I install no-design-time packages simply to let IDE know where to look for it's units.
You don't have to. I simply compile the package...
My bad. I used wrong wording for my actions. I also just compile and listen to IDE when it tells me not to make it fat without need.

Working with runtime packages helps to keep the IDE slimmer. And it avoids the naming conflicts.
The worse example was synapse in early days of OPM. We had synapse trunk, synapse official, and pl_synapse. All had the same named units, so when you had one project using one package, and the other project used another - you had quite a mess. That's what I try to avoid by differentiating enough lmath from dmath.

LMath directories are labeled with inconsistent casing: in some of them, the "u" is uppercase, in others it is lowercase -- this is a pain in case-sensitive OSs.
Using lower casing for all files and directories makes cross platform life of a package much easier and avoids lots of problems...
Title: Re: LMath new version (LMath and Components 0.5)
Post by: glorfin on August 14, 2020, 11:23:19 am
Actually, I kept names of all units inherited from DMath to maintain compatibility with DMath. "More systematic naming" in the documentation reflected change from LMath 0.4 where packages also were named uSomething to LMath 0.5 where packages became lmSomething.

So we have a question: what is better - maintain compatibility so that a project which previously used DMath can be easily switched to LMath, or make these libraries completely independent and give new names to all units.

In the latter case, I would probably also make units bigger. Jean Debord wrote a separate unit almost for every function, but now, with smart linking, it is probably not necessary and one could place related stuff in one unit to reduce uses clauses of calling programs.

To collect opinions, I created a poll in freepascal group in reddit:
https://www.reddit.com/r/freepascal/comments/i9isfp/unit_and_package_naming_in_lmath_library/

Title: Re: LMath new version (LMath and Components 0.5)
Post by: TRon on August 14, 2020, 11:31:01 am
Actually, I kept names of all units inherited from DMath to maintain compatibility with DMath.
..
To collect opinions, ...
If the above reason is the goal then that would be a no-brainer.

Nobody in his right mind would use both at exactly the same time, and besides that, it is already possible to do so.
Title: Re: LMath new version (LMath and Components 0.5)
Post by: glorfin on August 14, 2020, 11:33:18 am
Nobody in his right mind would use both at exactly the same time.

But one can switch from DMath to LMath, and this is easier if unit names are the same.
Title: Re: LMath new version (LMath and Components 0.5)
Post by: TRon on August 14, 2020, 11:41:19 am
But one can switch from DMath to LMath, and this is easier if unit names are the same.
That is exactly my point. If that is your goal then you should not rename the units.
Title: Re: LMath new version (LMath and Components 0.5)
Post by: wp on August 14, 2020, 11:58:08 am
Why should I switch to the dead DMath in the same project once that I have decided to use the maintained LMath?

To collect opinions, I created a poll in freepascal group in reddit:
https://www.reddit.com/r/freepascal/comments/i9isfp/unit_and_package_naming_in_lmath_library/
You can create polls also here (I never created one, so I don't know why). I will not register at yet another internet site just to repeat my opinon.
Title: Re: LMath new version (LMath and Components 0.5)
Post by: glorfin on August 14, 2020, 12:12:00 pm
I mentioned switching from DMath to LMath, which is also easier if backwards compatibility is maintained.
(Possible reason to switch from LMath back to DMath also can exist. For example, one can find that LMath introduces too many bugs  O:-) )

And thank you, I did not notice that one can create polls here.
Title: Re: LMath new version (LMath and Components 0.5)
Post by: TRon on August 14, 2020, 12:26:57 pm
I mentioned switching from DMath to LMath, which is also easier if backwards compatibility is maintained.
Seems I do not speak English clear enough :)

Let me try again: The suggestion in your poll to rename the units BREAKS that compatibility (*)

Last time I checked the construct alias was not available and there was no indication to add support for it nor does there seem any indication to add support for "proper" namespacing. The dotted unit-names are just a filename related implementation.

(*) which is of course perfectly fine if you wish to do so, but at the same time you are still claiming/wanting back/for -wards compatibility.
Title: Re: LMath new version (LMath and Components 0.5)
Post by: glorfin on August 14, 2020, 12:52:18 pm
TRon, I understand you, and agree with you. I am not inclined to rename units and break compatibility. Option 1 on the poll is exactly this one: keep names as they are. However, I am open to suggestions and want to collect opinions of other potential users.
Title: Re: LMath new version (LMath and Components 0.5)
Post by: TRon on August 14, 2020, 01:06:49 pm
With regards to your last remark that is of course your given right as you are the maker/maintainer/developer.

The only reason I react strongly, is that I get the hunch that you started to have this opinion and put up the poll because of reasons provided by others.

Not only that, I believe the provided reasons are invalid for your project and should not concern you at all. There is a far more fundamental issue at hand there that should be addressed instead of bothering you with it.

Of course all imho.
Title: Re: LMath new version (LMath and Components 0.5)
Post by: Alextp on August 14, 2020, 02:44:43 pm
>Name units lmSomething and packages lmpkgSomething to make names unique

Need new choices:
Name units lmath.Something and (anything)
Name units lmath_Something and (anything)
Title: Re: LMath new version (LMath and Components 0.5)
Post by: TRon on August 14, 2020, 03:38:24 pm
>Name units lmSomething and packages lmpkgSomething to make names unique

Need new choices:
Name units lmath.Something and (anything)
Name units lmath_Something and (anything)
There virtually is no choice there. The new 'namespace' addition (unit scope actually) allows for your former suggestion to (still) compile as is (provided you use the same unitnames after the dotpart that matches the original project. In case  compatibility is still wanted/required) but the latter will definitely break compatibility, see Marcov's answer here https://forum.lazarus.freepascal.org/index.php/topic,48164.msg346469.html#msg346469

However, in my opinion (as I understood the documentation) it has a flaw. You still have issues when defining two units scopes _and_ which uses the same unit names in the same project. A far better solution would imo be to have unit aliasing or package-named scopes as that shifts the burden from package/unit developer to end-user/main engine.

I find it difficult to grasp that all seem to stand or fail depending on how many packages you have installed/are in use by a project.
Title: Re: LMath new version (LMath and Components 0.5)
Post by: Alextp on August 14, 2020, 03:56:11 pm
So I suggest the "lmath_Somthing", it breaks compatibility but for this new LMath project it's not a big problem. Apps are new.
Title: Re: LMath new version (LMath and Components 0.5)
Post by: TRon on August 14, 2020, 04:15:18 pm
So I suggest the "lmath_Somthing", it breaks compatibility but for this new LMath project it's not a big problem. Apps are new.
Are you talking about the package name or the unit names ?

In case the latter, then I really do not understand why you people are taunting the developer of this package with suggesting breakable changes while he prefers to stay as compatible as possible.

If some units from his package conflicts with that of some other packages, then so be it. That is your problem as an end-user. Why keep bothering LMath developer with that is beyond me

What do you have in mind ? first come, first rights when it comes to naming units ?   >:D Even for those that would never install such a (conflicting) package ?  :'( Dot-prefixing by default does not solve it (as written earlier) but at least allows for compatibility. Underscoring would for sure break compatibility.

Have you ever considered that fpc/laz developers themselves could be adding packages that uses unit-names that then could break your suggested solution (for a moment focus on a broader area, not only this particular package) ? A said, it is a more fundamental issue that requires attention instead of suggesting workarounds that are not maintainable.
Title: Re: LMath new version (LMath and Components 0.5)
Post by: avra on August 14, 2020, 11:24:06 pm
If some units from his package conflicts with that of some other packages, then so be it. That is your problem as an end-user. Why keep bothering LMath developer with that is beyond me
Try to install both dmath and lmath and you will see how your IDE reacts to having duplicated units with different content. The same as when we used to have 3 Synapse packages. If you have serious projects in dmath and want to experiment with lmath then you need both. If you didn't use dmath earlier in your projects then it is clear why my itch is not yours, too.

What you call 'bothering developer' is a normal discussion in a public forum and that has been like that at least since Roman times. We discuss topics or project we care for. He who does the work has the most power and there is no democracy in such projects, so he accepts only ideas and/or patches that do not conflict with his vision. Who does not like it is free to make a fork to follow his own vision.

Dot-prefixing by default does not solve it (as written earlier) but at least allows for compatibility. Underscoring would for sure break compatibility.
This is constructive contribution to discussion. Facts are more valued then emotions.
Title: Re: LMath new version (LMath and Components 0.5)
Post by: marcov on August 14, 2020, 11:30:32 pm
(4) use namespaces/dotted unit names, they are functional in 3.2.0?
Title: Re: LMath new version (LMath and Components 0.5)
Post by: wp on August 14, 2020, 11:53:22 pm
Try to install both dmath and lmath and you will see how your IDE reacts to having duplicated units with different content. 
Avra, again: Do not install these packages, only compile them. Then there will be not naming conflict as long as you do not use both packages in the same project (which does not make any sense at all).

I just checked it: I downloaded DMath via OPM and compiled the DMath package. Then I compiled the LMath packages (which I have on svn) and compiled one of the LMath demos. No problem at all. The IDE does know the path to these packages but loads only the one which is required by the project.
Title: Re: LMath new version (LMath and Components 0.5)
Post by: avra on August 15, 2020, 12:20:10 am
Try to install both dmath and lmath and you will see how your IDE reacts to having duplicated units with different content. 
Avra, again: Do not install these packages, only compile them.
My bad, again.
Title: Re: LMath new version (LMath and Components 0.5)
Post by: TRon on August 15, 2020, 03:07:41 am
(4) use namespaces/dotted unit names, they are functional in 3.2.0?
They are (https://wiki.freepascal.org/FPC_New_Features_3.2.0#Support_for_Default_Namespaces) . I even got that hint from you when you posted that message I referred to  :)

But I do believe something else is dragged in at the same time as well, e.g. what to do when using multiple packages in a single project uses conflicting unit-names.

And as far as I understand it, that is still a problem.

Not with regards to DMath and LMath used at the same time, as that would make no sense, but in those cases that someone, somewhere would ever release a package that uses unit-names that someone else, somewhere else has released, and you happen to want to use both those packages inside your project at the same time.

afaik, there is currently no (easy) solution for that atm.
Title: Re: LMath new version (LMath and Components 0.5)
Post by: marcov on August 15, 2020, 10:39:22 am
But I do believe something else is dragged in at the same time as well, e.g. what to do when using multiple packages in a single project uses conflicting unit-names.

The thing with dotted unit names is that if you give them both such prefixes, projects with both packages use them as is, with prefix.  Users of just one, can choose to use them, or use the default namespace parameter to trim them off.
Title: Re: LMath new version (LMath and Components 0.5)
Post by: TRon on August 15, 2020, 04:31:17 pm
The thing with dotted unit names is that if you give them both such prefixes, projects with both packages use them as is, with prefix.  Users of just one, can choose to use them, or use the default namespace parameter to trim them off.
The issue with that afaik is that you (as end-user) can also choose to use multiple name-space parameters so that they get  'stripped' for both packages.

But that isn't even the main problem. The end-user has no control over how someone distributes his/her package, so such package can also be released without the use of dotted unit names. So, as a hypothetical example, say package1 comes delivered with unit utypes, and package2 does as well. The project the end-user is working on requires the use of both packages and thus requires the use of both utypes units.

afaik there currently is no provision or intention to make one to be able to solve such conflict (other then renaming the units manually yourself, or provide/create a "front-end" unit for that). That you are able to specifically select either one by using the in construct is nice but seems clumsy to me as it requires the knowledge of the (installation) location for that package.

I am not saying it should act like Delphi, but there you was (still are?) able to use unit aliasing in order to solve such issues.
Title: Re: LMath new version (LMath and Components 0.5)
Post by: marcov on August 15, 2020, 05:12:41 pm
The thing with dotted unit names is that if you give them both such prefixes, projects with both packages use them as is, with prefix.  Users of just one, can choose to use them, or use the default namespace parameter to trim them off.
The issue with that afaik is that you (as end-user) can also choose to use multiple name-space parameters so that they get  'stripped' for both packages.

Sure, but that is a third order magnitude issue. You can always pick some "weakness", but the risk of accidentally entering two specific default parameters is a small price to pay to being able to switching existing code between packages without ifdeffing or source modification, yet still use it in one project.

Quote
But that isn't even the main problem. The end-user has no control over how someone distributes his/her package, so such package can also be released without the use of dotted unit names. So, as a hypothetical example, say package1 comes delivered with unit utypes, and package2 does as well. The project the end-user is working on requires the use of both packages and thus requires the use of both utypes units.

I was more thinking about lazarus' "Online Package Manager" kind scenarios, where maintainers allow this and write the actual lpks.

Quote
afaik there currently is no provision or intention to make one to be able to solve such conflict (other then renaming the units manually yourself, or provide/create a "front-end" unit for that). That you are able to specifically select either one by using the in construct is nice but seems clumsy to me as it requires the knowledge of the (installation) location for that package.

There is no solution for that indeed, since it basically assumes "anything can happen", and package maintainers not regarding any rules.

Quote
I am not saying it should act like Delphi, but there you was (still are?) able to use unit aliasing in order to solve such issues.

That never worked well for me in the first place. Maybe because I use a lot of relative paths in my unit path, something that has been broken in Delphi (at least since BDS versions, maybe even before. Paths are relative to the IDE working directory, not to the project .dpr/dproj)
Title: Re: LMath new version (LMath and Components 0.5)
Post by: TRon on August 15, 2020, 06:39:51 pm
Sure, but that is a third order magnitude issue. You can always pick some "weakness", but the risk of accidentally entering two specific default parameters is a small price to pay to being able to switching existing code between packages without ifdeffing or source modification, yet still use it in one project.
Fair enough.

Please do note however that it is and was not my intention to focus on a particular weakness. It is simply something I observed, and took note off. Completely/totally ignoring it is just the another side of the spectrum  ;)

Quote
I was more thinking about lazarus' "Online Package Manager" kind scenarios, where maintainers allow this and write the actual lpks.
I am/was approaching it at a broader level. This is also an issue for fpc's package manager (which afaik OPM uses as mechanism as well).

Of course, in case you are in control then you can 'fix' some of the issues. What about those packages not being maintained (by OPM) ? There I have commercial packages in mind, for instance.

Quote
Quote
afaik there currently is no provision or intention to make one to be able to solve such conflict (other then renaming the units manually yourself, or provide/create a "front-end" unit for that). That you are able to specifically select either one by using the in construct is nice but seems clumsy to me as it requires the knowledge of the (installation) location for that package.
There is no solution for that indeed, since it basically assumes "anything can happen", and package maintainers not regarding any rules.
You could of course argue that commercial entities should not be using general used unit names, and should always be using dotted ones but is that being advertised in an official manner or are there instructions ?

As already mentioned by yourself, even the FCL itself seem to run into this issue.

Not to mention that whenever the fcl get's extended (either by using dotted names or not) that it could happen that the chosen prefix (or lack thereof) clashes with an already existing package that has been there for years (just a random example, please also see that it in a broader view e.g. lazarus packages etc)

Since everyone seems to be putting up their own package of what they believe is the right way to implement/solve certain topics there is a higher chance of such "name clashing" related issues.

Quote
Quote
I am not saying it should act like Delphi, but there you was (still are?) able to use unit aliasing in order to solve such issues.

That never worked well for me in the first place. Maybe because I use a lot of relative paths in my unit path, something that has been broken in Delphi (at least since BDS versions, maybe even before. Paths are relative to the IDE working directory, not to the project .dpr/dproj)
Yeah, I am not really fond of it either.

I understand this topic has probably been discussed a zillion of times before but my question is more if it could be solved. Should it be solved ? And in case it does, could it then be solved in such a way that it actually makes sense ?

For instance I was more thinking along the line of a "namespace" for an individual package, that could be changed at will. It does not imply an approach as used by .dot languages, rather a more direct one that allows the user to "select" a particular package by using it's namespace, preferably by allowing aliasing for them as well in case portability / compatibility is required.

Whatever the case, I thank you for the ack and feedback marcov.
Title: Re: LMath new version (LMath and Components 0.5)
Post by: marcov on August 15, 2020, 11:55:55 pm
Quote
I was more thinking about lazarus' "Online Package Manager" kind scenarios, where maintainers allow this and write the actual lpks.
I am/was approaching it at a broader level. This is also an issue for fpc's package manager (which afaik OPM uses as mechanism as well).

Of course, in case you are in control then you can 'fix' some of the issues. What about those packages not being maintained (by OPM) ? There I have commercial packages in mind, for instance.

In the end, some side gives and renames. Very old and established commercial packages might force OPM managers to think twice. New commercial packages face an avoidable support problem if OPM persists because of backwards compatibility, forcing them to think twice.

Quote
Quote
There is no solution for that indeed, since it basically assumes "anything can happen", and package maintainers not regarding any rules.
You could of course argue that commercial entities should not be using general used unit names, and should always be using dotted ones but is that being advertised in an official manner or are there instructions ?

I didn't mean to suggest everything should use dotted. I suggested this for a case where there are two forks of the same package (dmath/lmath) with resulting unit clashes.

Quote
As already mentioned by yourself, even the FCL itself seem to run into this issue.

Release versions are compiled -Ur which avoids searching for source for FPC units.

But there are more such cases, e.g. both lazarus and FPC's FV unit have a "dialogs" unit.   There have been other clashes too, iirc between FV and Mac OS X specific units.

FV features hopelessly general names like drivers/editors/dialogs/time/resource/gadgets/validate/views/app.   Unfortunately it is mostly used by the most helpless of users, in the most helpless of IDEs (textmode IDE).

Quote
Not to mention that whenever the fcl get's extended (either by using dotted names or not) that it could happen that the chosen prefix (or lack thereof) clashes with an already existing package that has been there for years (just a random example, please also see that it in a broader view e.g. lazarus packages etc)

Since everyone seems to be putting up their own package of what they believe is the right way to implement/solve certain topics there is a higher chance of such "name clashing" related issues.

Well, they are still quite rare, and most resolve themselves on first realization of the conflict. And that is still the most preferable scenario, since that doesn't need continous configuration management by the user.

Quote
I understand this topic has probably been discussed a zillion of times before but my question is more if it could be solved. Should it be solved ? And in case it does, could it then be solved in such a way that it actually makes sense ?

I don't believe in a solution to end all solutions, if only because that leads to hard to maintain configuration. It only benefits the kind of people that can also workaround it other ways.

 Maybe some minor guidelines to decrease the likeliness. In time OPM also helps, since if it contains the bulk of Lazarus shared source, testing if an unitname is occupied is easier

Quote
For instance I was more thinking along the line of a "namespace" for an individual package, that could be changed at will. It does not imply an approach as used by .dot languages, rather a more direct one that allows the user to "select" a particular package by using it's namespace, preferably by allowing aliasing for them as well in case portability / compatibility is required.

If you want to make a proposal, be warned that it is not simple because the compiler rarely has an overall overview. It only searches units it needs, and programs may be compiled in multiple steps with varying parameters. (paths, default namespaces). A good understanding of how the unit system works (as in the order of processing, not the syntax) is paramount.

Pascal is halfway between C/C++ (which needs oodles of external build tools, and even then most source only meets at the linker), and Java/.NET with their carefully collections of class hierarchies, each mapped on a directory structure. (though to be honest, I don't know the real nitty, gritty rules for compilation in Java/.NET either, but I assume it is more likely to get access to all program parts at once )

Quote
Whatever the case, I thank you for the ack and feedback marcov.

No problem. The unit system always fascinated me as it is quite elegant and major component of Pascal. Some nice parts of it haven't been backported from Modula2. Maybe one day....
Title: Re: LMath new version (LMath and Components 0.5)
Post by: furious programming on August 16, 2020, 03:45:40 am
Why not LMath.Something for units? Namespaces are supported and they are very useful (at least for me).

LMath as a package name seems to look good enough.
Title: Re: LMath new version (LMath and Components 0.5)
Post by: Zoran on August 16, 2020, 02:32:57 pm
Why not LMath.Something for units? Namespaces are supported and they are very useful (at least for me).

LMath as a package name seems to look good enough.

After reading everything in this topic, this really seems to be the best option.

That would keep a fair level of compatibility (old programs just need to add -FN LMath to compile).
Still, projects which possibly have some same named units (or depend on some package which have same named units) will be able to use LMath, just have to fully qualify LMath units when adding them to uses section.
Title: Re: LMath new version (LMath and Components 0.5)
Post by: VTwin on August 17, 2020, 12:45:28 am
Thanks for bring this up for discussion.

I am still learning the details of packages, but it seems to be possible to include files from multiple directories. It therefore seems that one package such as:

lmathpkg.pkg
lmath.pkg

could be used for all units currently in the LMath directory (except of course demo, and probably lmPlotter). I would love this because I currently use about 8 LMath packages in 3 projects across 3 platforms.

I support the conversion to "lmsomething.pas" for units, using lower case.



Title: Re: LMath new version (LMath and Components 0.5)
Post by: wp on August 17, 2020, 01:05:10 am
You must be aware that every unit cannot exist in multiple packages. glorfin provided a "summary" package lmath.lpk which requires all the other packages. Therefor you only must add lmath.lpk to the requirements of your projects to have access to all LMath units.
Title: Re: LMath new version (LMath and Components 0.5)
Post by: VTwin on August 17, 2020, 01:26:51 am
You must be aware that every unit cannot exist in multiple packages. glorfin provided a "summary" package lmath.lpk which requires all the other packages. Therefor you only must add lmath.lpk to the requirements of your projects to have access to all LMath units.

Yes, I did discover that while practicing my package skills.

That is great, it may have been due to a request I made. However, I do not see "lmath.lpk" in "lmath_and_components_0_5". What am I missing?

EDIT: Never mind, I found it in r100. Thanks glorfin!
Title: Re: LMath new version (LMath and Components 0.5)
Post by: VTwin on August 20, 2020, 04:56:31 pm
glorfin,

Here is the decreasing exponential fit function I messaged you about. It is a very minor modification of uiexpfit. I needed it to fit some natural time series that show exponential decay.

Feel free to use it in lmath, or not, as you see fit.

Regards,
VTwin

Title: Re: LMath new version (LMath and Components 0.5)
Post by: glorfin on August 20, 2020, 10:03:11 pm
Thank you!
I will look at udecexpfit in the nearest future.

Meanwhile, as a result of discussion above, I think I will change unit names to lmath.usomeunit. Reasons are that ames like uTypes or, to that end, uComplex are indeed very general and potentially leading to conflicts.

If one uses LMath only, installation is not needed, but LMComponents are design time packages and must be installed. Consequently, they require installation of many LMath units, which may aggravate potential conflicts.
From the other hand, mechanism of name spaces allows to minimize compatibility issues.
Title: Re: LMath new version (LMath and Components 0.5)
Post by: Kwadrum on August 25, 2020, 05:26:56 pm
Hi,
May I ask about the choice of TVector type used in some (or maybe many) functions of LMath? What are the advantages compared to other more "traditional" arrays/lists/etc? I made some reading on TVector and the only obvious difference seems to be that it can automatically increase its size (which probably makes it quite slow).
I am not trying to challenge this choice, just really unfamiliar with this type and no, I am not a Pascal expert.
Thank you!
Title: Re: LMath new version (LMath and Components 0.5)
Post by: glorfin on August 25, 2020, 07:15:52 pm
May I ask about the choice of TVector type used in some (or maybe many) functions of LMath?
Hi!
TVector is simply dynamic array of Float, and Float by default is double, but depending on compilation key may be single or extended.
In types.pas:
Code: Pascal  [Select][+][-]
  1. type
  2.   {$IFDEF SINGLEREAL}
  3.   Float = Single;
  4. {$ELSE}
  5. {$IFDEF EXTENDEDREAL}
  6.   Float = Extended;
  7. {$ELSE}
  8.   {$DEFINE DOUBLEREAL}
  9.   Float = Double;
  10. {$ENDIF}
  11. {$ENDIF}
  12. ........
  13.   TVector = array of Float;
  14.  
Technically it is a pointer to an array allocated in a heap.
In most cases it must be as efficient, as a usual array.
Title: Re: LMath new version (LMath and Components 0.5)
Post by: Kwadrum on August 25, 2020, 09:57:36 pm
Thanks for reply!
Does it mean that the same array may be addressed as an array of single or double during run time (depending on the conditions)? If yes, wouldn't conversion between single/double be too time-consuming?
Title: Re: LMath new version (LMath and Components 0.5)
Post by: glorfin on August 26, 2020, 01:07:22 pm
Does it mean that the same array may be addressed as an array of single or double during run time (depending on the conditions)?
No! What is Float is defined when you compile unit uTypes. Look at the code which I have provided: {$IFDEF ...} is a switch for conditional compilation.

So, if you open package lmGenMath, select Options, Custom Options, and write there -dSINGLEREAL, type Float will be equivalent to Single; all TVector will be array of Single.
-dDOUBLEREAL makes Float = double; all TVector are arrays of Double too. This is default option.
-dEXTENDEDREAL makes Float = EXTENDED. (However, see discussions about Extended in Windows 64 bits somewhere in this forum).

So, all these switches are compilation time, not runtime, switches.
Title: Re: LMath new version (LMath and Components 0.5)
Post by: jcbritobr on September 09, 2020, 01:28:00 am
Nice library. Always use it for machine learning and linear regression stuffs.
TinyPortal © 2005-2018