Remove the extension part of a file.

[SFSxOI]

OK, I got a stupid question. Why can't you just rename the file to remove the extension?

Code: Select all

RenameFile("C:\test.txt", "C:\test")

works fine

@SFSxO1: You wouldn't know what to name it to until you had removed the extension.

I believe the thread title was meant to read "Remove the extension part of a filename."

Oki dokee then I was wondering because all I do it just get everything to the left of the '.', strip the '.' away, put it in a variable, and then rename the file to what that variable holds (the PB RenameFile) then i always know what to rename it (everything to the left of the . and excluding the .), comes out with the same name but no extension. But oki dokee then. Now i'm wondering if i've been taking too simple of an approach...oh the headaches, the headaches

[Kaeru Gaman]

All these procedures are too big. Text manipulation such as this is what regular expressions where invented for.

xkcd.com image

Jealous?

nope.
I just luv that comic.

btw: http://store.xkcd.com/xkcd/#RegularExpressionsShirt

[Hroudtwolf]

Explain. I don't understand why you've coded your procedure like that.

Your procedure creates the regex object new on each call.
To use the same object ID initiates the objectmanager to destroy the old object and create a new again and again.
Thats wasting of CPU power.
I know... it is not that much.
But the oftener the procedure will called, the more wasting it is.
Therefore I used in my procedure the static keyword for the object id.
So the procedure is able to recycle the object which was created on the first call for each calls.

Regards
Wolf

[Kale]

Explain. I don't understand why you've coded your procedure like that.

Your procedure creates the regex object new on each call.
To use the same object ID initiates the objectmanager to destroy the old object and create a new again and again.
Thats wasting of CPU power.
I know... it is not that much.
But the oftener the procedure will called, the more wasting it is.
Therefore I used in my procedure the static keyword for the object id.
So the procedure is able to recycle the object which was created on the first call for each calls.
Regards
Wolf

I'm sorry but that is the biggest load of tosh i have ever heard! So there's is NO memory leak then? Of course there isn't! My procedure is fine and yours is overkill and testing too much. Plus mine is not destroying objects, but reallocating a few bytes. This is NOTHING!!! In yours, you are (as a lot on these boards) guilty of premature optimisation, which is a complete and total waste of time and ego.

I really wish people on this board would stop this obsession with saving a few cycles here and there. It's meaningless, and bordering on being totally anal!

Yes, Regex's are pretty horrid and hard to learn but this is what they are for, don't make it more complicated than is necessary (KISS). A few lines are all you need.

I just luv that comic.

Yeah, it's pretty cool!

[luis]

Plus mine is not destroying objects, but reallocating a few bytes. This is NOTHING!!! In yours, you are (as a lot on these boards) guilty of premature optimisation, which is a complete and total waste of time and ego.

Well, I wouldn't be so categoric!

I don't see what's wrong in avoiding to parse the string and to not compile the regular expression every time.
After all I think CreateRegularExpression() does a little more than copy the passed expression and store it away, probably process it and store it in a more convenient form. But I'm guessing.

Anyway using #PB_Any is also good to avoid to call your RemoveExtension() from other code maybe using a regular expression with the same id (0). You could overwrite one with another.

So I don't think it's anal. It's probably more efficient in general and it's certainly safer.

[Hroudtwolf]

@Kale

Amazing .
Keep cool.

Instead, we could have an interessting discussion about it.

[Kale]

@Kale

Amazing .
Keep cool.

Instead, we could have an interessting discussion about it.

Sorry, but c'mon, we're talking a few cycles here, lets be realistic.

...it's certainly safer.

In what way?

[luis]

Sorry, but c'mon, we're talking a few cycles here, lets be realistic.

I'm not saying your routine is slow or bad for the solution of the problem.
If you have to call it only some times in your code the time spent is immaterial in both the implementations. Who cares ?

But you can't say to someone is anal, is overoptimizing etc, only because his code is faster, and with really a small effort. The second implementation is better and faster, it's a fact.

But not only a little faster. It's twice the speed.

Again I don't see nothing wrong in suggest a better code. It's a programmers' forum.

Anyone in his programs can make the most opportune choices later !

Immaterial for 5, even 100 calls ? I agree.

Bad coded ? Anal ? Overoptimized ? Not to me.

Deserving mockery ? I don't think so.

The point where you were right in objecting was the "memory leak" affermation.
The PB manual says a object recreated with the same id free the previous one.

Code: Select all

Procedure.s RemoveExtension_1 (Filename.s)
   CreateRegularExpression(0, "(?<!\A)\.[\w]+\Z")
   ProcedureReturn ReplaceRegularExpression(0, Filename, "")
EndProcedure

