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[i];
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[i];
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[i];
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[i];
a = a * b;
}

However possibly
a = a * b;
could loose presision?
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[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 :)

be******@gmail.com wrote:

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[i];
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[i];
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?

--
http://www.hunlock.com -- Musings in Javascript, CSS.
$FA

[VK]

On Feb 7, 7:40 pm, [e-mail] wrote:

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[i];
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[i];
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....avascript/msg/
3833df1762d81fee>

[Dr J R Stockton]

In comp.lang.javascript message <Xn*******************@194.109.133.242>,
Wed, 7 Feb 2007 16:52:49, Evertjan. <ex**************@interxnl.net>
posted:

>

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.

--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/- FAQqish topics, acronyms & links;
Astro stuff via astron-1.htm, gravity0.htm ; quotings.htm, pascal.htm, etc.
L3 is not as far out as some have said.

[Richard Cornford]

On Feb 7, 4:40 pm, [e-mail] wrote:

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[i];
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[i];
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[i]);
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]

On Feb 8, 4:53 pm, "Richard Cornford" <[e-mail]>
wrote:

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[i];
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]

In article <11**********************@a75g2000cwd.googlegroups .com>, VK
<sc**********@yahoo.comwrites

<snip>

>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
--
John Harris

[Dr J R Stockton]

In comp.lang.javascript message <11**********************@v45g2000cwv.go
oglegroups.com>, Thu, 8 Feb 2007 05:53:59, Richard Cornford
<Ri*****@litotes.demon.co.ukposted:

>
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.034999999999999920063942226988729089498519897460 9375
?
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.

--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk DOS 3.3, 6.20; WinXP.
Web <URL:http://www.merlyn.demon.co.uk/- FAQqish topics, acronyms & links.
PAS EXE TXT ZIP via <URL:http://www.merlyn.demon.co.uk/programs/00index.htm>
My DOS <URL:http://www.merlyn.demon.co.uk/batfiles.htm- also batprogs.htm.

[VK]

On Feb 9, 1:34 am, Dr J R Stockton <[e-mail]>
wrote:

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.htmldoing 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 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FF
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]

In article <11**********************@v33g2000cwv.googlegroups .com>, VK
<sc**********@yahoo.comwrites

>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.

<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.

>a javascript number is only 56 bits long.

<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
--
John Harris

[Dr J R Stockton]

In comp.lang.javascript message <11**********************@m58g2000cwm.go
oglegroups.com>, Fri, 9 Feb 2007 08:41:48, VK <sc**********@yahoo.com>
posted:

>On Feb 9, 1:34 am, Dr J R Stockton <[e-mail]>
wrote:

>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

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.htmldoing 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.

--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 IE 6
news:comp.lang.javascript FAQ <URL:http://www.jibbering.com/faq/index.html>.
<URL:http://www.merlyn.demon.co.uk/js-index.htmjscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/TP/BP/Delphi/jscr/&c, FAQ items, links.

[Richard Cornford]

VK wrote:

On Feb 8, 4:53 pm, Richard Cornford wrote:

>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.

<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....7a1607e71be9fa

>

- 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....20fbcd4b4ab7f8

>

- where data storage became data mangling, but your testing skills failed
to identify that obvious flaw.

<URL:
http://groups.google.com/group/comp....536fb8aa09a734

>

- 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....c2f69c6d9004ba

>

And most recently there was rounding string representations of numbers:-

<URL:
http://groups.google.com/group/comp....869add6d8dfcad

>

- 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" <[e-mail]>
wrote:

<snip crap>

(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, 8:01 pm, "VK" <[e-mail]:

On Feb 11, 4:01 pm, "Richard Cornford" <[e-mail]>
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
[sc**********@yahoo.com] - 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" <[e-mail]>
wrote:

<snip crap>

>(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 ;-)

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
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Randy Webb]

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

On Feb 11, 8:01 pm, "VK" <[e-mail]:

>On Feb 11, 4:01 pm, "Richard Cornford" <[e-mail]>
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.

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

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Richard Cornford]

VK wrote:

On Feb 11, 8:01 pm, "VK" <sc**********@yahoo.comwrote:

>On Feb 11, 4:01 pm, Richard Cornford wrote:
<snip crap>

From the other side I'm a bit

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 ...

<snip>

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".

<snip>

... . 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.

[Richard Cornford]

VK <sc**********@yahoo.comwrote:

