It does sounde funny, but I did this and use 5 - 6 - 7 for n and just see what happens 5 & 6 yeold 0 and ....:

OldMan said:

It does sounde funny, but I did this and use 5 - 6 - 7 for n and just see what happens 5 & 6 yeold 0 and ....:

Code:Copy to clipboard

    <script>
        count = 150;
        n = 7
        alert(count/n);
    alert((count/n)%1);
    </script>

Click to expand...

Thanks for checking. Yeah, I get it now 💡 Should have realized % 1 simply returns the decimal fraction. Everybody else would have written the check as
if ( count % n == 0 ) but I guess the programmer of this example wanted to show off a bit 😂

As a rule. Anything modula 1 is 0.

n%1 = 0


The fact this worked for anyone is the reason I hate Javascript.

PaulC said:

As a rule. Anything modula 1 is 0.

Click to expand...

Should that not be "any integer modulo 1 is zero" ?
And is this specific for Javascript then ? If so, is it a valid reason to hate JS ?

It's mathematically correct that anything modulus 1 is 0.

Think about it. Modulus gives you the remainder of the division (*).

We know that:

x / 1 = x

Therefore anything divided by 1 cannot return a remainder.

Note the original x, the result and the divisor can all be real numbers. Modula is not an integer concept. You might be thinking or x-x.floor()?

* - Technically modula is signed, usually taking the sign of the divisor and a few other caveats as it is calculated via an equation rather than divide/take remainder. Java script is supposed to have a proper modulus operator, not a remainder operator.

So I'm curious. What inputs result in a non 0 answer.

My comment about hating JS, is because of things like this. It will turn out to be an odd type interpretation of an intermediate value in the equation which results in a non-sensical answer. Or more than likely a float precision rounding error.

I had the same argument initialliy, and it's exactly what confused me in the first place. But now somehow I also dig the fact that the result can be non-zero:

Anyway it's a bit of a moot case isn't it. One should just not write code like that. I blame the W3C coder for trying to be cute instead of sensibly writing if ( count % n == 0 ). I agree JS is too loosely typed, and sometimes quirky, but I find if you write good code, and don't try to explore the boundaries and vagaries of the language (in other words don't try to be clever) you seldom if ever get bitten by that. I don't hate JS for not being perfect 😉

Thanks for your feedback, interesting discussion.

Its an odd one all right.

I checked and any non-integer % 1 gives x - floor(x) equivalent answer.

EG:
3.5%1 = 0.5

I also tested this is the case in "bc".

Python too.

Then python gave me this:
>>> 3.3%1.1
1.0999999999999996

At which point I gave up. That is not correct. 3.3%1.1 should be 0 as 1.1 divides equally 3 times into 3.3. I'm confused. What are we missing?

All I can think is the rules are different for real numbers.

I did some more digging. It opens a few "cans of worms".

There are two different ways to calculate a "remainder", rounding and truncating. However there is another way entirely to calculate Modula.

The trouble arises when you use floating point numbers as the intuitive results no longer apply. There are competing interruptions which produce different answers. Some favouring "analogous" behaviour to the Integer "remainder" functionality. This is what yields, for example, 3.5%1 = 0.5 It's "analogous" to the integer *remainder* operator in that 1 divides 3 times leaving remainder 0.5. Or x%1 where x is a floating point = x-floor((x/1)) (truncation), or x-round((x/1)) (rounding). This is invalid according to the rules of true modulus.

So even if you read up on the IEEE and the various language specs and source code to get an understanding of the answers a particular language or library WILL give you, you will still run into binary decimal approximation issues. A computer cannot represent a 1/10th in binary. So even simple calculations like 3.3%1.1 result in completely incorrect answers. Using a high precision math's library (like Java BigDecimal) can get you closer to sensible answers.

To summarise.... don't use floating point/real numbers with the % of Math.fmod() function unless you really know what you are doing. If you are using a language which does not default to integer division (like JS) round them yourself first so you get an intuitive answer.

Wow, you've really dug into that. I believe all you wrote. However I think it's as moot as can be. If there is a point at all in wanting to use the modulo function on non-integer values, I don't see it. Strange though that both Python and Node.js give the same result 3.3 % 1.1 = 1.0999999999999996 which looks spectacularly wrong. But I guess the result could just as well have been 0.0000000000000004 in which case I'd have said fair enough, 14 digits precision is not so bad. Evidently there's no such thing as an exact division of real/float numbers, as both Python and Node.js say 3.3 / 1.1 = 2.9999999999999996 Anyway I'll let this go now, I don't like cans of worms.

One last question: do you hate Python as well now ?

I hate that you can't trust JS. Mind I go way, way back to NS4 days. When each browser had it's own, virtually incompatible version of JS. You literally had to write a script for IE, a script for NS and a script for Opera when it showed up.

A lot of that STILL happens in production JS. It's just it's hidden in minimized framework includes. There are wrappers around the quirks to try and protect you as well.

I have also watched/read the lists and lists of absolutely hilarious dynamic type hiccups resulting in garbage. I have experienced these myself in JS.

As to who thought it was a good idea to move JS from the sandbox and into compiled and executed live on the CPU native language better have known what they were doing. However I have already seen people running JS Compute code on my browser while I'm on their website. I only noticed as they went for about 4 cores, so I noticed the fans. JS is also as a result a vector for the likes of Spectre CPU vulnerability and JS from a web page, via an exploit can gain not just privileged access, but kernel access. I believe chrome on Linux still uses a sandbox chroot environment for the JS engine.

Python has it's own set of issues, but it's considerably better defined that JS is "in the wild".

No language is king. Although valid arguments could be made towards C being the king. I mean if you remove all the languages written IN C, or languages written in languages written in C recursively ... the list is incredibly short. That would suggest that if all other languages disappeared tomorrow, you could still produce the same functionality from computers.

By the way, Java gives just as bad an answer. Using BigDecimals and the BigDecimal remainder() function is recommended.

To summarize, and conclude, the discussion: no language is perfect.

cbreemer said:

To summarize, and conclude, the discussion: no language is perfect.

Click to expand...

Exactly. The more you can master, the bigger and more useful your toolkit and the faster you can adopt to new ones. That would be my advice.