oldefoxx wrote:and I am back to BASIC again, this time with PureBasic after some time with HotBasic
No, you are not back to Basic, you are frozen at assembler.
oldefoxx wrote:Would it be easier to create such patterns with something like PureBasic, or would it work out that assembler would help?
Its very easy to create such patterns with simple PB commands. But, if you want to search in strings very fast and in a professional style, you will not first change into patterns like in your example, you will use regular expressions (supported by pure basic).
Regular expressions are very fast and efficient in PB, that's true (if you know how to use them of course, it's not so easy).
There is no reason why oldefoxx shouldn't create his own function using Assembler if that is his preference - after all, one of PB's greatest strengths is that flexibility, it's got a lot of 'strength in depth' and you can use it the way you wish.
I'm writing apps for a living, so I tend to take the 'horses for courses' route - get the job done, optimize only where necessary, stick to Procedural methods in PB. It's possible to code a solid, reliable app very quickly in PB, far quicker than in C/C++, which I'm forced to use for most of my customers -via the APIs of the larger apps for which I write add-ons. Writing and compiling DLLs in C can be a frustrating experience - I prefer to use PB whenever I can.
IdeasVacuum
If it sounds simple, you have not grasped the complexity.
Okay, let's say you process a number of documents, none in a standard format, and you read the entire contents into one or more
strings. You want to file these docuements for later reference, and the six things needed to index them involve
1. Who it is from
2. Who it is to
3. The date it was written
4. The subject, if it can be located
5. What reference it makes use of
6. Whatever is Appended to it
The user doesn't see these documents beforehand. They come in electronically and get indexed and filed. And they are in sufficient
quantity that huge drives are required to keep them once filed. You figure out how to possibly locate each of the above, realizing
that the date alone represents any of 366 combinations of letters and digits or digits alone, and that is not counting the year, which
can be two or four digits long. You either have a good index to pursue, or you end up having to search all those drives byte by byte
for exact matches.
Now me, I see my best shot is coming up with a way to pattern the contents of those documents and trying to isolate things like
date, reference strings. address blocks that give the from and to information, and possibly the name of the signee at the bottom.
It's either that or try and teach the computer how to read and discern the contents of whatever that document has in it. Now
patterns don't do everything for you, but they can be a help. At least that is my experience. If you haven't used patterns, then that
is your experience.
I'm not here to rate the importance of doing patterns, I am merely considering the question of whether creating patterns is easier
managed in high level code or low level code. With low level code, if you know what you are doing, you can avoid some of the side
effects of doing it all in high level code. It's sometimes a question of balance. Certainly, with a suitable high level language, all
things should be possible to you, and it is almost always true that your pilot approach will be with high level code. Later, you might
consider the possible merits of working in some low level code in places where it would help. That's always been my approach.
Your hostility to the idea of using assember code is rather unusual. Maybe you can't handle it or something? No insult to you, but I
know that coming to terms with assembler code is awkward and difficult. Every significant change to the CPU, and it effects the
way you work with it using assembler. That's not true of high level languages in general, which can even be adapted to work with
different operating systems.
has-been wanna-be (You may not agree with what I say, but it will make you think).
The high-level solution to that scenario would be to build a relational database. If you also needed file management/security, then the files themselves could be stored within the database, ala some PDM systems.
IdeasVacuum
If it sounds simple, you have not grasped the complexity.
Relational databases track separate pieces of information in different database structures by a common index or thread. That means
you can add more structure by introducing more databases to carry more pieces of information while holding onto the same common
index or thread. Information once so organized is beneficial as you can structure queries that are guided by a database reference to
see how many or who gets matched up to what. Getting the information into the databases to start with can be what is most
demanding.
Security is also a concern, because you need to limit who can enter what into different portions of the databases, who has access to
the contents of the databases, and so on. Using pattern matching is not a part of this, because somewhere behind the scenes you
have a large crew pulling this data together and putting it into the databases so that others can query them and find useful
information.
The general term for covering the activities of the first crew is data mining, and yes, they use computers, software, and internet
access to collect as much data as they can. Without having such a crew at my disposal, I have to consider how far I can push the
envelope on my own. In other words, mine is the individual approach, which is certainly unable to count on the PC and software to
add smartness to the task unless I can somehow program it in myself.
I can't make the computer think, but I can have it render, and then search out anything that looks like it might be something that I
might have a use for. If I know the subject matter involved, I can search out key words or phrases. For instance, If I had all of the
PureBasic forum posts at my disposal, I could search out something like assembler, assembly, asm, and would chance onto this
thread and this post.
On the other hand, if I searched out the word pattern, I would get back a much smaller group of post, but again, this thread and this
post would be in it. Again, no patterns involved. But there are places for patterns, like in identifying dates and phone numbers and
even street addresses that are lines that start with a number, or state references which are usually a comma, space, and two capital
letters, possibly followed by 99999 or 99999-9999. Notice, to find this pattern group, I could just search for ", AA 99999". I can
easily program that, rather than search individually for the 50-odd postal code abbreviations individually. It there were a crew
behind me, I could just leave it to them to pick out the addresses and put them into the database.
has-been wanna-be (You may not agree with what I say, but it will make you think).