Procedure.s RemoveExtension_2 (sFilename.s)
   Static idRegEx.i
   
   ; Object recycling.
   If Not (idRegEx)
      idRegEx = CreateRegularExpression(#PB_Any , "(?<!\A)\.[\w]+\Z")
      If Not (idRegEx)
         ProcedureReturn sFilename
      EndIf
   EndIf
   
   ProcedureReturn ReplaceRegularExpression(idRegEx, sFilename, "")
EndProcedure

#cycles = 1000000

sTest.s = "c:\temp\filename.txt"

iStartTime = ElapsedMilliseconds()
For k = 1 To #cycles
 RemoveExtension_1 (sTest)
Next
iEndTime = ElapsedMilliseconds()


MessageRequester("", Str(iEndTime - iStartTime))


iStartTime = ElapsedMilliseconds()
For k = 1 To #cycles 
 RemoveExtension_2 (sTest)
Next
iEndTime = ElapsedMilliseconds()


MessageRequester("", Str(iEndTime - iStartTime))

...it's certainly safer.

In what way?

I explained in the post above...:

You are using 0 as id for the regexp. Using PB_Any is safer because you don't risk to call your procedure inside some other code using too a regexp potentially with the same id (0).
Doing so the inner CreateRegularExpression() (your proc) would destroy the outer one.

So this way is safer too. This is a lot more important than the talk about the speed to me.

Code: Select all

Procedure.s RemoveExtension_1 (Filename.s)
   CreateRegularExpression(0, "(?<!\A)\.[\w]+\Z")
   ProcedureReturn ReplaceRegularExpression(0, Filename, "")
EndProcedure

Procedure.s RemoveExtension_2 (sFilename.s)
   Static idRegEx.i
   
   ; Object recycling.
   If Not (idRegEx)
      idRegEx = CreateRegularExpression(#PB_Any , "(?<!\A)\.[\w]+\Z")
      If Not (idRegEx)
         ProcedureReturn sFilename
      EndIf
   EndIf
   
   ProcedureReturn ReplaceRegularExpression(idRegEx, sFilename, "")
EndProcedure

#cycles = 10

sTest.s = "c:\temp\filename.txt"

iStartTime = ElapsedMilliseconds()
For k = 1 To #cycles
 CreateRegularExpression(0, "hello")
 
 ; some other code 
 
 ; call the Kale's routine ... was that using a regexp ? I don't remember
 ; certainly I don't go to check every routine to see if it's destroying 
 ; the environment of the caller
 
 ; every routine is closed right ? well tested right ? right !
    
 Debug RemoveExtension_1 (sTest)
 
 ; ok now I will try to see if match 
 
 Debug MatchRegularExpression(0, "hello world")
 
 ; what ? does not!
 
Next

Change RemoveExtension_1 with RemoveExtension_2 and all is ok again.

[Kale]

[luis]

Yes, good, fine. That will do.

The points expressed above are still valid nevertheless.

A good reading about "Premature Optimization" by Randall Hyde (he wrote some great books, and HLA).

http://www.acm.org/ubiquity/views/v7i24_fallacy.html

You can reach your conclusions about what's "anal" and what is writing problematic code from the start.

[logging off]

[Kale]

You are still making invalid excuses. Your test code defines one million iterations, so of course you would optimise in that situation (as an example my entire HDD only has 225k files on it!). Not knowing the problem domain, you would not. Also the link you posted actually enforces my view! And in your test code we are only talking about milliseconds difference! The issue about a global ID being used for the Regex is also moot, because this is a standalone procedure. If you were including it in a larger system, then of course you would account for that. :roll:

[logging on]

[oldBear]

No sense "discussing" with Kale. Didn't you know - he wrote the "book", he's never wrong?

(keep it up - maybe he'll get pissed and leave again)

oB

[luis]

Your test code defines one million iterations, so of course you would optimise in that situation (as an example my entire HDD only has 225k files on it!). Not knowing the problem domain, you would not.

I repeat again :

I'm not saying your routine is slow or bad for the solution of the problem.
If you have to call it only some times in your code the time spent is immaterial in both the implementations. Who cares ?

But you can't say to someone is anal, is over-optimizing etc, only because his code is faster, and with really a small effort. The second implementation is better and faster, it's a fact

Also the link you posted actually enforces my view!

I was 90% sure that would be the effect on you. I posted for other people potentially interested to the subject.

And in your test code we are only talking about milliseconds difference!

We are talking about 100% time penalty. With a single iteration is immaterial and I'm repeating this from the start. Still, the second implementation is simply better.

The issue about a global ID being used for the Regex is also moot, because this is a standalone procedure. If you were including it in a larger system, then of course you would account for that. :roll:

So the second implementation is safer.

I can understand to post code excerpt in the forum simplified or without error checking for example when they serve to illustrate a point. Your was perfectly valid in that regard.

All this babbling is because someone else took the time to post something a little better, some more real-life code and you started to release smoke from the ears, and started to talk about pre-optimization and posting silly images instead of replying after asking other people to spend some of their time doing so.

But this is not over optimizing, this has very little to do with pre-optimization but only with writing good code form the start because an experienced programmer do so without any particular effort.

[Kale]

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil."
--Donald Knuth

[luis]

Yes, you are great blind quoter and image linker.

It's easier.

The phrase you just quoted is inside the link I posted BTW, and it's cited trying to understand its meaning, instead of using it as a shield for your own shortcomings.

I leave to you the last post. I will not reply because you really seem to feel the urge to post something (an image, or other people's words) even if you have nothing to say by yourself.

Anyway, and I conclude here: not trying to optimize code when you still don't know where the bottlenecks of the final program will be doesn't mean you have to write bad code in the hope of remembering to fix it later if the need will arise.

edited: typo
And as preditcted he had the last word, repeating his dogma like a broken record. Very Kale-ish.