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

[Christian Heilmann]

> Well, we should be careful here. Which one of these is the
> "inefficient and tortuous solution"?
>
>   function cutVal(val,d){
>     var x='100000000000000000000'.substring(0,d+1);
>     return parseInt(val*x)/x;
> }
>
> function cutOff(val,decimals){
>     var x = Math.pow(10,decimals);
>     return parseInt(val*x)/x;
> }

You omit the first switch solution there, which is the real bad idea
as it is neither scalable nor very helpful to the overall size of the
code.

> The first requires that one know that in JavaScript a string like
> '100' will be converted implicitly to an integer in the val*x context,
> and the second requires that one know that Math.pow(x, y) will return
> x^y. I remember when I first saw Math.pow(). I had no idea what it did
> (what's a pow?) until I read the documentation.
> The 'wtf' comes into play only because more seasoned developers
> conform to a solution like the second, using a library function. But
> the use of the library function is the only difference in these two
> solutions.

Not really, what the pow() solution does is keep the type of the
variable always as numbers whereas the string method does mix types.
This is no problem in JavaScript but will come back to haunt you when
you want to use other, higher programming languages later.

> So, I guess my point is just that we might want to be careful
> distinguishing inefficiency and tortuousness from that which simply
> goes against the programmer norm (which one becomes increasingly
> accustom to through formal and informal training).

That is the response I was actually anticipating sooner or later.
Going against the norm is not what I was confused about, not grasping
that the issue is exclusively a number and calculation problem is.

Whenever you learn a new skill your ambition tells you that you can do
it so much better than others did before you and you will find a way
nobody else thought of before. The other process is that you find out
about one thing and you want to implement it everywhere immediately
(if you have a hammer, everything looks like a nail - or a thumb,
depending how clumsy you are). The first developer learnt about
conditions and thought that was all he'll ever need. The second one
looked at strings and thought that is the solution to everything.
These are temptations you have to resist from time to time or else
you'll invent the wheel once more. I am not saying that you shouldn't
stop questioning concepts and norms in place, I am just saying that
you should recognise a problem for what it is and find the appropriate
solution.

> I would consider the most readable solution something like this:
>
> function floorDecimal(decimal, places){
>     var shiftfactor = 1;
>
>     // calculate 10^places
>     for (var i=1; i<=places; i++) {
>         shiftfactor= shiftfactor * 10;
>     }
>
>     return parseInt(decimal*shiftfactor)/shiftfactor;
> }
>
> 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.

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

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? :)

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. I discovered that to be inherently against the male psyche. We
buy high tech stuff and instead of reading the manual we switch it on,
attach it and when it doesn't work the first thing we do is shake it
or hit it - which surely must be the best way to fix high-tech things
with small bits inside.
I wasted years writing complex PHP functions and realising when I got
stuck and looked into the documentation that there was a method that
does exactly what I was trying to achieve already built in.

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?


regards,

chris

--
Chris Heilmann
Blog: http://www.wait-till-i.com
Writing: http://icant.co.uk/
Binaries: http://www.onlinetools.org/