On Feb 11, 4:01 pm, Richard Cornford wrote:
<snip crap>

The point of posting references to examples of your code that demonstrate
you making basic mistakes that no programmer would ever make was to
render my assertion that you are no programmer objective. Anyone who
cares to can take a look and see for themselves that you really don't
understand what you are attempting to do. Your delusion prevent you from
seeing that simple truth for yourself, but others may appreciate being
put in the picture.

>(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

It is not as trivial as the code needed to round representations of
numbers in string form, and you spectacularly failed at that when you
tried:-

<URL:
http://groups.google.com/group/comp....869add6d8dfcad

>

- 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".

Nonsense. You don't have the considerations of a specific application of
rounding to worry about. So just make a decision, state what the
decisions was and implement it.

I really hope to find some time this week.

I don't expect anyone will be holding their breath.

Richard.

[VK]

Self-correction:

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".

Still over-simplified IMO. Mantissa (aka significand aka coefficient)
phisically takes 52 bits no matter what. But in normalized form the
radix point is put after the first non-zero digit, like 150 would be
1.5 * 10^2. But in base two the only possible non-zero digit is 1.
Whis allows to optimize the storage space by storing only the part
after the radix point with 1. part always assumed ("implicit bit").
Denormalized numbers override the meaning of the implicit bit by
setting the exponent to all zeros.
So OK: mantissa has 52 physical bit of storage space and one "virtual"
bit provided over IEEE-754 algorithm, this way 53 bits in total are
used in operations.

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

}

The given explanation doesn't seem satisfactory anymore. I'll try MSDN
support first. With some luck I may get a useful answer instead of the
regular bot's "Thank-you-for-your-interest-blah-blah-get-off-
sucka'" :-)

[Richard Cornford]

"VK" <sc**********@yahoo.comwrote:

Self-correction:

>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".

Still over-simplified IMO.

Inarticulate gibberish in mine.

Mantissa (aka significand aka coefficient) phisically takes
52 bits no matter what. But in normalized form the radix point
is put after the first non-zero digit, like 150 would be
1.5 * 10^2. But in base two the only possible non-zero digit
is 1. Whis allows to optimize the storage space by storing only
the part after the radix point with 1. part always assumed
("implicit bit").

What would be the point of attempting to "optimise the storage space"?
You would need to store extra information to explain the meaning of the
bits stored (increasing the space required in many cases) and the
overheads in converting any other form stored into the bit pattern
expected by the FPU would be counter-productive.

Denormalized numbers override the meaning of the implicit bit
by setting the exponent to all zeros.
So OK: mantissa has 52 physical bit of storage space and one
"virtual" bit provided over IEEE-754 algorithm, this way 53
bits in total are used in operations.

<snip>

It is incredible. You will go off and concoct the most fantastic
explanations for the simplest things.

IEEE double precision floating point numbers can represent all integers
in the range +(2 to the power of 53) to -(2 to the power of 53)
(including both +0 and -0).

