complex calculation, possible?

[beach.dk]

Hi,

I'm trying to implement a simple hash algorith called rs_hash in
javascript,
but I cannot get a correct result.

In c the code looks like this:



signed char myArray[6];

myArray[0]= 0x01;
myArray[1]= 0x02;
myArray[2]= 0x03;
myArray[3]= 0x04;
myArray[4]= 0x05;
myArray[5]= 0x06;

signed int b = 378551;
signed int a = 63689;
signed int hash = 0;
int i= 0;
int len= 6;

for( i= 0; i<len; i++ )
{
hash = hash * a + myArray;
a = a * b;
}

return hash;


and my try in javascripts looks like this


var myArray = new Array();

myArray[0] = 0x01;
myArray[1] = 0x02;
myArray[2] = 0x03;
myArray[3] = 0x04;
myArray[4] = 0x05;
myArray[5] = 0x06;

var b = 378551;
var a = 63689;
var hash = 0;
var i = 0;
var len= 6;

for( i== 0; i<len; i++)
{
hash = hash * a + myArray;
a = a * b;
}

return hash;




The c functions returns -1596271655 (2698695641 when casted to
unsigned)
while the the javacsript funtion returns 4.922527108004972e+107

I guess this has to do with the fact that javascript has typeless
variables, but is there a way to
cast them to signed integers?

I tried casting some variables
var b = parseInt('378551');
var a = parseInt('63689');
var hash = parseInt('0');

but this didn't help. My some out there can?

 

[Evertjan.]

wrote on 07 feb 2007 in comp.lang.javascript:

for( i== 0; i<len; i++)
{
hash = hash * a + myArray;
a = a * b;
}

return hash;

The c functions returns -1596271655 (2698695641 when casted to
unsigned)
while the the javacsript funtion returns 4.922527108004972e+107

I guess this has to do with the fact that javascript has typeless
variables, but is there a way to
cast them to signed integers?

I tried casting some variables
var b = parseInt('378551');
var a = parseInt('63689');
var hash = parseInt('0');

but this didn't help. My some out there can?

var b = parseInt('378551');
or
var b = 378551;
That would not help, as it does not change the type of the variable:


The best you can do is do a Math.floor after every computation,
to keep the results as an integer.
[This is what you should do in C too, methinks, but possibly it is a
default behavour of storing a noninteger float in an integer variable
there.]

for( i== 0; i<len; i++) {
hash = Math.floor(hash * a) + myArray;
a = a * b;
}

However possibly
a = a * b;
could loose presision?

 

[pcx99]

Javascript is reporting the correct result. The C code is producing an
error result. You have a signed int hash which, unless you're working
in a 64 bit environment, is capped at 2 billion. Your code exceeds 2
billion and goes negative which is why C returns a negative number.

Javascript isn't rolling over, it's reporting the actual value of the
algorithm which really is an obscenely long number 107 places to be
more acurate which means the C code is not only rolling over once it is
rolling over MULTIPLE times like a car's odometer if you were to drive
from here to the nearest start -- billions and billions of miles but the
odometer would report some number between 0 and 999,999 miles.

So the question isn't if javascript can do complex calculation, it's can
C do it Well yea it can, but not with a signed int in this case

Hi,

I'm trying to implement a simple hash algorith called rs_hash in
javascript,
but I cannot get a correct result.

In c the code looks like this:



signed char myArray[6];

myArray[0]= 0x01;
myArray[1]= 0x02;
myArray[2]= 0x03;
myArray[3]= 0x04;
myArray[4]= 0x05;
myArray[5]= 0x06;

signed int b = 378551;
signed int a = 63689;
signed int hash = 0;
int i= 0;
int len= 6;

for( i= 0; i<len; i++ )
{
hash = hash * a + myArray;
a = a * b;
}

return hash;


and my try in javascripts looks like this


var myArray = new Array();

myArray[0] = 0x01;
myArray[1] = 0x02;
myArray[2] = 0x03;
myArray[3] = 0x04;
myArray[4] = 0x05;
myArray[5] = 0x06;

var b = 378551;
var a = 63689;
var hash = 0;
var i = 0;
var len= 6;

for( i== 0; i<len; i++)
{
hash = hash * a + myArray;
a = a * b;
}

return hash;




The c functions returns -1596271655 (2698695641 when casted to
unsigned)
while the the javacsript funtion returns 4.922527108004972e+107

