Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #13649 > unrolled thread

Javascript Math problem

Back to article view | Back to comp.lang.javascript

Contents

  Javascript Math problem Tom <thart@vicon.net> - 2012-04-27 15:41 -0700
    Re: Javascript Math problem Stefan Weiss <krewecherl@gmail.com> - 2012-04-28 01:33 +0200
      Re: Javascript Math problem Tom <thart@vicon.net> - 2012-04-27 18:02 -0700
      Re: Javascript Math problem Dr J R Stockton <reply1217@merlyn.demon.co.uk.not.invalid> - 2012-04-29 21:07 +0100
        Re: Javascript Math problem "Evertjan." <exjxw.hannivoort@interxnl.net> - 2012-04-30 08:06 +0000
          Re: Javascript Math problem Tom <thart@vicon.net> - 2012-04-30 01:33 -0700
          Re: Javascript Math problem Dr J R Stockton <reply1218@merlyn.demon.co.uk.not.invalid> - 2012-05-01 19:30 +0100
    Re: Javascript Math problem "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2012-04-27 17:30 -0700
      Re: Javascript Math problem Tom <thart@vicon.net> - 2012-04-27 18:05 -0700
      Re: Javascript Math problem Stefan Weiss <krewecherl@gmail.com> - 2012-04-28 04:00 +0200
        Re: Javascript Math problem Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-04-28 13:04 +0200
          Re: Javascript Math problem Stefan Weiss <krewecherl@gmail.com> - 2012-04-28 21:10 +0200
            Re: Javascript Math problem Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-04-28 22:23 +0200
              Re: Javascript Math problem "Jukka K. Korpela" <jkorpela@cs.tut.fi> - 2012-04-28 23:39 +0300
              JS/Terminology (was: Javascript Math problem) Stefan Weiss <krewecherl@gmail.com> - 2012-04-29 05:59 +0200
                Re: JS/Terminology Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-04-29 16:15 +0200
                  Re: JS/Terminology Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-04-29 16:20 +0200
                  Re: JS/Terminology Puzzled <scratching.head@example.com> - 2012-05-07 16:22 -0400
                    Re: JS/Terminology Gene Wirchenko <genew@ocis.net> - 2012-05-07 14:36 -0700
                      Re: JS/Terminology "Evertjan." <exjxw.hannivoort@interxnl.net> - 2012-05-08 08:40 +0000
                        Re: JS/Terminology Gene Wirchenko <genew@ocis.net> - 2012-05-08 09:29 -0700
              Re: Javascript Math problem John G Harris <john@nospam.demon.co.uk> - 2012-04-29 17:30 +0100
            Re: Javascript Math problem Scott Sauyet <scott.sauyet@gmail.com> - 2012-04-30 06:19 -0700
              Re: Javascript Math problem Dr J R Stockton <reply1218@merlyn.demon.co.uk.not.invalid> - 2012-05-01 19:48 +0100
                Re: Javascript Math problem Gene Wirchenko <genew@ocis.net> - 2012-05-01 19:30 -0700
        Re: Javascript Math problem "Mel Smith" <med_cutout_syntel@aol.com> - 2012-04-28 09:00 -0600
      Re: Javascript Math problem "Evertjan." <exjxw.hannivoort@interxnl.net> - 2012-04-28 09:02 +0000

Page 2 of 2 — ← Prev page 1 [2]

#13863 — Re: JS/Terminology

On 08 May 2012 08:40:59 GMT, "Evertjan."
<exjxw.hannivoort@interxnl.net> wrote:

>Gene Wirchenko wrote on 07 mei 2012 in comp.lang.javascript:
>
>> On Mon, 07 May 2012 16:22:51 -0400, Puzzled
>> <scratching.head@example.com> wrote:
>> 
>> [snip]
>> 
>>>One is rather tongue-in-cheek:  if they have armies to back them
>>>up (i.e., are spoken by different political entities), they're
>>>languages.  Thus, Danish, Norwegian, and Swedish are recognised
>>>as separate languages.
>> 
>>      As I recall, a navy is also required. 
>
>Easy in Javascript, while you are in your element:
>
>myElement.style.backgroundColor = 'navy';
>
>or
>
>myElement.style.backgroundColor = '#008';
>
><http://www.usingenglish.com/reference/idioms/in+your+element.html>

      Nicely played, sir!

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#13693

