Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.javascript > #27427 > unrolled thread
| Started by | jonas.thornvall@gmail.com |
|---|---|
| First post | 2015-04-30 00:11 -0700 |
| Last post | 2015-04-30 10:52 -0700 |
| Articles | 20 on this page of 105 — 9 participants |
Back to article view | Back to comp.lang.javascript
Overflow, integers and strings jonas.thornvall@gmail.com - 2015-04-30 00:11 -0700
Re: Overflow, integers and strings jonas.thornvall@gmail.com - 2015-04-30 01:29 -0700
Re: Overflow, integers and strings jonas.thornvall@gmail.com - 2015-04-30 03:31 -0700
Re: Overflow, integers and strings jonas.thornvall@gmail.com - 2015-04-30 03:33 -0700
Re: Overflow, integers and strings "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-04-30 13:38 +0200
Re: Overflow, integers and strings jonas.thornvall@gmail.com - 2015-04-30 08:20 -0700
Re: Overflow, integers and strings "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-04-30 20:37 +0200
Re: Overflow, integers and strings jonas.thornvall@gmail.com - 2015-04-30 23:46 -0700
Re: Overflow, integers and strings jonas.thornvall@gmail.com - 2015-05-01 01:01 -0700
Re: Overflow, integers and strings jonas.thornvall@gmail.com - 2015-05-01 01:47 -0700
Re: Overflow, integers and strings "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-05-01 10:50 +0200
Re: Overflow, integers and strings jonas.thornvall@gmail.com - 2015-05-01 02:04 -0700
Re: Overflow, integers and strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-01 11:08 +0100
Re: Overflow, integers and strings jonas.thornvall@gmail.com - 2015-05-01 04:43 -0700
Re: Overflow, integers and strings jonas.thornvall@gmail.com - 2015-05-01 04:46 -0700
Re: Overflow, integers and strings "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-05-01 10:48 +0200
Re: Overflow, integers and strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-01 10:58 +0100
Re: Overflow, integers and strings "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-05-01 14:34 +0200
Re: Overflow, integers and strings "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-05-01 14:47 +0200
Re: Overflow, integers and strings "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-05-01 15:04 +0200
Re: Overflow, integers and strings jonas.thornvall@gmail.com - 2015-05-01 06:18 -0700
Re: Overflow, integers and strings jonas.thornvall@gmail.com - 2015-05-01 06:24 -0700
Re: Overflow, integers and strings jonas.thornvall@gmail.com - 2015-05-01 06:49 -0700
Re: Overflow, integers and strings jonas.thornvall@gmail.com - 2015-05-01 07:00 -0700
Re: Overflow, integers and strings jonas.thornvall@gmail.com - 2015-05-01 07:17 -0700
Re: Overflow, integers and strings jonas.thornvall@gmail.com - 2015-05-01 07:21 -0700
Re: Overflow, integers and strings jonas.thornvall@gmail.com - 2015-05-01 07:37 -0700
Re: Overflow, integers and strings jonas.thornvall@gmail.com - 2015-05-01 11:27 -0700
Re: Overflow, integers and strings jonas.thornvall@gmail.com - 2015-05-01 12:34 -0700
Re: Overflow, integers and strings Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-05-01 22:42 +0200
Re: Overflow, integers and strings "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-05-01 23:37 +0200
Re: Overflow, integers and strings "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-05-02 00:19 +0200
Re: Overflow, integers and strings jonas.thornvall@gmail.com - 2015-05-02 05:50 -0700
Re: Overflow, integers and strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-02 14:21 +0100
Re: Overflow, integers and strings jonas.thornvall@gmail.com - 2015-05-03 04:30 -0700
Re: Overflow, integers and strings jonas.thornvall@gmail.com - 2015-05-03 07:12 -0700
Re: Overflow, integers and strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-03 16:45 +0100
Re: Overflow, integers and strings jonas.thornvall@gmail.com - 2015-05-03 09:17 -0700
Re: Overflow, integers and strings jonas.thornvall@gmail.com - 2015-05-03 09:22 -0700
Re: Overflow, integers and strings jonas.thornvall@gmail.com - 2015-05-04 03:38 -0700
Re: Overflow, integers and strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-04 14:01 +0100
Re: Overflow, integers and strings jonas.thornvall@gmail.com - 2015-05-04 06:41 -0700
Re: Overflow, integers and strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-04 15:39 +0100
Re: Overflow, integers and strings jonas.thornvall@gmail.com - 2015-05-04 07:48 -0700
Re: Overflow, integers and strings jonas.thornvall@gmail.com - 2015-05-04 06:49 -0700
Re: Overflow, integers and strings jonas.thornvall@gmail.com - 2015-05-04 07:25 -0700
Re: Overflow, integers and strings jonas.thornvall@gmail.com - 2015-05-04 08:26 -0700
Re: Overflow, integers and strings jonas.thornvall@gmail.com - 2015-05-04 08:59 -0700
Re: Overflow, integers and strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-05 00:59 +0100
Re: Overflow, integers and strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-04 15:28 +0100
Re: Overflow, integers and strings jonas.thornvall@gmail.com - 2015-05-04 07:34 -0700
Re: Overflow, integers and strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-04 15:41 +0100
Re: Overflow, integers and strings jonas.thornvall@gmail.com - 2015-05-04 07:52 -0700
Re: Overflow, integers and strings jonas.thornvall@gmail.com - 2015-05-04 08:03 -0700
Re: Overflow, integers and strings "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-05-04 17:56 +0200
Re: Overflow, integers and strings jonas.thornvall@gmail.com - 2015-05-04 09:04 -0700
Re: Overflow, integers and strings jonas.thornvall@gmail.com - 2015-05-04 09:21 -0700
Re: Overflow, integers and strings jonas.thornvall@gmail.com - 2015-05-04 09:38 -0700
Re: Overflow, integers and strings "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-05-04 21:07 +0200
Re: Overflow, integers and strings jonas.thornvall@gmail.com - 2015-05-04 12:25 -0700
Re: Overflow, integers and strings "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-05-04 21:43 +0200
Re: Overflow, integers and strings jonas.thornvall@gmail.com - 2015-05-04 12:46 -0700
Re: Overflow, integers and strings "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-05-04 22:11 +0200
Re: Overflow, integers and strings jonas.thornvall@gmail.com - 2015-05-04 12:53 -0700
Re: Overflow, integers and strings "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-05-04 22:23 +0200
Re: Overflow, integers and strings jonas.thornvall@gmail.com - 2015-05-04 13:40 -0700
Re: Overflow, integers and strings "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-05-04 23:12 +0200
Re: Overflow, integers and strings jonas.thornvall@gmail.com - 2015-05-04 13:06 -0700
Re: Overflow, integers and strings "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-05-04 22:39 +0200
Re: Overflow, integers and strings jonas.thornvall@gmail.com - 2015-05-04 13:42 -0700
Re: Overflow, integers and strings Scott Sauyet <scott.sauyet@gmail.com> - 2015-05-04 13:40 -0700
Re: Overflow, integers and strings jonas.thornvall@gmail.com - 2015-05-04 13:47 -0700
Re: Overflow, integers and strings "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-05-04 23:30 +0200
Re: Overflow, integers and strings "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-05-04 23:33 +0200
Re: Overflow, integers and strings jonas.thornvall@gmail.com - 2015-05-04 15:53 -0700
Re: Overflow, integers and strings jonas.thornvall@gmail.com - 2015-05-04 13:51 -0700
Re: Overflow, integers and strings Scott Sauyet <scott.sauyet@gmail.com> - 2015-05-04 18:00 -0700
Re: Overflow, integers and strings jonas.thornvall@gmail.com - 2015-05-04 18:22 -0700
Re: Overflow, integers and strings Scott Sauyet <scott.sauyet@gmail.com> - 2015-05-04 21:38 -0700
Re: Overflow, integers and strings jonas.thornvall@gmail.com - 2015-05-04 18:37 -0700
Re: Overflow, integers and strings jonas.thornvall@gmail.com - 2015-05-04 14:00 -0700
Re: Overflow, integers and strings jonas.thornvall@gmail.com - 2015-05-04 09:19 -0700
Re: Overflow, integers and strings "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-05-04 21:24 +0200
Re: Overflow, integers and strings wolfgang zeidler <invalid@invalid.invalid> - 2015-05-04 21:37 +0200
Re: Overflow, integers and strings "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-05-04 21:56 +0200
Re: Overflow, integers and strings jonas.thornvall@gmail.com - 2015-05-04 13:21 -0700
Re: Overflow, integers and strings wolfgang zeidler <invalid@invalid.invalid> - 2015-05-04 22:38 +0200
Re: Overflow, integers and strings "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-05-04 22:46 +0200
Re: Overflow, integers and strings "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-05-04 22:57 +0200
Re: Overflow, integers and strings "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-05-04 23:17 +0200
Re: Overflow, integers and strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-05 00:45 +0100
Re: Overflow, integers and strings "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-05-06 00:01 +0200
Re: Overflow, integers and strings Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-05-05 08:14 +0200
Re: Overflow, integers and strings "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-05-05 23:54 +0200
Re: Overflow, integers and strings wolfgang zeidler <invalid@invalid.invalid> - 2015-05-04 23:18 +0200
Re: Overflow, integers and strings "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-05-04 23:53 +0200
Re: Overflow, integers and strings jonas.thornvall@gmail.com - 2015-05-04 16:06 -0700
Re: Overflow, integers and strings "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-05-05 10:26 +0200
Re: Overflow, integers and strings Dr J R Stockton <reply1500@merlyn.demon.co.uk.invalid> - 2015-05-05 19:59 +0100
Re: Overflow, integers and strings jonas.thornvall@gmail.com - 2015-05-04 07:40 -0700
Re: Overflow, integers and strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-05 01:10 +0100
Re: Overflow, integers and strings jonas.thornvall@gmail.com - 2015-05-01 05:03 -0700
Re: Overflow, integers and strings Ben Bacarisse <ben.lists@bsb.me.uk> - 2015-04-30 20:36 +0100
Re: Overflow, integers and strings jonas.thornvall@gmail.com - 2015-04-30 13:08 -0700
Re: Overflow, integers and strings Scott Sauyet <scott.sauyet@gmail.com> - 2015-04-30 10:52 -0700
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
| From | jonas.thornvall@gmail.com |
|---|---|
| Date | 2015-05-04 14:00 -0700 |
| Message-ID | <c62ae88a-cdc5-4840-8715-7e4d1d0865c0@googlegroups.com> |
| In reply to | #27513 |
Den måndag 4 maj 2015 kl. 22:40:50 UTC+2 skrev Scott Sauyet: > jonas.thornvall@gmail.com wrote: > > skrev Evertjan.: > >> jonas.thornvall@gmail.com wrote: > >> > >> Computations done on them are done on the integer value, and are also > >> independent of the base. > > > > You are a moron if you Think they are independent to interpretation. > > Evertjan is not a moron. And if you're not hearing what he's saying, > then you're not listening well. > > That doesn't mean that he isn't being a bit abrasive as well. But > you're going over the top here; he's not nearly as bad as you are. > > The representation of your data affects the speed of your computation. > This is true, and I really doubt Evertjan disputes that. > > You have done nothing to demonstrate that you can save time by changing > to a much higher base. Claiming that it has to be so is not enough, > especially as you will then have to start using look-up tables stored > in memory or in even slower storage, which will work against the savings > you could gain by doing fewer calculations. > > So I'd really like to see your evidence. > > -- Scott Basicly Scott i only need skilled programmers as you and Evertjan to show that the algorithm to interpretate the digit value matter for the compotational complexity. And it will all become clear, i could probably show you further shourcuts but i am a strawman. Mathematicians would do alot better. I am not responsible for the security of using RSA, but i remember using factors of same magnitude is hazarous, and may have give them a hint. Before we move on from positional number systems would someone please give me a hint i gave you the pesudo code, quite readable in my opinion. And i know you are far better programmers than i ever will be.
[toc] | [prev] | [next] | [standalone]
| From | jonas.thornvall@gmail.com |
|---|---|
| Date | 2015-05-04 09:19 -0700 |
| Message-ID | <f445a89f-ef58-4971-9485-017f85a6b8f1@googlegroups.com> |
| In reply to | #27492 |
Den måndag 4 maj 2015 kl. 17:56:36 UTC+2 skrev Evertjan.: > Ben Bacarisse <ben.usenet@bsb.me.uk> wrote on 04 mei 2015 in > comp.lang.javascript: > > >> No the magnitude of the base will help. > > > > Do you have any evidence for that? What is the optimal base to use? > > > > The whole exercise seems rather useless indeed, imho. > > Using different bases is only important for input and output of course string since it > > Doing other arithmetic, say + - *, in different bases than 2 seems just > overkill. [integer division can get non-integer results, so such results > even cannot be stored in integer arithmetic] > > Internally [storage and arithmetic] the only logical base is 2. > > If you need more resolution than javascript can deliver natively, > more than 32 bit integer, > just define an array of javascript native [= base 2] numbers. > > Then you would only need to accommodate for that. > > -- > Evertjan. > The Netherlands. > (Please change the x'es to dots in my emailaddress) I will of course implement fractionals/decimal points for all bases. But they will not be stored as floats but integers in an array. I have no intention implement storage structure and datatype until i get arithmetic and baseconversion in anybase. But it seem one type do not fit all bases. Who knows maybe i skip decimals and their eqivalent in other bases, and go for partitioning into sums of fractions to do arithmeric upon. That i way i keep it exact and do not lose digiplaces. But of course for input i must make a decimal to fraction converter
[toc] | [prev] | [next] | [standalone]
| From | "Evertjan." <exxjxw.hannivoort@inter.nl.net> |
|---|---|
| Date | 2015-05-04 21:24 +0200 |
| Message-ID | <XnsA490D9BA4524eejj99@194.109.133.246> |
| In reply to | #27495 |
jonas.thornvall@gmail.com wrote on 04 mei 2015 in comp.lang.javascript: > I will of course implement fractionals/decimal points for all bases. Why "of course"? Please give arguments for your points. However you are just talking about notation, not of basic arithmrtic. > But > they will not be stored as floats but integers in an array. I have no > intention implement storage structure and datatype until i get > arithmetic and baseconversion in anybase. But it seem one type do not > fit all bases. You are not making sense here. Storing values in binary is the most efficient in digitsl computers, and your conversions are just input/output. > Who knows maybe i skip decimals and their eqivalent in other bases, and > go for partitioning into sums of fractions to do arithmeric upon. You are not making sense here. > That i > way i keep it exact and do not lose digiplaces. But of course for input > i must make a decimal to fraction converter Again, you are talking about notation, so input/output, the values, wether integer or fractional, are independent of the notation base. btw, there are lots of values that cannot be notated in a 10-based decimal- point notation, like 1/3, or even as a fraction in any base, like pi, so as soon as you are allowing fractional values, exactness will go out of the window. So stop your self-inflicted impossible task and start enjoying Javascript and mathemetics. -- Evertjan. The Netherlands. (Please change the x'es to dots in my emailaddress)
[toc] | [prev] | [next] | [standalone]
| From | wolfgang zeidler <invalid@invalid.invalid> |
|---|---|
| Date | 2015-05-04 21:37 +0200 |
| Message-ID | <mi8hpl$k9p$1@news.m-online.net> |
| In reply to | #27492 |
Evertjan. wrote: > Ben Bacarisse <ben.usenet@bsb.me.uk> wrote on 04 mei 2015 in > comp.lang.javascript: > >>> No the magnitude of the base will help. >> >> Do you have any evidence for that? What is the optimal base to use? >> > > The whole exercise seems rather useless indeed, imho. > > Using different bases is only important for input and output. > > Doing other arithmetic, say + - *, in different bases than 2 seems just > overkill. [integer division can get non-integer results, so such results > even cannot be stored in integer arithmetic] > > Internally [storage and arithmetic] the only logical base is 2. > You better use a power of 2. As an example this makes multiplication faster. The usual way to multiplicate 2 numbers is to multiplicate each digit of one number with each digit of the other one. Assume you have to multiplicate two 60 bit numbers. Using base 2 you'll have 60 * 60 = 3600 "digit multipications". Using base 32768 = 2 ^ 15 you'll have only 4 * 4 = 16 "digit multipications". -- wzwz.de/mail
[toc] | [prev] | [next] | [standalone]
| From | "Evertjan." <exxjxw.hannivoort@inter.nl.net> |
|---|---|
| Date | 2015-05-04 21:56 +0200 |
| Message-ID | <XnsA490DF2F34167eejj99@194.109.133.246> |
| In reply to | #27501 |
wolfgang zeidler <invalid@invalid.invalid> wrote on 04 mei 2015 in comp.lang.javascript: >> Internally [storage and arithmetic] the only logical base is 2. >> > > You better use a power of 2. > > As an example this makes multiplication faster. > > The usual way to multiplicate 2 numbers is to multiplicate > each digit of one number with each digit of the other one. > > Assume you have to multiplicate two 60 bit numbers. > > Using base 2 you'll have 60 * 60 = 3600 "digit multipications". > > Using base 32768 = 2 ^ 15 you'll have > only 4 * 4 = 16 "digit multipications". That is internal to the multiplication method black mox. Like in present day ram-memory storage in multiples of 8 bits is more efficient, but that should be internal to the storage methods. Perhaps using present day microcode some special embedded code can be very efficient and the programmer should be aware of that, like he should be aware of parallel execution in multicore processors and prefetching of memory-values on a probablistic theory. However in general terms, binary is the preferred way of storing en computing at the moment, and doing those WITH JAVASCRIPT in variable bases is ludicrous. Making input and output conversion algoritms are quite interesting and feasable, but let us keep that apart from storage and operator functions. -- Evertjan. The Netherlands. (Please change the x'es to dots in my emailaddress)
[toc] | [prev] | [next] | [standalone]
| From | jonas.thornvall@gmail.com |
|---|---|
| Date | 2015-05-04 13:21 -0700 |
| Message-ID | <54c66a90-3fd8-4636-abec-26a2c299c316@googlegroups.com> |
| In reply to | #27505 |
Den måndag 4 maj 2015 kl. 21:56:26 UTC+2 skrev Evertjan.: > wolfgang zeidler <invalid@invalid.invalid> wrote on 04 mei 2015 in > comp.lang.javascript: > > >> Internally [storage and arithmetic] the only logical base is 2. > >> > > > > You better use a power of 2. > > > > As an example this makes multiplication faster. > > > > The usual way to multiplicate 2 numbers is to multiplicate > > each digit of one number with each digit of the other one. > > > > Assume you have to multiplicate two 60 bit numbers. > > > > Using base 2 you'll have 60 * 60 = 3600 "digit multipications". > > > > Using base 32768 = 2 ^ 15 you'll have > > only 4 * 4 = 16 "digit multipications". > > That is internal to the multiplication method black mox. > > Like in present day ram-memory storage in multiples of 8 bits is more > efficient, but that should be internal to the storage methods. > > Perhaps using present day microcode some special embedded code can be very > efficient and the programmer should be aware of that, like he should be > aware of parallel execution in multicore processors and prefetching of > memory-values on a probablistic theory. > > However in general terms, binary is the preferred way of storing en > computing at the moment, and doing those WITH JAVASCRIPT in variable bases > is ludicrous. > > Making input and output conversion algoritms are quite interesting and > feasable, but let us keep that apart from storage and operator functions. > > -- > Evertjan. > The Netherlands. > (Please change the x'es to dots in my emailaddress) Well i Think i will go on from here doing the coding without wining because the benefits are minimal. I do realise though that my coding style is not really easy to interpretate. I will however post links to the advancements as posted to FTP site. But if someone Think my endless posting of codebugs do benefit their understanding do not hesitate to cheer me from going on. I would though appreciate help with my coding, because i know there are Bright people here. Far better programmers than i ever could be, that have no problem understand my code whatsoever. I just need some help avoiding the most obvious bugs and implementing the ideas.
[toc] | [prev] | [next] | [standalone]
| From | wolfgang zeidler <invalid@invalid.invalid> |
|---|---|
| Date | 2015-05-04 22:38 +0200 |
| Message-ID | <mi8lbl$3i8$1@news.m-online.net> |
| In reply to | #27505 |
Evertjan. wrote: > wolfgang zeidler <invalid@invalid.invalid> wrote on 04 mei 2015 in > comp.lang.javascript: > >>> Internally [storage and arithmetic] the only logical base is 2. >>> >> >> You better use a power of 2. >> >> As an example this makes multiplication faster. >> >> The usual way to multiplicate 2 numbers is to multiplicate >> each digit of one number with each digit of the other one. >> >> Assume you have to multiplicate two 60 bit numbers. >> >> Using base 2 you'll have 60 * 60 = 3600 "digit multipications". >> >> Using base 32768 = 2 ^ 15 you'll have >> only 4 * 4 = 16 "digit multipications". > > That is internal to the multiplication method black mox. > > Like in present day ram-memory storage in multiples of 8 bits is more > efficient, but that should be internal to the storage methods. > > Perhaps using present day microcode some special embedded code can be very > efficient and the programmer should be aware of that, like he should be > aware of parallel execution in multicore processors and prefetching of > memory-values on a probablistic theory. > > However in general terms, binary is the preferred way of storing en > computing at the moment, and doing those WITH JAVASCRIPT in variable bases > is ludicrous. > So we agree that calculation should be done in only one base, ( only base 2 ) xor ( only base 16 ) xor ( only base 256 ) xor ... Some time ago I wrote a programm including big integer calculation and I found out that base 2^15 is much faster then base 2. Likely base 2^16 would also work correct, but I was too lazy to check this. > Making input and output conversion algoritms are quite interesting and > feasable, but let us keep that apart from storage and operator functions. > -- wzwz.de/mail
[toc] | [prev] | [next] | [standalone]
| From | "Evertjan." <exxjxw.hannivoort@inter.nl.net> |
|---|---|
| Date | 2015-05-04 22:46 +0200 |
| Message-ID | <XnsA490E7C0E4EF3eejj99@194.109.133.246> |
| In reply to | #27510 |
wolfgang zeidler <invalid@invalid.invalid> wrote on 04 mei 2015 in comp.lang.javascript: > So we agree that calculation should be done in only one base, > ( only base 2 ) xor ( only base 16 ) xor ( only base 256 ) xor ... That was my point all along. > Some time ago I wrote a programm including big integer calculation > and I found out that base 2^15 is much faster then base 2. However, that is not the variable base system the OP wants to construct. In digital arythmetic, 2^15 is just binary arythmetic, where you take a number of characters together to speed things up, like you would do in decimal notation using chups of 3 characters [thousands]. In the worls of microcode, this is mostly hardware-dependant. > Likely base 2^16 would also work correct, but I was too lazy to check this. There is no question that correct code will work correctly in any form. That is why it is called correct code. In Javascript 2^32 comes to mind, in which case you can use much of the internal engine. -- Evertjan. The Netherlands. (Please change the x'es to dots in my emailaddress)
[toc] | [prev] | [next] | [standalone]
| From | "Christoph M. Becker" <cmbecker69@arcor.de> |
|---|---|
| Date | 2015-05-04 22:57 +0200 |
| Message-ID | <mi8mff$42k$1@solani.org> |
| In reply to | #27515 |
Evertjan. wrote: > wolfgang zeidler <invalid@invalid.invalid> wrote on 04 mei 2015 in > comp.lang.javascript: > >> Likely base 2^16 would also work correct, but I was too lazy to check > this. > > There is no question that correct code will work correctly in any form. > That is why it is called correct code. > > In Javascript 2^32 comes to mind, in which case you can use much of the > internal engine. Consider that conforming ES implementations are not required to do any integer arithmetic. -- Christoph M. Becker
[toc] | [prev] | [next] | [standalone]
| From | "Evertjan." <exxjxw.hannivoort@inter.nl.net> |
|---|---|
| Date | 2015-05-04 23:17 +0200 |
| Message-ID | <XnsA490ECE3012F5eejj99@194.109.133.246> |
| In reply to | #27518 |
"Christoph M. Becker" <cmbecker69@arcor.de> wrote on 04 mei 2015 in comp.lang.javascript: >> In Javascript 2^32 comes to mind, in which case you can use much of the >> internal engine. > > Consider that conforming ES implementations are not required to do any > integer arithmetic. Indeed, but Javascript is both the topic of this NG and that of this thread, as started by the OP. [I vagely remember all threads ever were started by the OP, but this one is also mainly responded to by the same.] -- 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-05-05 00:45 +0100 |
| Message-ID | <87r3qvdgrh.fsf@bsb.me.uk> |
| In reply to | #27518 |
"Christoph M. Becker" <cmbecker69@arcor.de> writes: > Evertjan. wrote: > >> wolfgang zeidler <invalid@invalid.invalid> wrote on 04 mei 2015 in >> comp.lang.javascript: >> >>> Likely base 2^16 would also work correct, but I was too lazy to check >> this. >> >> There is no question that correct code will work correctly in any form. >> That is why it is called correct code. >> >> In Javascript 2^32 comes to mind, in which case you can use much of the >> internal engine. > > Consider that conforming ES implementations are not required to do any > integer arithmetic. They are, however, required to perform a large set of calculations exactly. These include many calculations involving integers which have exact floating point representations. I phrase it like this because I'm not exactly sure what you meant, but the end result is that ES appears to do integer arithmetic for a certain range of values. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Christoph M. Becker" <cmbecker69@arcor.de> |
|---|---|
| Date | 2015-05-06 00:01 +0200 |
| Message-ID | <mibej7$54q$1@solani.org> |
| In reply to | #27529 |
Ben Bacarisse wrote: > "Christoph M. Becker" <cmbecker69@arcor.de> writes: > >> Evertjan. wrote: >> >>> In Javascript 2^32 comes to mind, in which case you can use much of the >>> internal engine. >> >> Consider that conforming ES implementations are not required to do any >> integer arithmetic. > > They are, however, required to perform a large set of calculations > exactly. These include many calculations involving integers which have > exact floating point representations. > > I phrase it like this because I'm not exactly sure what you meant, but > the end result is that ES appears to do integer arithmetic for a certain > range of values. I was referring to the potential mistake to think of integer artihmetic (+, -, *, /) in ES conforming implementations as being real integer arithmetic on 32bit values. With IEEE 754 doubles one could use a larger range. On further consideration, however, it might be interesting with regard to the OP's problem to consider asm.js which provides real integer arithmetic and efficient integer arrays. -- Christoph M. Becker
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2015-05-05 08:14 +0200 |
| Message-ID | <3644640.NRzihMUj1S@PointedEars.de> |
| In reply to | #27518 |
Christoph M. Becker wrote: > Evertjan. wrote: >> In Javascript 2^32 comes to mind, in which case you can use much of the >> internal engine. > > Consider that conforming ES implementations are not required to do any > integer arithmetic. Untrue. Read, for example, <http://ecma-international.org/ecma-262/5.1/#sec-9.4> pp. and find the operations that use them. That does not support the original statement, though, mainly because there still is no “Javascript” programming language, and there are several languages, as you implied correctly, several ECMAScript implementations, that bear the “JavaScript” name. -- 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 | "Christoph M. Becker" <cmbecker69@arcor.de> |
|---|---|
| Date | 2015-05-05 23:54 +0200 |
| Message-ID | <mibe61$3mp$1@solani.org> |
| In reply to | #27535 |
Thomas 'PointedEars' Lahn wrote: > Christoph M. Becker wrote: > >> Evertjan. wrote: >>> In Javascript 2^32 comes to mind, in which case you can use much of the >>> internal engine. >> >> Consider that conforming ES implementations are not required to do any >> integer arithmetic. > > Untrue. Read, for example, > <http://ecma-international.org/ecma-262/5.1/#sec-9.4> pp. and find the > operations that use them. Of course, you're right. I meant to refer to the basic arithmethic operations, i.e. the multiplicative[1] and additive[2] operators, which do not involve ToInteger operations. [1] <http://ecma-international.org/ecma-262/5.1/#sec-11.5> [2] <http://ecma-international.org/ecma-262/5.1/#sec-11.6> -- Christoph M. Becker
[toc] | [prev] | [next] | [standalone]
| From | wolfgang zeidler <invalid@invalid.invalid> |
|---|---|
| Date | 2015-05-04 23:18 +0200 |
| Message-ID | <mi8no0$7jr$1@news.m-online.net> |
| In reply to | #27515 |
Evertjan. wrote: > wolfgang zeidler <invalid@invalid.invalid> wrote on 04 mei 2015 in > comp.lang.javascript: > >> So we agree that calculation should be done in only one base, >> ( only base 2 ) xor ( only base 16 ) xor ( only base 256 ) xor ... > > That was my point all along. > ;-) >> Some time ago I wrote a programm including big integer calculation >> and I found out that base 2^15 is much faster then base 2. > > However, that is not the variable base system the OP wants to construct. > Yes, I fear that's the problem, we can't convience the OP. > In digital arythmetic, 2^15 is just binary arythmetic, where you take a > number of characters together to speed things up, like you would do in > decimal notation using chups of 3 characters [thousands]. > > In the worls of microcode, this is mostly hardware-dependant. > ACK. But in the case of JavaScript 32 bit should be warranted for safe (signed) arithmetic and bit ( & >> | << ) operation not depending on hardware. >> Likely base 2^16 would also work correct, but I was too lazy to check > this. > > There is no question that correct code will work correctly in any form. > That is why it is called correct code. > > In Javascript 2^32 comes to mind, in which case you can use much of the > internal engine. > That's the reason why I used base 2^15, multiplication of 2 n-bit-digits may result in a 2*n-bit-value. Why 2^15 and not 2^16? I was unsure wheather signed (!) arithmetic would always works correct in my implementation (likely they would) and the speed difference between 15 and 16 isn't huge. -- wzwz.de/mail
[toc] | [prev] | [next] | [standalone]
| From | "Evertjan." <exxjxw.hannivoort@inter.nl.net> |
|---|---|
| Date | 2015-05-04 23:53 +0200 |
| Message-ID | <XnsA490F31B3279Deejj99@194.109.133.246> |
| In reply to | #27522 |
wolfgang zeidler <invalid@invalid.invalid> wrote on 04 mei 2015 in comp.lang.javascript: > Why 2^15 and not 2^16? > I was unsure wheather signed (!) arithmetic would always works correct > in my implementation (likely they would) and the speed difference > between 15 and 16 isn't huge. Perhaps this 2^32 * 5ms overflow bug in all Boeing 787s would interest you: "We have been advised by Boeing of an issue identified during laboratory testing. The software counter internal to the generator control units (GCUs) will overflow after 248 days of continuous power, causing that GCU to go into failsafe mode. If the four main GCUs (associated with the engine mounted generators) were powered up at the same time, after 248 days of continuous power, all four GCUs will go into failsafe mode at the same time, resulting in a loss of all AC electrical power regardless of flight phase." <http://ad.easa.europa.eu/blob/20150907.pdf/AD_US-2015-09-07_1> 2^32 * 5ms = 21,427,200,000 ms = 248.551348 days. Just ask Google "2^32 * 5 ms in days" -- Evertjan. The Netherlands. (Please change the x'es to dots in my emailaddress)
[toc] | [prev] | [next] | [standalone]
| From | jonas.thornvall@gmail.com |
|---|---|
| Date | 2015-05-04 16:06 -0700 |
| Message-ID | <ee716edd-1a17-4ccf-9e94-8ad4cb1e6109@googlegroups.com> |
| In reply to | #27525 |
Den måndag 4 maj 2015 kl. 23:53:56 UTC+2 skrev Evertjan.: > wolfgang zeidler <invalid@invalid.invalid> wrote on 04 mei 2015 in > comp.lang.javascript: > > > Why 2^15 and not 2^16? > > I was unsure wheather signed (!) arithmetic would always works correct > > in my implementation (likely they would) and the speed difference > > between 15 and 16 isn't huge. > > Perhaps this 2^32 * 5ms overflow bug in all Boeing 787s would interest you: > > "We have been advised by Boeing of an issue identified during laboratory > testing. The software counter internal to the generator control units (GCUs) > will overflow after 248 days of continuous power, causing that GCU to go > into failsafe mode. If the four main GCUs (associated with the engine > mounted generators) were powered up at the same time, after 248 days of > continuous power, all four GCUs will go into failsafe mode at the same time, > resulting in a loss of all AC electrical power regardless of flight phase." > > <http://ad.easa.europa.eu/blob/20150907.pdf/AD_US-2015-09-07_1> > > 2^32 * 5ms = 21,427,200,000 ms = 248.551348 days. > > Just ask Google "2^32 * 5 ms in days" > > -- > Evertjan. > The Netherlands. > (Please change the x'es to dots in my emailaddress) I will give you something to ponder about Evertjan, every number can be written as the sum of four Squares. And you do acknowledge we do not have to use the Squares themself we can use the Sqrt to identify them?
[toc] | [prev] | [next] | [standalone]
| From | "Evertjan." <exxjxw.hannivoort@inter.nl.net> |
|---|---|
| Date | 2015-05-05 10:26 +0200 |
| Message-ID | <XnsA4916A4184DDDeejj99@194.109.133.246> |
| In reply to | #27527 |
jonas.thornvall@gmail.com wrote on 05 mei 2015 in comp.lang.javascript: >> 2^32 * 5ms = 21,427,200,000 ms = 248.551348 days. >> >> Just ask Google "2^32 * 5 ms in days" > > I will give you something to ponder about Evertjan, every number can be > written as the sum of four Squares. So what, you are not giving me totally off topic tasks. Why should I ponder about Evertjan, btw? > And you do acknowledge we do not have to use the Squares themself we can > use the Sqrt to identify them? Do you acknowledge not having to clean your shoes when entering a classroom? Why should "we" want to identify something? -- Evertjan. The Netherlands. (Please change the x'es to dots in my emailaddress)
[toc] | [prev] | [next] | [standalone]
| From | Dr J R Stockton <reply1500@merlyn.demon.co.uk.invalid> |
|---|---|
| Date | 2015-05-05 19:59 +0100 |
| Message-ID | <F1w5mZcAMRSVFws9@invalid.uk.co.demon.merlyn.invalid> |
| In reply to | #27525 |
In comp.lang.javascript message <XnsA490F31B3279Deejj99@194.109.133.246> , Mon, 4 May 2015 23:53:53, Evertjan. <exxjxw.hannivoort@inter.nl.net> posted: >2^32 * 5ms = 21,427,200,000 ms = 248.551348 days. > >Just ask Google "2^32 * 5 ms in days" So you have perhaps not been reading news:comp.lang.javascript, in which it has already been observed that 248+ days is when a signed 32-bit count of centiseconds will overflow. Also, 248+ days has been in my critdate.htm#CPs for many years, AFAIR. And 205057074096000 years is also special. -- (c) John Stockton, nr London, UK. E-mail, see Home Page. Turnpike v6.05. Website <http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms PAS EXE etc. : <http://www.merlyn.demon.co.uk/programs/> - see in 00index.htm Dates - miscdate.htm estrdate.htm js-dates.htm pas-time.htm critdate.htm etc.
[toc] | [prev] | [next] | [standalone]
| From | jonas.thornvall@gmail.com |
|---|---|
| Date | 2015-05-04 07:40 -0700 |
| Message-ID | <308b20cc-7c68-4828-badd-5213ef2107b3@googlegroups.com> |
| In reply to | #27483 |
Den måndag 4 maj 2015 kl. 16:28:09 UTC+2 skrev Ben Bacarisse: > jonas.thornvall@gmail.com writes: > > > Den måndag 4 maj 2015 kl. 15:01:44 UTC+2 skrev Ben Bacarisse: > >> jonas.thornvall@gmail.com writes: > >> <snip> > >> > This is only an outline / pseudocoe for how the base conversion would > >> > look with bignumb implementation will look. You have to check the > >> > arrays so they contain intergers and not chars, that is probably what > >> > fail in first loop. > >> > >> There is no value in using a bugnum for the base in a bignum > >> implementation. This whole part of the project is a waste of time > >> (unless you just want learn ECMAScript programming but that seems > >> unlikely). > > > > I can see that the implementation faster multiplying in base 2048 > > rather than base 2, although it right now cause overflows if number > > outside integer scope for all bases other than 10. > > I can't follow this. There is nothing to follow i say the higher base my implementation use the faster arithmetic. Of course it could be due to my implementation, but it isn't it is due to the weight of the digiplaces. > > I will fix that though, and that it will becom apparent when > > multiplying big numbers which approach is faster. > > > > Binary base or bignumb base. > > > > That is a fact. > > What is a fact? Do you think that using a base that is itself a bignum > will help in some way? > > -- > Ben.
[toc] | [prev] | [next] | [standalone]
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
Back to top | Article view | comp.lang.javascript
csiph-web