I guess this has to do with the fact that javascript has typeless
variables, but is there a way to
cast them to signed integers?

I tried casting some variables
var b = parseInt('378551');
var a = parseInt('63689');
var hash = parseInt('0');

but this didn't help. My some out there can?

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]>,

The best you can do is do a Math.floor after every computation,
to keep the results as an integer.

If the intermediate may be non-integer, is it necessarily too big?
Math.round might be safer.

If the work can be done with 32-bit variables, |0 might be considered.

Quantities of more than 32 bits can be represented as multiple 32-bit
variables.

 

[VK]

Hi,

I'm trying to implement a simple hash algorith called rs_hash in
javascript,
but I cannot get a correct result.

In c the code looks like this:

signed char myArray[6];

myArray[0]= 0x01;
myArray[1]= 0x02;
myArray[2]= 0x03;
myArray[3]= 0x04;
myArray[4]= 0x05;
myArray[5]= 0x06;

signed int b = 378551;
signed int a = 63689;
signed int hash = 0;
int i= 0;
int len= 6;

for( i= 0; i<len; i++ )
{
hash = hash * a + myArray;
a = a * b;
}

return hash;

and my try in javascripts looks like this

var myArray = new Array();

myArray[0] = 0x01;
myArray[1] = 0x02;
myArray[2] = 0x03;
myArray[3] = 0x04;
myArray[4] = 0x05;
myArray[5] = 0x06;

var b = 378551;
var a = 63689;
var hash = 0;
var i = 0;
var len= 6;

for( i== 0; i<len; i++)
{
hash = hash * a + myArray;
a = a * b;
}

return hash;

The c functions returns -1596271655 (2698695641 when casted to
unsigned)
while the the javacsript funtion returns 4.922527108004972e+107

I guess this has to do with the fact that javascript has typeless
variables, but is there a way to
cast them to signed integers?

As it was pointed out, the problem is with your C code, not with
JavaScript.
signed int holds values from -2,147,483,648 to 2,147,483,647 and your
calculations are going way beyond this border. It is called "type
overflow" and the exact error correction is not defined in C language
specifications. It means that depending on particular C/C++ compiler
you may get different results. As I can tell on your current C
compiler type overflow is resolved by simply truncating extra bits, so
from some point your hash = hash * a starts acting as some very fancy/
weird bitwise shift statement. If you are getting the needed results
with it then it is a very lucky coincidence.

In JavaScript all numbers are - at least officially - IEEE-754
floating point double precision, so even after 2,147,483,647 your hash
just keeps growing.

P.S. After you bring your C code into correct form and start porting
in JavaScript, keep in mind some important limits for big integers
summarized in Nielsen's table
<http://groups.google.com/group/comp.lang.javascript/msg/
3833df1762d81fee>

 

[Richard Cornford]

I'm trying to implement a simple hash algorith called rs_hash in
javascript, but I cannot get a correct result.

In c the code looks like this:

signed char myArray[6];

myArray[0]= 0x01;
myArray[1]= 0x02;
myArray[2]= 0x03;
myArray[3]= 0x04;
myArray[4]= 0x05;
myArray[5]= 0x06;

signed int b = 378551;
signed int a = 63689;
signed int hash = 0;
int i= 0;
int len= 6;

for( i= 0; i<len; i++ )
{
hash = hash * a + myArray;
a = a * b;
}

return hash;

and my try in javascripts looks like this

var myArray = new Array();

myArray[0] = 0x01;
myArray[1] = 0x02;
myArray[2] = 0x03;
myArray[3] = 0x04;
myArray[4] = 0x05;
myArray[5] = 0x06;

var b = 378551;
var a = 63689;
var hash = 0;
var i = 0;
var len= 6;

for( i== 0; i<len; i++)
{
hash = hash * a + myArray;
a = a * b;
}

return hash;

The c functions returns -1596271655 (2698695641 when casted to
unsigned)
while the the javacsript funtion returns 4.922527108004972e+107

I guess this has to do with the fact that javascript has typeless
variables, but is there a way to cast them to signed integers?

<snip>

Having type less variable is irrelevant. Your problem is that
javascript uses an IEEE double precision floating point number as its
only numeric type. As a result you cannot "cast" a number to a
different numeric type (there are not other numeric types to "cast" it
to).

On the other hand, the double precision floating point number can
represent all values that can be represented in signed 32 bit integers
with precision.

I tried casting some variables
var b = parseInt('378551');
var a = parseInt('63689');
var hash = parseInt('0');