On Sat, 28 Apr 2012 at 22:23:38, in comp.lang.javascript, Thomas
'PointedEars' Lahn wrote:

  <snip>
>Since JavaScript 1.0 and JScript 1.1 can be considered obsolete, the catch-
>all term for the rest of discussions is there: ECMAScript implementations.
  <snip>

He finds two examples that destroy his proposed naming scheme so what
does he do? He deems them to be irrelevant : problem solved.

Unfortunately for him, they are still on-topic for this news group.

  John
-- 
John Harris

[toc] | [prev] | [next] | [standalone]

#13715

Stefan Weiss wrote:
> Thomas 'PointedEars' Lahn wrote:
>> Stefan Weiss wrote:
>>> On 2012-04-28 02:30, Michael Haufe (TNO) wrote:
>
>>>> function f(n){ return (n-(n%3))/3 }
>
>>> Ah yes, I forgot to add that one.
>
>> However, that approach requires three floating-point operations (and one
>> call of a user-defined function), whereas
>
>>   Math.floor(n / 3)
>
>> only requires two (and one property access and one built-in function call).
>> ISTM that therefore the cost and potential rounding error is greater with
>> the former than with the latter, and that the latter should be preferred,
>> at least for n >= 0.
>
> I also had the suspicion that rounding could introduce errors here, and
> I did a half-hearted search for such a case, but couldn't find one.

Does anyone have a case where this rounding is an issue?  Although
these are floating point operations, since the first one to execute is
a modulus and the next is integeer subtraction, only the final
division seems likely to have real rounding issues, and that's done in
any of these solutions.

> Things might get interesting at the 2^32 boundary for bit operations,
> and 2^53 for arithmetic operations, but for calculations with numbers of
> that magnitude we need to take special precautions anyway.
>
> As for performance, function calls (built-in or user-defined) are
> generally much more expensive than numeric operations (unless the
> functions are inlined by the compiler). Without testing, I'd expect
> (a/b)|0 or (a/b)>>0 to perform best out of the expressions mentioned in
> this thread. Math.floor() would still be my choice for the "normal"
> case, small positive integers and few repetitions, because the intent of
> the code is immediately obvious.

I did a quick test on JSPerf:

    <http://jsperf.com/floor-alternatives>

and the results are far from conclusive.  I tested the three browsers
I have on my work desktop and my Android phone.  In each case, the
threee bitwise versions clumped together:

    ~~(5 / 3)
    (5 / 3) >> 0
    (5 / 3) | 0

There was little to distinguish them, although the first might be a
bit less performant than the other two.

But there was a major discrepancy between `Math.floor(5 / 3)` and `(5
- (5 % 3)) / 3`.  In Android 2.3.4, Math.floor was substantially
slower than the bitwise operators, which were substantially slower
than modulus-subtract-divide.  In Chrome 19.0.1077, Math.floor was
slightly faster than the bitwise operators, and a bit slower than
modulus-subtract-dived.  In Firefox 10, Math.floor was slightly slower
than most of the bitwise operators, but more than twice as fast as
modulus-subtract-divide.  And in IE 8.0.3, Math.floor was quite a bit
slower than modulus-subtract-divide, which was slightly slower than
the bitwise operators.  Of course the raw numbers for each browser was
significantly different.

So, I guess the answer is, as always, "it depends".  And since even
the slowest off all these (Math.floor on IE) ran over 1.2 million
operations per second, it's likely to be a rare case where this speed
even matters.

  -- Scott

[toc] | [prev] | [next] | [standalone]

#13751

In comp.lang.javascript message <67b160c3-9bd2-4872-9601-3125fff1c852@r1
3g2000vbg.googlegroups.com>, Mon, 30 Apr 2012 06:19:50, Scott Sauyet
<scott.sauyet@gmail.com> posted:

>
>But there was a major discrepancy between `Math.floor(5 / 3)` and `(5
>- (5 % 3)) / 3`.  In Android 2.3.4, Math.floor was substantially
>slower than the bitwise operators, which were substantially slower
>than modulus-subtract-divide.  In Chrome 19.0.1077, Math.floor was
>slightly faster than the bitwise operators, and a bit slower than
>modulus-subtract-dived.  In Firefox 10, Math.floor was slightly slower
>than most of the bitwise operators, but more than twice as fast as
>modulus-subtract-divide.  And in IE 8.0.3, Math.floor was quite a bit
>slower than modulus-subtract-divide, which was slightly slower than
>the bitwise operators.  Of course the raw numbers for each browser was
>significantly different.

