Re: Disable Drop-box Based On Users Selection
"Dr John Stockton" <spam@merlyn.de mon.co.uk> wrote in message
news:NfdPL9OPSV EAFwKj@merlyn.d emon.co.uk...
<snip>[color=blue][color=green]
>>While I was looking at the handling of numbers for formatting
>>I noticed that IE 4 does not have isNaN and isFinite[/color]
>
>My IE 4 does have them.
>
>Small Flanagan says that isNaN is javascript 1.1 and isFinite is
>js 1.2; and that both are ECMA-262. Also that IE4 & NS4 are js 1.2.[/color]
The core language documentation from Netscape for JS 1.4 states that
isFinite was introduced in 1.3 rather than 1.2 and some JScript
documentation I have states that both were introduced in JScript 5.
Though the MSDN site says versions 1 and 3 respectively. I am not sure
if I trust any of them. But, as Jim pointed out, it is unlikely to be a
problem as JScript versions depend on a DLL and are likely to be updated
with security and OS patches and/or any later installation of any
Microsoft software that allows scripting (WSH, Office, etc).
I don't think I am going to worry about them any more.
<snip>[color=blue][color=green]
>>Very few of the number formatting functions I have found are
>>designed to cope with the possibility that the number is in
>>the range that would normally be converted to a string in[/color]
>exponential format ...[/color]
[color=blue]
>My routines in js-round.htm are designed to *always* show the
>right value, even if the number is unreasonable for the routine
>- RSVP if any of those alleged to be good do fail here.[/color]
No, your number formatting functions don't behave stupidly with
exponential formatted numbers. I was searching c.l.j on google to see if
I could find any others that could feature in an expanded list of number
formatting functions and a recurring feature of the ones that I found
was that they tended to do stupid things with numbers of that type.
Which is partly why I am interested in seeing if anyone would like to
contribute alternatives, in the hope that they would be more robust.
[color=blue]
>Where a value, possibly the accumulated US budget in cents,
>cannot be represented in the designated width, then ISTM that
>the programmer should choose whether to break width or change
>format.[/color]
[color=blue]
>Where a value cannot be represented in the designated format,
>then ISTM that the programmer should choose whether to change
>format.[/color]
Because so many example number formatting functions that I found
disregarded the possibility of the string representation of those
numbers being in exponential format I thought it would be a good idea to
include one example that was explicitly interested in re-formatting
number strings in that format. To serve as a reminder that the
possibility existed.
[color=blue][color=green]
>>To that end I was considering using the RegExp.exec method to
>>split any (non-NaN/Infinite) number up into its significant
>>parts as one starting point for more general formatting.[/color]
>
>You cannot do that; you can only use a RegExp on a String
>representati on of a Number.
>
>If a String represents a Number, then it can also be Hex or
>Octal, and might have a decimal point not surrounded by decimal
>digits.[/color]
My plan was to take the number and type-convert it to a string for use
with the RegExp. Which side steps the consideration of octal and hex
formats. I figured that the resulting string would be as precise a
representation of the number as was available and so the substrings
would contain exactly the information from the original, with no change
in their precision or the approximation of the original number.
That seemed well suited to some re-formatting problems, such as
turning -4.7e23 into -4.7x10<sup>23</sup> where to re-formatting would
only be string manipulation.
<snip>[color=blue]
>If a Number is to be decomposed to that extent, it should be
>done by arithmetic.
>
> X=+0.00087
> Neg = X<0
> Pos = X>0
> Nun = X==0 ; Mant=Expo=0
> if (!Nun) {
> A = Math.abs(X)
> Expo = Math.floor(Math .log(A)*Math.LO G10E)
> Mant = A*Math.pow(10, -Expo) }
> Z = [Neg, Nun, Pos, Mant, Expo][/color]
What worried me about this approach was that taking a number that was
already within a range that required it to be expressed in exponential
format and then performing a sequence of mathematical operations on it
would suffer from additional approximations along the way. So even if
reversing the process always results in the original number any
presentation based on the isolated components of that number may distort
the original.
Richard.
"Dr John Stockton" <spam@merlyn.de mon.co.uk> wrote in message
news:NfdPL9OPSV EAFwKj@merlyn.d emon.co.uk...
<snip>[color=blue][color=green]
>>While I was looking at the handling of numbers for formatting
>>I noticed that IE 4 does not have isNaN and isFinite[/color]
>
>My IE 4 does have them.
>
>Small Flanagan says that isNaN is javascript 1.1 and isFinite is
>js 1.2; and that both are ECMA-262. Also that IE4 & NS4 are js 1.2.[/color]
The core language documentation from Netscape for JS 1.4 states that
isFinite was introduced in 1.3 rather than 1.2 and some JScript
documentation I have states that both were introduced in JScript 5.
Though the MSDN site says versions 1 and 3 respectively. I am not sure
if I trust any of them. But, as Jim pointed out, it is unlikely to be a
problem as JScript versions depend on a DLL and are likely to be updated
with security and OS patches and/or any later installation of any
Microsoft software that allows scripting (WSH, Office, etc).
I don't think I am going to worry about them any more.
<snip>[color=blue][color=green]
>>Very few of the number formatting functions I have found are
>>designed to cope with the possibility that the number is in
>>the range that would normally be converted to a string in[/color]
>exponential format ...[/color]
[color=blue]
>My routines in js-round.htm are designed to *always* show the
>right value, even if the number is unreasonable for the routine
>- RSVP if any of those alleged to be good do fail here.[/color]
No, your number formatting functions don't behave stupidly with
exponential formatted numbers. I was searching c.l.j on google to see if
I could find any others that could feature in an expanded list of number
formatting functions and a recurring feature of the ones that I found
was that they tended to do stupid things with numbers of that type.
Which is partly why I am interested in seeing if anyone would like to
contribute alternatives, in the hope that they would be more robust.
[color=blue]
>Where a value, possibly the accumulated US budget in cents,
>cannot be represented in the designated width, then ISTM that
>the programmer should choose whether to break width or change
>format.[/color]
[color=blue]
>Where a value cannot be represented in the designated format,
>then ISTM that the programmer should choose whether to change
>format.[/color]
Because so many example number formatting functions that I found
disregarded the possibility of the string representation of those
numbers being in exponential format I thought it would be a good idea to
include one example that was explicitly interested in re-formatting
number strings in that format. To serve as a reminder that the
possibility existed.
[color=blue][color=green]
>>To that end I was considering using the RegExp.exec method to
>>split any (non-NaN/Infinite) number up into its significant
>>parts as one starting point for more general formatting.[/color]
>
>You cannot do that; you can only use a RegExp on a String
>representati on of a Number.
>
>If a String represents a Number, then it can also be Hex or
>Octal, and might have a decimal point not surrounded by decimal
>digits.[/color]
My plan was to take the number and type-convert it to a string for use
with the RegExp. Which side steps the consideration of octal and hex
formats. I figured that the resulting string would be as precise a
representation of the number as was available and so the substrings
would contain exactly the information from the original, with no change
in their precision or the approximation of the original number.
That seemed well suited to some re-formatting problems, such as
turning -4.7e23 into -4.7x10<sup>23</sup> where to re-formatting would
only be string manipulation.
<snip>[color=blue]
>If a Number is to be decomposed to that extent, it should be
>done by arithmetic.
>
> X=+0.00087
> Neg = X<0
> Pos = X>0
> Nun = X==0 ; Mant=Expo=0
> if (!Nun) {
> A = Math.abs(X)
> Expo = Math.floor(Math .log(A)*Math.LO G10E)
> Mant = A*Math.pow(10, -Expo) }
> Z = [Neg, Nun, Pos, Mant, Expo][/color]
What worried me about this approach was that taking a number that was
already within a range that required it to be expressed in exponential
format and then performing a sequence of mathematical operations on it
would suffer from additional approximations along the way. So even if
reversing the process always results in the original number any
presentation based on the isolated components of that number may distort
the original.
Richard.
Comment