but this didn't help. My some out there can?

It seems that what you want is to be able to multiply two numeric
values that can be represented as 32 bit signed integers and get the
same result as you would in C; another 32bit signed integer, but
probably the value that would be the lower 4 bytes of the 64 bit
integer that is the result of the multiplication of two 32 bit
integers.

I am reminded of assembly language programming a decade ago where the
CPU in use could do direct multiplication of 16 bit integers to
produce 32 bit results (as a limitation imposed by its registers being
32 bits wide). When you needed to multiply two 32 bit value you would
split them up into 4 16 bit value, do 4 multiplications and then shift
and add the results to get the desired 64 bit result spread across two
registers.

Internally javascript uses signed and unsigned 32 bit value with its
bitwise operations, and it is certainly possible to convert an
arbitrary floating point number into a value that can be represented
as a signed or unsigned 32 bit integer by applying a bit-wise
operation. Given this, and starting with values that can be
represented as signed 32 bit integers, it would be possible to create
a function that took two such values as input, split them up into
their upper and lower 16 bits and then performed the multiplication on
the parts (which must produce a results that can itself be represented
as 32 bit integers), shift and add those results and apply other
appropriate bitwise operations to produce a return value that was in
the range of signed 32 bit integers.

A quick attempt came up with:-

function test(){
var myArray =[
0x01,
0x02,
0x03,
0x04,
0x05,
0x06
];

var b = 378551;
var a = 63689;
var hash = 0;
var i = 0;
var len= 6;

for(i== 0;i<len;++i){
hash = (mul32(hash, a) + myArray);
a = mul32(a, b);
}
return hash;
}

function mul32(a, b){
var aL = (a & 0xFFFF);
var bL = (b & 0xFFFF);
var aH = (a >>> 16);
var bH = (b >>> 16);
return ((((aH * bL) + (bH * aL))<<16) + ((aL * bL)|0))| 0;
}

Which does result in your -1596271655 value when executed, though I
have not tested it in comparison with how C would do multiplication of
32 bit signed integers to give a 32bit signed result.

Richard.

 

[VK]

It seems that what you want is to be able to multiply two numeric
values that can be represented as 32 bit signed integers and get the
same result as you would in C; another 32bit signed integer, but
probably the value that would be the lower 4 bytes of the 64 bit
integer that is the result of the multiplication of two 32 bit
integers.

Actually the OP's question knocked me down a bit... By the style the
question was asked I felt that the C code snippet was something
obvious and meaningful to poster - while it was looking clearly wrong
from any common programming considerations. So I checked it out and I
be damned: there is someone Robert Sedgewick who is a rather famous
programming specialist AFAICT. Among other things he proposed a hash
key calculation algorithm commonly referred as RSHash or rs_hash
algorithm (by the first letters in the name). A pure C-form would be:

unsigned int RSHash(const std::string& str)
{
unsigned int b = 378551;
unsigned int a = 63689;
unsigned int hash = 0;

for(std::size_t i = 0; i < str.length(); i++)
{
hash = hash * a + str;
a = a * b;
}

return (hash & 0x7FFFFFFF);
}

I be damned once again: the entire algorithm is based on intentional
type overflow and engine error correction mechanics. What is going on
in this world?

 

[Lee]

VK said:

I be damned once again: the entire algorithm is based on intentional
type overflow and engine error correction mechanics. What is going on
in this world?

C programmers (used to) do that all the time.
You know without doubt how big "unsigned int" is and that
there isn't any engine to try to correct anything.


--

 

[John G Harris]

I be damned once again: the entire algorithm is based on intentional
type overflow and engine error correction mechanics. What is going on
in this world?

I'd have thought it's obvious what's going on. The whole point of a hash
operation is to turn a long string of various lengths into a short
result with a fixed length. A 32 bit result is a popular value, though
cryptographic hashes tend to be longer, say 20 bytes.

The OP's algorithm relies on anything over the size of an int (e.g 32
bits) being thrown away, so each step needs to finish with a modulo
operation. Unfortunately, the algorithm does hash * a where both hash
and a can be size-of-int long. (hash * a) will lose bits sometimes in
javascript since the integral part of a javascript number is only 56
bits long. As Richard said, the multiplication would have to be split
into parts; two would be sufficient when "ints" are 32 bits long.

John

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]
oglegroups.com>, Thu, 8 Feb 2007 05:53:59, Richard Cornford

