Forum Moderators: open
One of my sites uses frames. My homepage index.html contains a frameset and has a toolbar PR of a high 4. When I open each of the framed pages individually I see that all of them have a PageRank of 4, too. This made me think that the PR is conveyed from the frameset to each of the framed pages as is; that is, without any reduction! You could have dozens of framed pages and they all would get the same PR as the homepage!
in your experience, do you think this is the case? Couldn't this be abused in some way?
The toolbar just shows an integer on a logarithmic scale. Therefore, you can see pages with less real PR showing the 'same' toolbar PR value.
I know someone who has a framed page and a few weeks ago I checked out each page within the frames out of curiosity and found that they had less pagerank according to the toolbar.
While we're on the topic I would suggest avoiding frames altogether as they can produce a great deal of unpredictable behaviour : )
Try opening one of the links in a new window.
The pagerank generally decreases by about 1 as you click into sections ( on a roughly hierachical site ).
I know that the toolbar PR is an logarithmically scaled version of the real PR. I even happen to know that the base is 6. I still do not quite believe in a coincidence/precision issue. I'll tell you why: Let's assume that a frame reference behaves just like any other link. The homepage has three frames. Each framed page consequently receives at most one third of the frameset's PR. I say 'at most' because there also is a dampening factor in the PR equation. Anyway, the real PR of a toolbar PR4 page is six times higher than a that of a toolbar PR3 page, so one third of a high toolbar PR4 could still be a toolbar PR4. BUT: one of the framed pages is itself a frameset with two frames. This means that the the remaining one third of the PR4 is split in two which must be a toolbar PR3. But both pages have a PR4. This can't be! What's happening here?
geebee2,
> The pagerank shown is misleading - it will be the pagerank for the whole site, and will never change.
You probably mean that it's the PR of the homepage. PR is for pages, not sites.
> Try opening one of the links in a new window.
That's exactly what I did and my post reflects that.
the conclusion is simple: the logarithmic base is not 6. Moreover, the real value is much higher.
By the way, Google also modified the damping factor compared to the originally mentioned value of 0.85.
OK, then what is the base? Wouldn't you say that it must be less than 10? I'd also love to be enlightened about the dampening factor ... or is that information you don't want to share?
How is this relevant? How old is the frameset, etc?
If you're trying to base firm conclusions on pages/frames that are less than, say, 4 iterations old, you're wasting your time. Iterations occur roughly monthly.
Kaled.
The pagerank shown is misleading - it will be the pagerank for the whole site, and will never change.
That's an amazingly deep statement that I'd like to have you expand on.
The whole site? Average pagerank? Total pagerank?
Where did this idea of yours come from? Can you provide references elsewhere on this forum - it has a massive impact on one of my sites if you're correct.
DerekH
The pagerank shown is misleading - it will be the pagerank for the whole site, and will never change.
That's an amazingly deep statement that I'd like to have you expand on.
No, it's just a trivial observation that in a site with a top level frame that doesn't change, the pagerank display never changes - it just doesn't update - it just displays the pagerank of the frame page (which is what appears in the address bar).
In fact Hanu says later that he did open the sub-page in a seperate window, in which case the similar pagerank is just coincidental. I just checked a framed site, and in general (of course!) the other pages have different rank.
Hope that clears it up :)
Wouldn't you say that it must be less than 10?
No, I would say it's larger than 10.
PR is calculated iteratively.
If you're trying to base firm conclusions on pages/frames that are less than, say, 4 iterations old, you're wasting your time. Iterations occur roughly monthly.
kaled,
you're mixing different things:
First of all the well-known PR formula is not iterative. In principle you can calculate the final PR value within one step without initial guess. However, in practice one is using iterative schemes which solve the set of linear equations to speed up the numerical calculations. There are several methods to do this, e.g. the Jacobian iteration described in the original papers. Depending on the initial guess (normally one would take PR values of the last calculation as input to speed up the calculation) it takes some iterations until the solution is 'stable'.
On the other hand there are updates of the PR. (In the old days, Google updated the PR about once a month.) This means that Google take the final PR values of the iteration as input for the ranking algorithm.
However, the updates have nothing to do with the number of iterations used to calculate PR values (assuming that the PR calculation is done correctly, i.e. not stopped before the values are 'stable'). This means that even after one update the PR values shown are correct as long as the linking structure used for the calculation is the same as the current one.
Of course, there might be a delay between getting the final PR values and displaying them in the toolbar. However, this is a different topic.
First of all the well-known PR formula is not iterative.
I stated that PR was calculated iteratively. To the best of my knowledge, this is universally agreed, but only Google know for sure.
If calculated iteratively a finite number of iterations are required before you can be confident it has stablised to a specified degree of accuracy. My post states that I believe at least four iterations are required before you should rush to judgement.
Kaled.
First of all the well-known PR formula is not iterative.
This was just a (related) side note. (And the calculation is indeed done iteratively as said in msg #12.)
However, my point was the following:
However, the updates have nothing to do with the number of iterations used to calculate PR values ... This means that even after one update the PR values shown are correct as long as the linking structure used for the calculation is the same as the current one.
Kaled.
If Google is still calculation PR only (about) once a month, then there is enough time for an accurate calculation between the updates.
However, if Google is calculating PR (for example) daily on the fly (as described in the above thread) then it would take some updates (= some days) until PR is stable. However, since Google updates the PR value for the toolbar only (about) once a month, even in this case you normally would have an accurate value just after one toolbar PR update.
And another thing, why discard all the old data - makes no sense. It is possible that one update == several iterations, but I see ZERO evidence for this either.
If I were in charge, I would run a rolling continuous calculation with no discarding of data and I would incorporate each iteration into the index. I see no reason to believe Google would behave differently.
I may be wrong or maybe I'm right.
Kaled.
I even happen to know that the base is 6
Let's assume that a frame reference behaves just like any other link
I say 'at most' because there also is a dampening factor in the PR equation
The problem with your argument that it must be passing PR 100% is that you're making a bunch of assumptions. They may be right, they may not be. I don't know what the base of the logarithmic scale is and I congratulate you if you've identified it with absolute certainty. The dampening factor would have a significant impact on your calculatoins though as does the assumption that frame references are treated the same.
I'm not sayong you're wrong, I'm just saying you're making a few assumptions here that you might not have supporting facts to support.
In the end all you would need to find is one counter example to get the answer to your question about PR passing to framesets. I happened to find one, and I'm sure if you look around a little while you'll find one too.
... why would a new site show oscillations?
A Reason for this behaviour might be that Google haven't spidered the whole site. Therefore, the link structure and PR might change with time.
However, I'm not seeing these oscillations (if the whole page is spidered and get PR). By the way, the original iteration scheme wouldn't lead to oscillations during the iterations for normal linking structures.
Of course, the are also other reasons for PR changes:
- a change of PR for pages linking to page
- a change of transferred PR caused by a change of the number of links on those pages
- a change in the PR algorithm (e.g. the damping factor)
- a change in the toolbar scale
- additional incoming links or links that are removed
And another thing, why discard all the old data
I never suggested this. Even a monthly update doesn't mean that you have to start from the beginning. Moreover, I always recommended [webmasterworld.com] starting with the old data to speed up the calculations.
If I were in charge, I would run a rolling continuous calculation with no discarding of data and I would incorporate each iteration into the index.
I gave a similar statement in the 'How long does one iteration of PR calculation take?' (msg #4): 'I think it should be possible to calculate an iteration within less than one day. Therefore, it would be possible to calculate PR on the fly. E.g. start with the old PR values, make three iterations and take these values as the new ones.'
I see no reason to believe Google would behave differently.
I didn't know if Google makes a 'continuous calculation' and just updates the values shown in the toolbar once a month or still updates the PR only once a month. However, (as already pointed out) even in the first case (normally) you won't see oscillations because the time until the data are stable (few days) is much shorter than the time until Google updates the data for the toolbar.
Let me just point out that your example is also a strange way of using frames because the links in the navigation frame have _top as their target. This means that a click on a link in the navigation frame swaps in a whole new page instead of just one frame. The point of using frames is that only one frame shows a new page, the other frames stay as they are.
doc_z, just one thought: If the logarithmic base for the pagerank were 10 or higher the linear pagerank could not be represented using a 32-bit unsigned integer since 10 ^ 10 > 2 ^ 32 (first 10 is the base, second 10 is the maximum toolbar PR). Considering the type of machinery used in G's datacenters, I seriously doubt that they would use a 64 bit integer for PR.
Considering the type of machinery used in G's datacenters, I seriously doubt that they would use a 64 bit integer for PR.
I don't know on which kind of machines Google is running PR calculations. However, I'm sure that PR is a floating point with (at least) double precision (64 bit). Performing operations with a 4 billion dimensional vector using single precision doesn't make sense.
One can measure the logarithmic base as well as the damping factor. Your observations are just an example of getting informations about these values and they show b > 6 / d^2, where b is the log. base and d denotes the damping factor.
The assumption that the log. base is smaller than 10 normally based on the following arguments (a rough sketch): the total PR of the system is smaller or equal the number of pages. The page with the highest PR have not more than 1/1000 PR of the total system. Therefore, starting with real PR 1 = toolbar PR 1 leads to too high values for PR10.
However, some of the assumptions made are wrong.
