Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.javascript > #28754 > unrolled thread
| Started by | jonas.thornvall@gmail.com |
|---|---|
| First post | 2015-09-28 23:24 -0700 |
| Last post | 2015-09-30 13:28 +0200 |
| Articles | 5 — 5 participants |
Back to article view | Back to comp.lang.javascript
Comparisson operators jonas.thornvall@gmail.com - 2015-09-28 23:24 -0700
Re: Comparisson operators "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-09-29 12:16 +0200
Re: Comparisson operators Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-29 12:24 +0100
Re: Comparisson operators Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-09-29 19:39 +0200
Re: Comparisson operators Silvio <silvio@internet.com> - 2015-09-30 13:28 +0200
| From | jonas.thornvall@gmail.com |
|---|---|
| Date | 2015-09-28 23:24 -0700 |
| Subject | Comparisson operators |
| Message-ID | <807dd61a-97ec-48cb-ad49-c6292a448a73@googlegroups.com> |
Does the comparisson operators also suffer from the 32/64 bit integer limit? What happens if you assign a bigger value will it get truncated? And what happen if you try to compare elements that is bigger than the scope of javascript integers?
[toc] | [next] | [standalone]
| From | "Evertjan." <exxjxw.hannivoort@inter.nl.net> |
|---|---|
| Date | 2015-09-29 12:16 +0200 |
| Message-ID | <XnsA5247CDE043D1eejj99@194.109.6.166> |
| In reply to | #28754 |
jonas.thornvall@gmail.com wrote on 29 Sep 2015 in comp.lang.javascript: > Does the comparisson operators also suffer from the 32/64 bit integer > limit? What happens if you assign a bigger value will it get truncated? Seems simple to test for with your level of experience. Did you? Results? Operators feel no pain, maybe you do. > And what happen if you try to compare elements that is bigger than the > scope of javascript integers? What is 'the scope of javascript integers'? Integers have no scope, they are blind, meseems. -- Evertjan. The Netherlands. (Please change the x'es to dots in my emailaddress)
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-09-29 12:24 +0100 |
| Message-ID | <87twqdcvt1.fsf@bsb.me.uk> |
| In reply to | #28754 |
jonas.thornvall@gmail.com writes: > Does the comparisson operators also suffer from the 32/64 bit integer limit? > What happens if you assign a bigger value will it get truncated? You should start by understanding what the type Number is in ECMAScript. It is not an integer type in the usual sense of the word. It is a floating point type with very specific properties usually rather loosely called "IEEE floating point". It can, of course, store integer values, but your reference to a "32/64 bit integer limit" suggests you don't know what ECMAScript numbers are. > And what happen if you try to compare elements that is bigger than the > scope of javascript integers? A normal floating-point comparison is done, just as it always is. What matters is the range of integer values that can be represented exactly. That range is -(2**53 - 1) to 2**53 - 1. The latest ECMAScript defines property, Number.MAX_SAFE_INTEGER with the value 9007199254740991, but you can always calculate Math.pow(2, 53) - 1. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2015-09-29 19:39 +0200 |
| Message-ID | <2785430.nENm2z7bcr@PointedEars.de> |
| In reply to | #28760 |
Ben Bacarisse wrote: > jonas.thornvall@gmail.com writes: >> And what happen if you try to compare elements that is bigger than the >> scope of javascript integers? > > A normal floating-point comparison is done, just as it always is. What > matters is the range of integer values that can be represented exactly. > That range is -(2**53 - 1) to 2**53 - 1. The latest ECMAScript defines > property, Number.MAX_SAFE_INTEGER with the value 9007199254740991, but > you can always calculate Math.pow(2, 53) - 1. This description is so imprecise as to be misleading. Several integers smaller and greater than these boundaries can be stored exactly, but the integers *between* the boundaries and the stored integers cannot be, because the achievable precision is insufficient. Insofar Number.MIN_SAFE_INTEGER and Number.MAX_SAFE_INTEGER only give the minimum/maximum integer down/up to which proper arithmetic is possible (hence “SAFE”). The minimum/maximum integer than can be represented exactly with IEEE 754 doubles is approximately ±1.8 × 10³⁰⁸; it is exactly given by -Number.MAX_VALUE and Number.MAX_VALUE, respectively. (Note that Number.MIN_VALUE gives the smallest floating-point value greater than 0 instead.) -- PointedEars FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/> Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix> Please do not cc me. / Bitte keine Kopien per E-Mail.
[toc] | [prev] | [next] | [standalone]
| From | Silvio <silvio@internet.com> |
|---|---|
| Date | 2015-09-30 13:28 +0200 |
| Message-ID | <560bc747$0$23724$e4fe514c@news.xs4all.nl> |
| In reply to | #28754 |
On 09/29/2015 08:24 AM, jonas.thornvall@gmail.com wrote: > Does the comparisson operators also suffer from the 32/64 bit integer limit? > What happens if you assign a bigger value will it get truncated? > > And what happen if you try to compare elements that is bigger than the scope of javascript integers? > You keep asking questions that you would not have to ask if you actually read the responses you get. People keep telling you that JavaScript (or ECMAScript if you will) has neither 32 nor 64 bit integers and that all numerical values are just that, IEEE floating point variables that happen to be able to represent a range of whole numbers. Operations on numerical values, including comparisons, are performed as IEEE floating point operations. And before you post any more code: PLEASE LEARN HOW TO USE LOCAL VARIABLES OR FORGET ABOUT PROGRAMMING ANYTHING SERIOUS ALTOGETHER!!!
[toc] | [prev] | [standalone]
Back to top | Article view | comp.lang.javascript
csiph-web