Having type less variable is irrelevant. Your problem is that
javascript uses an IEEE double precision floating point number as its
only numeric type. As a result you cannot "cast" a number to a
different numeric type (there are not other numeric types to "cast" it
to).

The tail of that is not really true, except on a strict interpretation
of "cast".

Javascript currently only has one built-in numeric type; but one can use
an array of digits to represent, exactly, numbers with greater
resolution than an IEEE Double can deal with. The standard operators
cannot be used directly, but one can write a function Plus with two
array arguments returning an array representing the sum, etc. etc.

ASIDE : In fact, I've done more or less that in Pascal/Delphi in
LONGCALC (via sig line 3) - it will do integer arithmetic on signed
numbers of up to 65520 digits (99999999 in Delphi) to any base in 2..16,
including swapping bases in mid-stream. Feel free to translate it (with
appropriate attribution) into Javascript; IIRC, it's only about 3000
lines, some blank. Command line "longcalc 99 fac #ge wrt wrt" gives
"+4 +9" showing that Gregorian Easter Sunday of the year 99-factorial
will be April 9th [*].


I've also done a part of that in the code that converts an IEEE Double's
sign+mantissa to an exact decimal string - functions Add() & Halve()
used in <URL:http://www.merlyn.demon.co.uk/js-misc0.htm#DW4> - perhaps
you remember an article saying (not necessarily in those words) that
Number("1.035") = 1.0349999999999999200639422269887290894985198974609375
?


All arithmetic can be done with array-of-Boolean being the only numeric
type.



[*] It should be on the same date for all factorial years from 19! up.
Actually, it's the same in AD 18! and AD 16! and AD 11! which I suspect
of being coincidences.

 

[VK]

Javascript currently only has one built-in numeric type; but one can use
an array of digits to represent, exactly, numbers with greater
resolution than an IEEE Double can deal with. The standard operators
cannot be used directly, but one can write a function Plus with two
array arguments returning an array representing the sum, etc. etc.

Yes, it is called BigMath and there is no need to write it: there is a
number of BigMath libraries written for many languages including
JavaScript, see for instance BigInt library at <http://www.leemon.com/
crypto/BigInt.html> doing lossless RSA in any base up to 95.

The deal is that: BigMath is i) external, ii) string based, iii) hell
expensive, iv) deadly slow if written on higher level languages.

This way saying "numbers in JavaScript" it is safe to assume the
native IEEE-754 double precision floating point - while keeping the
BigMath option in mind for special circumstances.

 

[VK]

I'd have thought it's obvious what's going on. The whole point of a hash

operation is to turn a long string of various lengths into a short
result with a fixed length. A 32 bit result is a popular value, though
cryptographic hashes tend to be longer, say 20 bytes.

I didn't question of "how does it work?" - that is pretty obvious. I
questioned the correctness of an approach based on intentional
overflow tricks. For me it is as "elegant" as say for-loop based on
try-catch block with custom throw. If anyone really wanted to get max
speed by moving on low level bitwise corrections: then write an
assembly chunk called from your C proc. This way no one will ever
wonder what a hey are you doing with poor unsigned - and especially
signed - int.

From the other side JavaScript has enough of its own rware'd topics to

pull C'ish problems atop of it So let's anyone does whatever she's
happy with.

From the practical point of view I see little sense to port RSHash

onto JavaScript - unless for demo and educational purposes. Its
primary strength - max effectiveness over automated unsigned int
overflow correction - becomes its primary weakness in JavaScript with
its IEEE-754 DP-FP (double precision - floating point) numbers. What
comes natural in C original it will require an expensive emulation in
JavaScript variant.

IMHO it would be more beneficial to use hash procs made with
JavaScript in mind.
<http://pajhome.org.uk/crypt/md5/> does MD4, MD5 and SHA-1 with
satisfactory productivity.

Without that stupid IE I would just suggest to use crypto object
methods that are working on source level - so times quicker than top
level js procs:
<http://developer.mozilla.org/en/docs/JavaScript_crypto>
....and then native atob() and btoa() instead of custom base64 codecs -
and the stuff will just fly... but IE holds you like a stone on your
chest.

a javascript number is only 56 bits long.

52 to be exact ;-)
1 bit for sign
11 bits for exponent
52 bits for mantissa
----------------------
64 bits of IEEE-754 DP-FP

S EEEEEEEEEEE FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
0 1 11 12 63

