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.
Would be possible to add one package that includes all of lmath?
Very nice. Thank you!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).
I added a wiki page!Oh, many thanks! I schould have done myself, but was too lazy.
https://wiki.freepascal.org/LMath
if both lmath and dmath are installed in IDEIs "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.
Is "installation" needed at all?
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 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.if both lmath and dmath are installed in IDEIs "installation" needed at all?
What is the difference between lmath.lpk and lmath_all.lpk?I could not find lmath_all.lpk in trunk.
according to first note in Changes from DMath (https://wiki.freepascal.org/LMath#Changes_from_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.QuoteNaming 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 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.
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.
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.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...
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...
Actually, I kept names of all units inherited from DMath to maintain compatibility with DMath.If the above reason is the goal then that would be a no-brainer.
..
To collect opinions, ...
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.That is exactly my point. If that is your goal then you should not rename the units.
To collect opinions, I created a poll in freepascal group in reddit: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.
https://www.reddit.com/r/freepascal/comments/i9isfp/unit_and_package_naming_in_lmath_library/
I mentioned switching from DMath to LMath, which is also easier if backwards compatibility is maintained.Seems I do not speak English clear enough :)
>Name units lmSomething and packages lmpkgSomething to make names uniqueThere 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
Need new choices:
Name units lmath.Something and (anything)
Name units lmath_Something and (anything)
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 ?
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 meTry 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.
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.
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).
My bad, again.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.
(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.
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.
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.
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.
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).
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 ?Quoteafaik 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.
Yeah, I am not really fond of it either.QuoteI 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)
QuoteI 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.
QuoteThere 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.
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.
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.
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.
May I ask about the choice of TVector type used in some (or maybe many) functions of LMath?Hi!
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.