[thelist] Just a quick WTF: How to cut off a number after acertainamount of decimals

Matt Warden mwarden at gmail.com
Tue Mar 28 13:13:51 CST 2006

Hi Christian,

On 3/28/06, Christian Heilmann <codepo8 at gmail.com> wrote:
> > The two solutions presented simply offer two ways of getting around
> > the need for code for the loop in the function (but it's still
> > there!).
> How so? Native in the pow() method? If that is the case (which it must
> be) that'll make it more efficient as you don't need to rely on the
> for() method to execute every time you want to calculate.

The operation is O(n) whether you use the loop in the parser or the
loop in code. I was trying to say that without whipping out asymptotic
notation, is all.

(There is also an O(log n) algorithm for exponentiation, but the same
idea applies there as well.)

> A loop is never a more efficient way than relying on code that is
> already in the parser.

Never say never. What if my parser is written in JavaScript? It's
pretty pointless to talk about what parsers/compilers might and might
not do, which is why people stick to asymptotic notation.

> You could use for example var p=document.getElementsByTagName('p')[4]
> to reach the fifth paragraph or
> var allElm=document.getElementsByTagName('*');
> var count=0;
> for(var i=allElm.length;i++){
> if(allElm[i].nodeName.toLowerCase()!='p'){continue;}
> if(count==4){
>   var p=allElm[i];
>   break;
> }
> count++
> }
> The simple p[4] does all the other bits the loop does and guess what
> executes faster with less processor overhead? :)

Who knows? The only way to know is to test it or read the parser
source, and then that answer is limited only to the parser(s) you
tested/read. Blanket statements like this are reasonable with some
languages where there are only one or two compilers available.

If anyone knows about JavaScript parser implementations here, it'd be
you. So maybe you are able to make generalizations based on what you
know about various JavaScript implementations. But it's usually not
practical, and it's better to focus on algorithmic
complexity/efficiency (except in cases where bugs, like memory leaks,
in specific implementations need to be known and coded around).

> All I am saying (is give peace a chance) is that if you want to use a
> technology, it might be a good plan to read up on it and see what is
> there.

Much agreed.

> That CSS, HTML and JavaScript are easy to learn and quick to develop
> and test and that browsers are very forgiving is no excuse to check
> your own stuff from time to time to see what can be done more
> efficiently or cleaner using inbuilt functionality. Isn't that what
> the whole web standards movement is about?

Yes. Standard, norm, whatever. I was just pointing out that there is a
difference between that which is good because it is standard and that
which is good because it is better. (Hopefully, there is quite a bit
of overlap, but there are a lot of instances, especially outside of
programming, where this is not the case.)

It was a minor point, really.

Matt Warden
Miami University
Oxford, OH, USA

This email proudly and graciously contributes to entropy.

More information about the thelist mailing list