How to refresh cached image ONCE
C. (http://symcbean.blogspot.com/)
I have an application which generates image graphs. These cache nicely
at the client, however if the user submits more data, I'd like to
force a reload of the image from the server.
I had a google, but all I could find were suggestions to use a varying
query in the URL. This is not a solution to my problem because if I
change the page to do that then ALL the graphs will be reloaded every
time.
I tried
document.getElementById("imgs_id_tag").src.reload():
and
document.getElementById("imgs_id_tag").reload():
But just got errors.
(If I open JUST the image URL in a browser, I get the cached version,
if I then click on refresh, it goes back to the server to get a new
copy - which is what I want).
Any suggestions?
TIA
C.
webbu...@gmail.com
var elem = document.getElementById("imgs_id_tag");
var oldSrc = elem.src;
elem.src = oldSrc + '?rnd=' + new Date().getTime();
This basically says "set the src to the exact same thing, with an
aditional 'random' parameter (current date/time as a number)"
HTH
Jorge
Stanislav
Hi,
You should send right http headers to the client.
More about this: http://developer.yahoo.com/performance/rules.html
under Add an Expires or a Cache-Control Header
;)
Best,
Stanislav
Thomas 'PointedEars' Lahn
> you can try this...
>
> var elem = document.getElementById("imgs_id_tag");
The `images' collection should be used instead:
var elem = document.images["imgs_id_tag"];
> var oldSrc = elem.src;
What for?
> elem.src = oldSrc + '?rnd=' + new Date().getTime();
>
> This basically says "set the src to the exact same thing, with an
> aditional 'random' parameter (current date/time as a number)"
Because it is not considered the same thing by the user agent, it will fill
up its cache (if enabled), leaving less space for other, maybe more
important data.
Also, a random value alone is not sufficient; it must be a value that is
unique over a longer period of time, like the timestamp that you suggested.
Cache-controlling HTTP headers are the correct approach instead.
Please do a little research before you post something here.
PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>
Jorge
wrote:
>
> Also, a random value alone is not sufficient;
>
Yes it is, Thomas, remember that the OP said that he wanted to reload
the image *once*.
> it must be a value that is
> unique over a longer period of time, like the timestamp that you suggested.
>
The probability of obtaining the same ramdom number twice in a row is
about 1/(2^(8*8)) === 1/18446744073709551615
And keeps being almost null even after tens or hundreds of
extractions.
If you want to experiment how long that period of time can be, try
this : it will hang your browser until Math.random() repeats a certain
value :-)
javascript:n= 0, a= Math.random();while(a !== Math.random()){n+
+};alert(n);
--Jorge.
Jorge
>
Right. Cache-control headers ought to be explicitly setup just for
these images. Agreed.
But the OP was looking for a client-side solution, and that's not.
And the proposed solution will get the image reloaded regardless of
the (cache control) headers sent/received.
> Please do a little research before you post something here.
>
Grrr.
--Jorge.
Jorge
>
> javascript:n= 0, a= Math.random();while(a !== Math.random()){n+
> +};alert(n);
>
On my Mac it took 2,147,483,645 iterations to get "a" repeated.
--Jorge.
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> Cache-controlling HTTP headers are the correct approach instead.
>
> Right. Cache-control headers ought to be explicitly setup just for
> these images. Agreed.
>
> But the OP was looking for a client-side solution, and that's not.
| I have an application which generates image graphs. These cache nicely
| at the client, however if the user submits more data, I'd like to
| force a reload of the image from the server.
Not a single word about a client-side only solution.
> And the proposed solution will get the image reloaded regardless of
> the (cache control) headers sent/received.
The server must send an appropriate expiry value and ETag in the headers,
and the client must refresh the images often enough. If the expiry date was
met, the ETag changed or the resource was not in the cache in the first
place, it would be downloaded (again) from the server; if not, the cache
would be used. ISTM anything else would require a server-push communication
like Comet.
>> Please do a little research before you post something here.
>
> Grrr.
Now I have given you a reason for that.
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
Jorge
wrote:
> Jorge wrote:
> > Thomas 'PointedEars' Lahn wrote:
> >> Cache-controlling HTTP headers are the correct approach instead.
>
> > Right. Cache-control headers ought to be explicitly setup just for
> > these images. Agreed.
>
> > But the OP was looking for a client-side solution, and that's not.
>
> | I have an application which generates image graphs. These cache nicely
> | at the client, however if the user submits more data, I'd like to
> | force a reload of the image from the server.
>
> Not a single word about a client-side only solution.
>
Does this look like server-side scripting to you : (?)
"I tried document.getElementById("imgs_id_tag").src.reload(): "
"and document.getElementById("imgs_id_tag").reload(): "
> (...)
> ISTM anything else would require a server-push communication
> like Comet.
>
Duh !
--Jorge.
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> Jorge wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> Cache-controlling HTTP headers are the correct approach instead.
>>> Right. Cache-control headers ought to be explicitly setup just for
>>> these images. Agreed.
>>> But the OP was looking for a client-side solution, and that's not.
>> | I have an application which generates image graphs. These cache nicely
>> | at the client, however if the user submits more data, I'd like to
>> | force a reload of the image from the server.
>>
>> Not a single word about a client-side only solution.
>
> Does this look like server-side scripting to you : (?)
>
> "I tried document.getElementById("imgs_id_tag").src.reload(): "
> "and document.getElementById("imgs_id_tag").reload(): "
I have noticed that before. So the OP had a problem with their client-side
script for refreshing the image. That does not mean in any way that the
solution must be client-side only.
>> (...)
>> ISTM anything else would require a server-push communication
>> like Comet.
>
> Duh !
Tough luck.
C. (http://symcbean.blogspot.com/)
wrote:
> Jorge wrote:
> > Thomas 'PointedEars' Lahn wrote:
> >> Jorge wrote:
> >>> Thomas 'PointedEars' Lahn wrote:
> >>>> Cache-controlling HTTP headers are the correct approach instead.
> >>> Right. Cache-control headers ought to be explicitly setup just for
> >>> these images. Agreed.
> >>> But the OP was looking for a client-side solution, and that's not.
> >> | I have an application which generates image graphs. These cache nicely
> >> | at the client, however if the user submits more data, I'd like to
> >> | force a reload of the image from the server.
>
> >> Not a single word about a client-side only solution.
>
> > Does this look like server-side scripting to you : (?)
>
> > "I tried document.getElementById("imgs_id_tag").src.reload(): "
> > "and document.getElementById("imgs_id_tag").reload(): "
>
> I have noticed that before. So the OP had a problem with their client-side
> script for refreshing the image. That does not mean in any way that the
> solution must be client-side only.
>
> >> (...)
> >> ISTM anything else would require a server-push communication
> >> like Comet.
>
Thanks guys - unfortunately it doesn't really solve my proble - I
guess I didn't make it clear enough.
I really want the image to be cached client side unless the data used
to create the image (server-side) changes. I can't really get every
client who has a cached copy to update their cache. Using a dirrent
URI each time by appending a random value just makes the browser think
it is a different image - undermining the caching which is working
fine in most cases:
> had a google, but all I could find were suggestions to use a varying
> query in the URL. This is not a solution to my problem because if I
> change the page to do that then ALL the graphs will be reloaded every
> time.
However, I think it may be possible to do for the client who just
uploaded the data - since, if they click the 'Refresh' button in the
browser it carries out an unconditional reload of the content. I'm
wanting to emulate this from Javascript.
C.
Thomas 'PointedEars' Lahn
> I really want the image to be cached client side unless the data used to
> create the image (server-side) changes.
That is what cache-controlling headers are for: <http://mnot.net/cache-docs>
> I can't really get every client who has a cached copy to update their
> cache.
Why not?
> Using a dirrent URI each time by appending a random value just makes the
> browser think it is a different image - undermining the caching which is
> working fine in most cases:
This is updating the cache in a sense, only that it is filled with mostly
useless information then. You hardly want that.
>> had a google, but all I could find were suggestions to use a varying
>> query in the URL. This is not a solution to my problem because if I
>> change the page to do that then ALL the graphs will be reloaded every
>> time.
>
> However, I think it may be possible to do for the client who just
> uploaded the data - since, if they click the 'Refresh' button in the
> browser it carries out an unconditional reload of the content. I'm
> wanting to emulate this from Javascript.
Have you already tried executing
img.src = img.src;
or
var oldsrc = img.src;
img.src = "";
img.src = oldsrc;
in a repetitive setTimeout() while using cache-controlling headers?
Jorge
<colin.mckin...@gmail.com> wrote:
>
> However, I think it may be possible to do for the client who just
> uploaded the data - since, if they click the 'Refresh' button in the
> browser it carries out an unconditional reload of the content. I'm
> wanting to emulate this from Javascript.
>
See here : http://tinyurl.com/6lwmmb
The first & second buttons do what Thomas is proposing.
The 3rd button does a truly "unconditional reload" of the *same* image
file.
Though, you don't seem to want an unconditional reload, because you
don't want the image to be reloaded unless the image content has
changed.
The cache control headers have to be setup properly in order to
achieve this.
But still, in order to trigger the reload, it's unclear to me how is
it going to be discovered client-side, that the image content has
changed at the server-side ?
--Jorge.
Dr J R Stockton
8g2000hsy.googlegroups.com>, Fri, 18 Jul 2008 12:16:30, Jorge
<jo...@jorgechamorro.com> posted:
>On Jul 18, 7:50 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
>wrote:
>>
>> Also, a random value alone is not sufficient;
>>
>
>Yes it is, Thomas, remember that the OP said that he wanted to reload
>the image *once*.
>
>> it must be a value that is
>> unique over a longer period of time, like the timestamp that you suggested.
>>
>
>The probability of obtaining the same ramdom number twice in a row is
>about 1/(2^(8*8)) === 1/18446744073709551615
>And keeps being almost null even after tens or hundreds of
>extractions.
No, for two reasons. The generator is not necessarily 64-bit or even
53-bit. In my js-randm.htm, "MSIE 6 and 7 show 53 bits; Firefox 2.0.0.3
shows 52 bits; Opera 9.21 shows 31 bits; Safari 3.1 shows 31 bits."
And, as the generator is only pseudo-random, it should not repeat until
after a full cycle.
What does that page report (for various browsers?) on your Mac?
--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05.
Web <URL:http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms
PAS EXE etc : <URL:http://www.merlyn.demon.co.uk/programs/> - see 00index.htm
Dates - miscdate.htm moredate.htm js-dates.htm pas-time.htm critdate.htm etc.
Dr J R Stockton
18 Jul 2008 19:50:07, Thomas 'PointedEars' Lahn <Point...@web.de>
posted:
>
>> elem.src = oldSrc + '?rnd=' + new Date().getTime();
>>
>> This basically says "set the src to the exact same thing, with an
>> aditional 'random' parameter (current date/time as a number)"
>Also, a random value alone is not sufficient; it must be a value that is
>unique over a longer period of time, like the timestamp that you suggested.
In most browser instances, Math.random can be shown to give 53 bits of
pseudo-randomness, although the initial value's randomness depends on
the quality of the initialisation.
Machines connected to the Internet generally resynchronise from time to
time with an Internet or server clock. Nearly 50% of computers will
need to be set back in time, and in the case of those which cannot be
slowed or stopped but must jump back it will be necessary to repeat a
certain amount of internal-clock time. So new Date().getTime() may
give the same value after an interval as it did before. That will not
often happen, but ISTM likely to happen more often than the repeat of a
good RNG, let alone of a a PRNG which will cycle through all possible
values before repeating.
Recommending adjusting HTTP headers as opposed to adjusting the 'URL' is
not helpful to those whose servers do not allow header control.
Professional servers should allow it; those available to many of the
amateurs who read this group may very well not do so.
>Please do a little research before you post something here.
Please think before you post something here.
Jorge
>
> No, for two reasons. The generator is not necessarily 64-bit or even
> 53-bit. In my js-randm.htm, "MSIE 6 and 7 show 53 bits; Firefox 2.0.0.3
> shows 52 bits; Opera 9.21 shows 31 bits; Safari 3.1 shows 31 bits."
> And, as the generator is only pseudo-random, it should not repeat until
> after a full cycle.
>
Yes you're right. In fact Safari's PRNG always repeats at n=
2,147,483,645 (-> 2^31) (don't tell Thomas :-)
> What does that page report (for various browsers?) on your Mac?
>
"Apparent resolution is at least 30 bits."
Thanks,
--Jorge.
Jorge
On a Mac :
Webkit r34974: "Apparent resolution is at least 30 bits."
Safari 3.1.2: "Apparent resolution is at least 30 bits."
Opera 9.51: "Apparent resolution is at least 31 bits."
Navigator 9.0.0.3: "Apparent resolution is at least 52 bits."
Camino 1.6.1: "Apparent resolution is at least 52 bits."
FF 2.0.0.16: "Apparent resolution is at least 52 bits."
FF 3.1: "Apparent resolution is at least 52 bits."
IE 5.2.3: "Apparent resolution is at least 53 bits."
iCab 3.0.5: "Apparent resolution is at least 58 bits."
--Jorge
Dr J R Stockton
2g2000hsc.googlegroups.com>, Sat, 19 Jul 2008 12:37:21, Jorge
<jo...@jorgechamorro.com> posted:
>On Jul 19, 6:07 pm, Dr J R Stockton <j...@merlyn.demon.co.uk> wrote:
>> What does that page report (for various browsers?) on your Mac?
> ...
>iCab 3.0.5: "Apparent resolution is at least 58 bits."
That one was initially rather unexpected, since Math.random() is
supposed to return an evenly-distributed IEEE Double with an effective
53-bit mantissa, and the best previously seen or reported was 53 bits.
ISO/IEC 16262 only requires that the result of Math.random() be evenly
distributed, not that the resolution be independent of the value.
It appears that other browsers in effect mask the output of the
(64-bit?) PRNG to 53 bits before converting to Double, while iCab does
that only within the conversion itself.
It seems undesirable for there to be unnecessary numerical differences
between browsers; if anyone has contact with those writing future
specifications, then I suggest that they ask for the future spec to have
this uncertainty removed. While iCab in a sense has better randomness,
ISTM that uniformity would be preferable.
The function you observed, Resol, is now Resol1; new Resol3 is similar
but uses only randoms >= 0.5.
--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)
Jorge
>
> The function you observed, Resol, is now Resol1; new Resol3 is similar
> but uses only randoms >= 0.5.
>
John,
I have retouched your resol1() a little bit. Now it receives a
parameter p, and it doesn't return until the higher resolution found
remains unchanged for p iterations of the loop. It gives higher
readings now.
I have also written a bits() function that finds what is the smaller
power of 2 for which it's true that (2^x) === ((2^x)+1). I think that
that must be the size of the mantissa, or not ?
See it here : http://tinyurl.com/68d9br
These are the numbers I get :
IE 5.2.3 : 53, 53.
FF2, FF3 : 52, 53.
Safari : 30, 53.
Opera 9.51 : 31, 53.
iCab 3.0.5 : 63, 53.
But I don't understand why those numbers are different. And, if the
mantissa is 53 bits (iCab), how can, why does resol1() give 63 ?
Here's the code :
<script>
window.onload= function () {
var resol1= (function (p) {
var x, t, max= 0, i= p;
while (i) {
t= 0, x= Math.random();
while ((x*= 2)%1 > 0) { // shift left until empty
t++;
}
if (t > max) {
max= t, i= p;
} else {
i--;
}
}
return max;
})(1e4);
var bits= (function () {
var x, i= 0;
do {
x= Math.pow(2,++i);
} while (x !== (x+1))
return i;
})();
var test= Math.pow(2,bits);
var text= "resol1() : Maximum resolution is at least "+resol1+"
bits.<br>";
text+= "bits() : "+bits+" -> In this browser "+(test+1)+" ===
1+"+test;
(document.body.appendChild(
document.createElement(
'h2'))).innerHTML= text;
};
</script>
Thanks,
--Jorge.
C. (http://symcbean.blogspot.com/)
Thanks Jorge - unfortunately the first 2 still use the cached copy (in
Firefox) while the last undermines the caching policy I'm trying to
implement.
I struggled for a while with this - as per my original post - I could
get it to reload by accesing the image URL directly from the browser
then hitting the reload button - I just need to implement that in
Javascript - eventually I came up with one solution:
I can get to go back to the server even though the image is cached if
I put in an iframe with src= the image URL then
document.getElementById("MyIframe").contentWindow.location.reload();
(only tested with Firefox & seems like rather hard work though)
(BTW - regarding the big discussion about random numbers - if it's
that important use a timestamp instead)
C.
Jorge
<colin.mckin...@gmail.com> wrote:
>
> I can get to go back to the server even though the image is cached if
> document.getElementById("MyIframe").contentWindow.location.reload();
>
If just a plain location.reload() won't do, if setting img.src+= "?
something" won't do either, then that sounds like a Good Idea...
--Jorge.
Dr J R Stockton
6g2000hsf.googlegroups.com>, Mon, 21 Jul 2008 06:27:24, Jorge
<jo...@jorgechamorro.com> posted:
>I have also written a bits() function that finds what is the smaller
>power of 2 for which it's true that (2^x) === ((2^x)+1). I think that
>that must be the size of the mantissa, or not ?
We know that 2^53 is 9007199254740992. A Number, being an IEEE Double
and having a 53-bit mantissa, cannot represent 9007199254740993. But
it's not yet absolutely clear to me whether 2^53+1 MUST evaluate to 2^53
and not to 2^53+2.
It is certain that JavaScript uses IEEE Doubles, and that those consist
of one sign bit, eleven biased-exponent bits, a non-stored "1" bit
leading the mantissa, and fifty-two more mantissa bits. 2^53+1 is the
lowest integer requiring MSB...LSB to be at least 54 bits; the lowest
which cannot be stored exactly.
>These are the numbers I get :
>
>IE 5.2.3 : 53, 53.
>FF2, FF3 : 52, 53.
>Safari : 30, 53.
>Opera 9.51 : 31, 53.
>iCab 3.0.5 : 63, 53.
>
>But I don't understand why those numbers are different. And, if the
>mantissa is 53 bits (iCab), how can, why does resol1() give 63 ?
I'm not entirely sure, to +/- 1 in the result, whether the algorithms
are ideal. But there are clearly three cases : about 31, about 52, and
about 63.
I suppose that "about 31" are those in which 32-bit processing is
involved - probably a 32-bit generator (which will repeat after 2*32 (or
2^32-1) values). Clearly, given the integer operations such as X|Y and
the use of Number for storage, the JavaScript engine must have
interconverters.
The others probably, but not necessarily, use a 64-bit integer pseudo-
random binary sequence generator of the form
U[n] = (U[n-1]*vast + 1) mod 2^64.
Note that the FPU of a PC has the "comp" type, a 64-bit integer, and the
"Extended" type, with a genuine 64-bit mantissa; and a PC can do 64-bit
integer arithmetic either with comp or with a pair of 32-bit integers.
So the system programmer can calculate U[n], put it into the mantissa of
an Extended with suitable exponent, and ask for conversion to the Double
equivalent. In the conversion, U[n] will lose all its leading zeroes,
and then as many trailing bits as cannot fit into the 53 places
available. The value of the least preserved bit will depend on the
value of the Random generated.
However, that means that the resolution of Math.random depends on the
value generated - which seems undesirable.
Those who think that Math.random should give only multiples of 2^-53
(and will in time give all such values such that 0<=X<1) can instead
mask U[n] to 53 bits before conversion, or round the converted result to
a multiple of 2^-53.
--
(c) John Stockton, near London. *@merlyn.demon.co.uk/?.?.Stockton@physics.org
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Correct <= 4-line sig. separator as above, a line precisely "-- " (SoRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "> " (SoRFC1036)
Thomas 'PointedEars' Lahn
> "C. (http://symcbean.blogspot.com/)" wrote:
>> However, I think it may be possible to do for the client who just
>> uploaded the data - since, if they click the 'Refresh' button in the
>> browser it carries out an unconditional reload of the content. I'm
>> wanting to emulate this from Javascript.
>
> See here : http://tinyurl.com/6lwmmb
I explained to you before why those alias URLs are unsuitable and
unnecessary in Usenet, and asked you to stop posting them.
I am asking you again to post original URL(s) here instead. As a Google
Groups user who heavily relies on the information in that archive, surely
you can see the advantages in complying with that request.
> [...]
> But still, in order to trigger the reload, it's unclear to me how is
> it going to be discovered client-side, that the image content has
> changed at the server-side ?
Then you should read <http://mnot.net/cache-docs> (again). It explains in
great detail which headers are used by clients to determine that.
Therefore, I see two distinct possibilities and two variations:
1. A client that makes only GET requests.
A) If there is a cached resource and headers indicate that the
server-side resource has not changed, it disconnects without
receiving the message body and retrieves the resource from
the cache instead.
B) The entire response is evaluated regardless of headers first.
Then headers are evaluated to determine which resource can be
considered newer. Then proceed as in (A).
2. A client that makes a HEAD request first. If headers indicate that
the cached resource (if there is one) and the server-side resource
differ, it proceeds with a GET request; else it retrieves the
resource from the cache. (Further tests may happen afterwards.)
HTH
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
Jorge
wrote:
> Jorge wrote:
>
> > But still, in order to trigger the reload, it's unclear to me how is
> > it going to be discovered client-side, that the image content has
> > changed at the server-side ?
>
> Then you should read <http://mnot.net/cache-docs> (again). It explains in
> great detail which headers are used by clients to determine that.
>
I worded it badly. Does the server's image change because the user/
client posts some new data ?
If so, the client knows beforehand when to reload the image.
If not, either poll or reload blindly (relying on correct cache
headers) or the image would need to be pushed somehow, if at all
possible.
--Jorge.
Jorge
wrote:
>
> I explained to you before why those alias URLs are unsuitable and
> unnecessary in Usenet, and asked you to stop posting them.
>
Yes Thomas, you did. But I still don't agree with you. Sorry about
that.
Regards,
--Jorge.
Dr J R Stockton
22 Jul 2008 19:08:42, Thomas 'PointedEars' Lahn <Point...@web.de>
posted:
>Jorge wrote:
>> "C. (http://symcbean.blogspot.com/)" wrote:
>>> However, I think it may be possible to do for the client who just
>>> uploaded the data - since, if they click the 'Refresh' button in the
>>> browser it carries out an unconditional reload of the content. I'm
>>> wanting to emulate this from Javascript.
>>
>> See here : http://tinyurl.com/6lwmmb
>
>I explained to you before why those alias URLs are unsuitable and
>unnecessary in Usenet, and asked you to stop posting them.
>
>I am asking you again to post original URL(s) here instead. As a Google
>Groups user who heavily relies on the information in that archive, surely
>you can see the advantages in complying with that request.
Why should one be concerned with your alleged convenience in the matter
of compressed URLs when you persistently ignore the convenience of
others by not only providing but insisting upon the briefest of
attributions?
--
(c) John Stockton, nr London UK. ???@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Check boilerplate spelling -- error is a public sign of incompetence.
Never fully trust an article from a poster who gives no full real name.
Jorge
>
> I'm not entirely sure, to +/- 1 in the result, whether the algorithms
> are ideal. But there are clearly three cases : about 31, about 52, and
> about 63.
>
What do you think about this :
do {
x*= 2, x-= Math.floor(x), t++;
} while ( x> 0) // shift left until empty
(?)
--Jorge.
Dr J R Stockton
6g2000pri.googlegroups.com>, Thu, 24 Jul 2008 16:56:10, Jorge
<jo...@jorgechamorro.com> posted:
It gives an answer one larger than the corresponding part of my code.
That may be better.
--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Dr J R Stockton
rlyn.invalid>, Fri, 25 Jul 2008 23:30:59, Dr J R Stockton
<j...@merlyn.demon.co.uk> posted:
>In comp.lang.javascript message <72ddfea4-511a-4a91-9e37-0a8be4328cd3@k3
>6g2000pri.googlegroups.com>, Thu, 24 Jul 2008 16:56:10, Jorge
><jo...@jorgechamorro.com> posted:
>>On 22 jul, 00:38, Dr J R Stockton <j...@merlyn.demon.co.uk> wrote:
>>>
>>> I'm not entirely sure, to +/- 1 in the result, whether the algorithms
>>> are ideal. But there are clearly three cases : about 31, about 52, and
>>> about 63.
>>
>>What do you think about this :
>>
>> do {
>> x*= 2, x-= Math.floor(x), t++;
>> } while ( x> 0) // shift left until empty
>
>It gives an answer one larger than the corresponding part of my code.
>That may be better.
Or for (x = Math.random(), t = 0 ; x%1 > 0 ; t++) x *= 2
I have changed <URL:http://www.merlyn.demon.co.uk/js-randm.htm#MR>
subsection "For Your Browser".
I see, in WinXP, Safari & Opera showing as expected for a 32-bit PRBS
converted to Double. Firefox has a PRBS of at least 53 bits, with my
results comparable with Math.random() returning only multiples of 2^-53.
But MSIE apparently can return an odd multiple of 2^-54, which seems
unsound.
ISO/IEC 16262 15.8.2.14 is somewhat liberal in its definition of what
Math.random() should give; but, as in its range the absolute resolution
of Number is lowest (for values of 0.5 and higher) at 2^-53, the
greatest uniformity is obtained by allowing return values of N * 2^-53
for 0 <= N < 2^53. Anything else is less than ideal.
Comments?
--
(c) John Stockton, near London. *@merlyn.demon.co.uk/?.?.Stockton@physics.org
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Jorge
> In comp.lang.javascript message <nls87jYjQliIF...@invalid.uk.co.demon.me
On a Mac: resolA, resolB, resolC :
Safari 3.1.2: 31,31,31
FF 2.0.0.16 : 53,53,53
FF 3.0.1 : 53,53,53
Opera 9.5.1: 32, 32, 32
IE 5.2.3: 54,53,54
iCab 3.0.5: 64,53,57
--Jorge.
Dr J R Stockton
> On Jul 27, 2:59 pm, Dr J R Stockton <j...@merlyn.demon.co.uk> wrote:
> > I have changed <URL:http://www.merlyn.demon.co.uk/js-randm.htm#MR>
> > subsection "For Your Browser".
>
> > I see, in WinXP, Safari & Opera showing as expected for a 32-bit PRBS
> > converted to Double. Firefox has a PRBS of at least 53 bits, with my
> > results comparable with Math.random() returning only multiples of 2^-53.
> > But MSIE apparently can return an odd multiple of 2^-54, which seems
> > unsound.
> > Comments?
>
> On a Mac: resolA, resolB, resolC :
>
> Safari 3.1.2: 31,31,31
> FF 2.0.0.16 : 53,53,53
> FF 3.0.1 : 53,53,53
> Opera 9.5.1: 32, 32, 32
> IE 5.2.3: 54,53,54
> iCab 3.0.5: 64,53,57
Thanks; I've updated the page. It may be that with various different
range parameters for ResolC a greater understanding of what iCab is
doing might be obtained. The author of iCab can be found via <http://
www.icab.de/>.
--
(c) John Stockton, near London, UK. Posting with Google.
Mail: J.R.""""""""@physics.org or (better) via Home Page at
Web: <URL:http://www.merlyn.demon.co.uk/>
FAQish topics, acronyms, links, etc.; Date, Delphi, JavaScript, ...
Jorge
> ><jo...@jorgechamorro.com> posted:
> >>What do you think about this :
>
> >> do {
> >> x*= 2, x-= Math.floor(x), t++;
> >> } while ( x> 0) // shift left until empty
>
>
>
Or do {} while (t++, (x*= 2)%1 > 0)
Why there's not an "international obfuscated JavaScript code
contest" ?
--Jorge.
Dr J R Stockton
6g2000hsf.googlegroups.com>, Mon, 28 Jul 2008 08:02:04, Jorge
<jo...@jorgechamorro.com> posted:
>Or do {} while (t++, (x*= 2)%1 > 0)
or do {t++} while ((x*=2)%1)
>Why there's not an "international obfuscated JavaScript code
>contest" ?
You're in it! But that means "count doublings until integer", which
expresses the need rather exactly. Page js-randm.htm again updated;
results as before.
--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)
Jorge
You got it right. Oh yeah, now that's perfect !
--Jorge.