In the same way as 3 bits can represent integers from zero to ((2 to the
power of 2) + (2 to the power of 1) + (2 to the power of 0), or 7 (== 4 +
2 + 1), 52 bits can represent numbers from zero to ((2 to the power of
52) + (2 to the power of 51) + (2 to the power of 50) + ... + (2 to the
power of 1) + (2 to the power of 0), or 9007199254740991 (===
4503599627370496 + 2251799813685248 + 1125899906842624 + ... + 2 + 1).

The next number in a continuous sequence of integers is (2 to the power
of 53) and while it cannot be represented with 52 bits it happens to be
((2 to the power of 52) * 2), or (4503599627370496 * 2). So when you have
a binary exponent you can achieve ((2 to the power of 52) * 2) by taking
the representation of (2 to the power of 52) and adding one to its
exponent. The result is still precise in the same way as (1 * (10 to the
power of 2)), or 10e2, is precisely 100.

This characteristic of mantissa + exponent representations of numbers may
be illustrated with a very simplified example. Suppose a number is to be
represented by a one decimal digit mantissa and a one decimal digit
exponent, both are signed and the decimal digit is assumed to be to the
left of the exponent digit. Thus:-

+1e+0 [or, +0.1 * (10 to the power of 0)] is the number +0.1
+1e+1 [or, +0.1 * (10 to the power of 1)] is the number +10
+2e-2 [or, +0.2 * (10 to the power of -2)] is the number +0.002
- and so on

The range of the continuous sequence of integers that can be represented
with such a format is 10 to -10, but the mantissa can only accommodate
the digits 0 to 9. Where 9 is +9e+1 and -9 is -9e+1

-9e+1 == 9
-8e+1 == 8
-7e+1 == 7
-6e+1 == 6
-5e+1 == 5
-4e+1 == 4
-3e+1 == 3
-2e+1 == 2
-1e+1 == 1
+0e+1 == 0
-1e+1 == -1
-2e+1 == -2
-3e+1 == -3
-4e+1 == -4
-5e+1 == -5
-6e+1 == -6
-7e+1 == -7
-8e+1 == -8
-9e+1 == -9

- but the continuous sequence of integers that can be represented can be
extended beyond that which can be accommodated in the mantissa because
+10 and -10 (the next steps in either direction) can be represented as
+1e+2 and -1e+2 respectively.

The next integers in the possible sequence, +11 and -11, cannot be
represented in this format at all, and the next integers greater than +10
and less than -10 that can be represented are +20 and -20 respectively.
The nearest available number to +11 in this number representation is +10.

And that is how it is with IEEE double precision floating-point numbers
also; ((2 to the power of 53) + 1) cannot be represented at all. Instead
it is approximated to the nearest number that can be represented, which
is (2 to the power or 53). And so the continuous sequence of integers
that can be represented comes to an end at (2 to the power of 53).

Richard.

[Richard Cornford]

Richard Cornford wrote:
<snip>

The result is still precise in the same way as (1 * (10 to the
power of 2)), or 10e2, is precisely 100.

^^^^
Should be 1e2

<snip>

+1e+1 [or, +0.1 * (10 to the power of 1)] is the number +10

<snip ^^^

Should be +1

Richard.

[Richard Cornford]

Richard Cornford wrote:
<snip>

... and the decimal digit is assumed to be to the left of the exponent

<snip ^^^^^ ^^^^^^^^

- and that should be "decimal point" and "left of the mantissa".

Richard.

[VK]

Denormalized numbers override the meaning of the implicit bit

by setting the exponent to all zeros.
So OK: mantissa has 52 physical bit of storage space and one
"virtual" bit provided over IEEE-754 algorithm, this way 53
bits in total are used in operations.

<snip>

It is incredible. You will go off and concoct the most fantastic
explanations for the simplest things.

IEEE double precision floating point numbers can represent all integers
in the range +(2 to the power of 53) to -(2 to the power of 53)
(including both +0 and -0).

Nice try, but still long way to go. Your homework to do - do not
worry, I'm still doing mine as well though this part is passed for me
-

1) What is "integer number" and "mantissa" and how do they correlate?

2) What is the algorithm difference for resolving IEEE-754 DP-FP
numbers like ( S E F sequence)
0 00000000000 100...0
and
0 00000000001 100...0
Note: the question is not about the stored values, but about the
resolving algorithm change.
Hint: what are normalized numbers, denormalized numbers and assumed
leading 1 (aka implicit bit) in IEEE-754 ?

3) What kind of number zero (0) is in IEEE-754?

4) Can be zero (0) represented exactly in IEEE-754?
Hint: Why not?

[Isaac Schlueter]

On Feb 8, 11:14 am, Lee <[e-mail]:

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.

That's why we had to memorize the sizeof() results from the type table
in my CSC 110 class in college :)

--i

[Randy Webb]

VK said the following on 2/12/2007 1:49 PM:

Self-correction:

>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".

Still over-simplified IMO.

It could be as simplified as possible and you would still f**k it up.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Dr J R Stockton]

In comp.lang.javascript message <11*********************@s48g2000cws.goo
glegroups.com>, Mon, 12 Feb 2007 10:49:27, VK <sc**********@yahoo.com>
posted:

>The given explanation doesn't seem satisfactory anymore. I'll try MSDN
support first. With some luck I may get a useful answer instead of the
regular bot's "Thank-you-for-your-interest-blah-blah-get-off-
sucka'" :-)

Did you want an accurate answer, or something that you can understand?

How's your rounding code doing? fit for use yet?

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

--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 IE 6
news:comp.lang.javascript FAQ <URL:http://www.jibbering.com/faq/index.html>.
<URL:http://www.merlyn.demon.co.uk/js-index.htmjscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/TP/BP/Delphi/jscr/&c, FAQ items, links.