For simple cases like that, a browser might optimise out the formal call
to the actual function floor, in favour of working out the result at
compile time.  Then, the speed tests would be misleading.

Such a browser might (or might not) be deluded by executing, say,
Math["flo"+"or"] = Math.random before the call-under-test.  Certainly,
in MSIE 8, Firefox 12.0, Opera 11.62, Safari 5.1.5, Chrome 18.0,
Math.floor is not readonly :

        X = Math.floor(3.77)
        Math.floor = function () { return 2.96 }
        Y = Math.floor(3.77)
        Z = [X, Y]                      // gets [3,2.96]


-- 
 (c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk  Turnpike 6.05  WinXP.
 Web  <http://www.merlyn.demon.co.uk/> - FAQ-type topics, acronyms, and links.
 Command-prompt MiniTrue is useful for viewing/searching/altering files. Free,
 DOS/Win/UNIX now 2.0.6; see <URL:http://www.merlyn.demon.co.uk/pc-links.htm>.

[toc] | [prev] | [next] | [standalone]

#13754

On Tue, 1 May 2012 19:48:53 +0100, Dr J R Stockton
<reply1218@merlyn.demon.co.uk.not.invalid> wrote:

[snip]

>For simple cases like that, a browser might optimise out the formal call
>to the actual function floor, in favour of working out the result at
>compile time.  Then, the speed tests would be misleading.

     There are lies, damned lies, statistics, damned statistics, and
then there are compiler benchmarks.

>Such a browser might (or might not) be deluded by executing, say,
>Math["flo"+"or"] = Math.random before the call-under-test.  Certainly,
>in MSIE 8, Firefox 12.0, Opera 11.62, Safari 5.1.5, Chrome 18.0,
>Math.floor is not readonly :
>
>        X = Math.floor(3.77)
>        Math.floor = function () { return 2.96 }
>        Y = Math.floor(3.77)
>        Z = [X, Y]                      // gets [3,2.96]

     I would be floored if I got a result like that.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#13670

Stefan said:
> In JS, -5.5 % 3 is -2.5 ...
>
> In PHP, -5.5 % 3 is -2 ...
>
> In Python, -5.5 % 3 is 0.5 ...
>
> In Perl, -5.5 % 3 is 1 ...
>  (unless you "use integer", then it depends on the compiler)
>
> In C, -5.5 % 3 doesn't work at all (int only)...
>  (but fmod(-5.5, 3) returns -2.5)
>  (oh, and the behavior with negative numbers is
>     "implementation defined")
>

Stefan:

    ... and in my language (xHarbour -- eXtended Harbour: a language that is 
compiled into C functions using the old Borland BCC 5.5.1 verion in this 
instance), the statement and results are:

   nTest := -5.5 % 3
   ? ntest            // result -2.5
   ? str(nTest)    // result -2.5  -- same

-Mel

[toc] | [prev] | [next] | [standalone]

#13660

Michael Haufe (TNO) wrote on 28 apr 2012 in comp.lang.javascript:

> On Friday, April 27, 2012 5:41:55 PM UTC-5, Tom wrote:
>> Hi, I was wondering if someone could help me with math puzzle.  I
>> need a function that will give me the number of times an integer is
>> divisible by 3, but I can't use the round function.   In other words,
>> if I sent the value of 6, it would return 2 since 6/3 = 2.  9/3 = 3
>> etc. For numbers that are not evenly divisible,  5/3 would need to
>> return 1, 7/3 would return 2 etc, basically scrap the decimal
>> numbers.  But like I said it can't use round.
>> 
>> I was thinking that possibly it would use some combination of the 
>> division and modulus operators (/,%), but I haven't been able to
>> figure it out yet.
>> 
>> Can anyone think of anything?  Thx
> 
> Simple enough for the mathematically inclined:
> 
> function f(n){ return (n-(n%3))/3 }

I would prefer (given n>=0 for both functions):

function f(n) {return Math.floor(n/3);};

visually simpler (so less bug-prone), and perhaps faster.

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.javascript

csiph-web