When pushed into corner by big math lovers it may take extra bit
from exponent so with some simplifications - I would be killed for in
Berkley for sure - one can tell "normally 52 bits, sometimes 53 bits".

P.S. JScript uses VBScript math module, and respectively inherits a
bit different denormalized numbers - those 53-bit outlaws I mentioned
just before - production. It allows a unique of its kind math-based
browser sniffing, like:

if (new Number(999999999999999934469).toString().indexOf('e') == -1) {
// Internet Explorer
}
else {
// all others
}

P.P.S. In either case 999999999999999934469 nukes the calculator, so
each engine simply hallucinating after having swallowed it. The trick
is that the hallucinations caused by the probe are different for IE
and other browsers and we are drawing the conclusion from
hallucination records differences. IMO that makes this browser
sniffing as absolutely A-Grade "conceptual" among anything else.

I still consider it as a curiosity and not as practical tool.

 

[John G Harris]

I didn't question of "how does it work?" - that is pretty obvious. I
questioned the correctness of an approach based on intentional
overflow tricks.

<snip>

I'll say it again, using more words.

The OP's algorithm does a big calculation then ends by doing modulo 2^m
to give an m-bit result. m happens to be the number of bits in an
(un)signed integer (this is not a coincidence). m is often 32.

The big calculation uses only + and * operations. It is a property of
modulo that you can do modulo 2^m after any or all stages in this
calculation and still get the same end result.

The C & C++ standards guarantee that doing + or * on unsigned integers
gives the 'proper' value modulo 2^m. This is exactly what's wanted.
(Signed integer arithmetic is allowed to produce hardware interrupts, so
should be avoided).

There is absolutely nothing wrong with the "correctness of an approach
based on intentional overflow tricks". The language standards and the
mathematics guarantee you get the right result.


<snip>

There's a typing error there. 53 bits is the size of integers guaranteed
to be held exactly in a javascript number. You misquoted me : you've
missed out the words that said I wasn't talking about the whole number.


John

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]

Yes, it is called BigMath

No; at least one is called BigMath and you do not know how many others
there are with different names.

and there is no need to write it: there is a
number of BigMath libraries written for many languages including
JavaScript, see for instance BigInt library at <http://www.leemon.com/
crypto/BigInt.html> doing lossless RSA in any base up to 95.

The deal is that: BigMath is i) external, ii) string based, iii) hell
expensive, iv) deadly slow if written on higher level languages.

I EXPLICITLY wrote "array arguments". Access to individual characters
of strings can be much slower than for arrays.

Expensive?

HLL code is not necessarily slow, if done with a good compiler it's
usually about as good as ASM. Fully-interpreted languages are
different. The OP's calculation, as presented, is not that complex; it
won't take long, properly coded in javascript, on a modern machine.

This way saying "numbers in JavaScript" it is safe to assume the
native IEEE-754 double precision floating point - while keeping the
BigMath option in mind for special circumstances.

Yes, we know that's what RC was thinking of. He was not thinking widely
enough - you have often had that experience yourself.

It's a good idea to read the newsgroup and its FAQ. See below.

 

[Richard Cornford]

Actually the OP's question knocked me down a bit... By
the style the question was asked I felt that the C code
snippet was something obvious and meaningful to poster -
while it was looking clearly wrong from any common
programming considerations.

<snip>


You are no programmer, so whatever you may perceive as "common
programming considerations" has little relevance outside of your
deranged mind.

Remember:-

<URL:
http://groups.google.com/group/comp.lang.javascript/msg/1d7a1607e71be9fa
- which received the accolade; "It uses the most bizarre and obtuse
storage method I've ever witnessed, and it uses it inconsistently and
without any obvious benefits.".

And your second attempt at it:-

<URL:
http://groups.google.com/group/comp.lang.javascript/msg/2820fbcd4b4ab7f8
- where data storage became data mangling, but your testing skills failed
to identify that obvious flaw.

<URL:
http://groups.google.com/group/comp.lang.javascript/msg/df536fb8aa09a734
- where you declare your method for testing whether an object is an array
as "absolutely robust" when it is easily fooled, and suffers the very
significant design fault of modifying the length of every array that it
tested. And in the same thread you reveal an incomprehension of the -
delete - operator in javascript:-

<URL:
http://groups.google.com/group/comp.lang.javascript/msg/a2c2f69c6d9004ba
And most recently there was rounding string representations of numbers:-

