![]() |
Add proper ending to number (st, nd, rd, th)
I'm pretty sure (though it's very possible I'm wrong) that PHP doesn't have anything built in to do this outside of dates and I searched the internet and couldn't find anything worth a darn via google.
PHP Code:
|
PHP Code:
|
I tried oesxyl's function and it stopped working at 21 and everything ended with "th".
I found the following code on http://www.talkphp.com/tips-tricks/2...ers-dates.html and it worked like a charm. :) PHP Code:
|
*Edit*
I didn't see the other response. Assuming his doesn't work, mine would be the shortest yet, does that make a difference in terms of speed? I also just realized that 11 would come out 11st...thus requiring another another if statement... |
Quote:
PHP Code:
Code:
-1Quote:
best regards |
Quote:
|
Quote:
33 would be 33rd not 33th. |
just fix the problem:
PHP Code:
|
Quote:
I fix this in #8. I don't know which is faster, mine is obvious shorter. best regards |
seems that previous was incorrect, see 11st, 12nd, 13rd vs. 11th, 12th, 13th:
Fixed: PHP Code:
|
PHP Code:
|
I'm very new to PHP and programming in general. It's becoming increasingly clearer that there is more than one way to do just about anything and ultimately it comes down to using the most efficient method available.
The question then is how we know which way is the most efficient. Here we have 3 functions that all do the same thing different ways, which one works the best though? |
Thats trickier to answer. When it comes to algorithms, most of them can be calculated by an order of magnitude. Since these all have an O(1) magnitude, they are all technically as efficient from a magnitude view. Magnitude really only cares about the 'big' picture as a whole.
So, look at other factors. Datatypes are my primary concern. If you treat you're number as a string, you will waste time and resource, but looking at the last digit itself is a matter of a char lookup. So, should the number be interpreted as a string, any string > 4 characters in length has exceeded the memory size required for any number storable as an integer (and this will increase in PHP6 which is going to native unicode). kbluhm and oesxyl have both ensured that they are working with numbers. Oesyxl's approach is slightly more efficient, but will not tell you if its actually a number (and therefore becomes untrappable). It doesn't care if you give it a string, if you do it will cast it to a number. I believe that the is_* functions are slightly less efficient than direct casting. The benifit is you can toss and trap errors associated with this approach. Though the codes are negligable, efficiency wise I expect that oesxyl's will be slightly faster in execution time; however, like I mentioned there is little that can be done to trigger / throw and trap any errors from it since it technically cannot have any errors with the explicit casting. Oesxyl's appears to also waste a little more memory than kbluhm's method since it declares two local variables (since the third is a write-on-copy context). Weight on weight, I'll bet if I tested these to benchmark on precision to 1000, they would come up identical. At 100000, I'd suspect to see a 5 - 8 variance, which is incredibly tiny. Also, one more factor is readability. Efficiency is IMO tossable for readability in languages like PHP. We're not doing embedded microprocessing, so memory and cpu are not really an issue nowadays. You can certainly take a more readable approach so you can understand later what you've done without needing to walk through it step by step (from the above, kbluhm's is more readable than oesxyl's). |
Quote:
best regards |
My thoughts:
PHP Code:
PHP Code:
|
| All times are GMT +1. The time now is 11:15 PM. |
Powered by vBulletin®
Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.