<URL:
http://groups.google.com/group/comp.lang.javascript/msg/2f869add6d8dfcad
- where asking for two decimal places in the output did not even
guarantee two decimal places in the output, let alone a reasonable
sequence of digits.

(I assume all your hollow promises to create a rounding function that was
superior to the one in the FAQ ended when you either realised that the
task was beyond your skill, or, for once, properly tested the code you
had
written and found it so defective that it would be, yet again,
embarrassing to post it in public.)

I am not interested in talk of "common programming considerations" that
originate with someone who can hardly manage to put 30 lines of code
together into something that even does the job it was claimed to do.

Richard.

 

[VK]

On Feb 11, 4:01 pm, "Richard Cornford" <[email protected]>
wrote:

(I assume all your hollow promises to create a rounding function that was
superior to the one in the FAQ ended when you either realised that the
task was beyond your skill, or, for once, properly tested the code you
had
written and found it so defective that it would be, yet again,
embarrassing to post it in public.)

The last two weeks were very intensive for me, so I had no enough time
for that. As you may guess posting at clj is not my primary job ;-)

The code of this kind by itself is pretty much a trivia - but - clear
answers have to be found for:
1) what rounding rule to make the default one.
2) define exact borders where IEEE-754 DP-FP rounding has sense, so to
say clearly "from here and from here go to hell or use BigMath".

I really hope to find some time this week.

 

[VK]

On Feb 11, 4:01 pm, "Richard Cornford" <[email protected]>
wrote:

<snip crap>

From the other side I'm a bit proud to have personal historiograph on

the Usenet who's collecting all my thoughts throughout the years to
keep them for the next generations.



I'm also proud to be the only one having personal bot marking all my
posts on Google Groups as "Very poor". Nearly 3,000 marks by now (by
the amount of my posts over last two years). As the mark is always
only one and as it comes in lesser than minute after post any time day
or night, it must be a bot. Other option is a group of devoted
individuals working on shift basis over one account.

I never mentioned that - as I don't really care, just came to my mind
by now.

btw if the bot maintainer happens to read this: maybe it's time to add
some AI into program? So far it simply marks anything posted by VK
[[email protected]] - answers and questions all together. Maybe
it would have sense to limit to answers only? Otherwise it is a bit
illogical IMO

- "What is the rounding result of 1.035.toFixed(2) on Safari?"
- "Very poor post".

- "Some nodes are not being removed, why?"
- "Very poor post".

 

[Randy Webb]

VK said the following on 2/11/2007 12:01 PM:

On Feb 11, 4:01 pm, "Richard Cornford" <[email protected]>
wrote:



The last two weeks were very intensive for me, so I had no enough time
for that. As you may guess posting at clj is not my primary job ;-)

Some people would rejoice if it weren't even a hobby.

The code of this kind by itself is pretty much a trivia - but - clear
answers have to be found for:

If it is so "trivia" then why did you fail so miserably at attempting
the trivial?

1) what rounding rule to make the default one.

You couldn't satisfy your own rules, how would you ever manage to
satisfy someone else's?

 

[Randy Webb]

VK said the following on 2/11/2007 2:08 PM:

the Usenet who's collecting all my thoughts throughout the years to
keep them for the next generations.

It's more like protecting the next generation from you.

 

[Richard Cornford]

Why have you placed a ">" character at the beginning of that sentence
when you are using that character to mark quoted text?

proud to have personal historiograph on the Usenet who's
collecting all my thoughts throughout the years to keep
them for the next generations.

You have been, and probably will remain, an object lesson in what not to
do in browser scripting.

I'm also proud to be the only one having personal bot ...

I never mentioned that - as I don't really care, just came
to my mind by now.

It may be your habit whenever you have made an ass of yourself in public
to attempt to distract attention by positing some irrelevance, but please
spare us the things that come to your "mind".

... . Maybe it would have sense to limit to answers only?
Otherwise it is a bit illogical IMO

Your not grasping logic is one of the more self-evident influences on the
code you write.

- "What is the rounding result of 1.035.toFixed(2) on Safari?"
- "Very poor post".

Your not understanding why that question is irrelevant, after it was
explained to you in great detail, is pretty poor.

- "Some nodes are not being removed, why?"
- "Very poor post".

Having claimed to have spent the best part of 10 years 'writing'
javascript not understanding what "live" means in reference to NodeList,
NameNodeMap and HTMLCollection, when they have been around since the late
1990s themselves, is also pretty poor.

Richard.