I never said it wasn't. I said you're not basing your percentage on the data presented, but on a transformation of said data, which invalidates you comparing it to percentages based on that data.
Rate is inversely proportional to time taken, they are linked so if you have one you have the other by default.
So it means 31% less time == 0.69 time == 1/0.69 rate == 1.45 rate == 45% faster. These are all different ways of saying the same thing.
If we say 31% faster == 1.31 rate = 1/0.76 == 0.76 time = 24% less time. It does not work when starting from a position of 31% faster.
Now I know you are going to say 'but in the context of time 31% faster == 0.69 time ...'. Sure you can believe that but it is an incorrect use of the word faster and is where quicker might be used. Hence the prior reference to drag racing wher quicker refers to acceleration (so 0-60 times) and fast refers to speed (I topped out at 150 MPH on the quater mile run).
I am sure you will argue 'but your definition does is not supreme over other definitions' and sure it is not. The use of faster and quicker in these contexts has convention though and if you want to stick to the convetion you don't do 31% faster == 0.69 time. AMD broke the convention of the use of the term faster which is why it is considered incorrect.
Again: I never said it couldn't be calculated from the data provided; I said it wasn't the data provided. In order to get a rate, you must first perform a calculation. That's it. The rate is inherent to the data provided, but the data provided isn't the rate, nor is the percentage presented a percentage that relates directly to the rate of work - it relates to the time to completion. This is literally the entire dumb misunderstanding that you've been harping on this entire time.
Performing a calculation on data in order to transform its unit is ... transforming the data. It is now different data, in a different format. Is this difficult to grasp?
The use of the word faster ties the % to rate. The only correct way to tie it to time in the context of a benchmark is to give a discrete time saving like 93s faster.
Fast Quick or Quickly - Cambridge Dictionary.
The base unit of data is literally the unit in which the data was provided. AMD provided data in the format of time to complete one render, and a percentage difference between said times.
They got the percentage difference wrong when combining it with the term faster. There are words that are perfectly fine for describing a 31% reduction in time taken, faster is not one of them.
There is no "mathematical" definition of "faster", as speed isn't a mathematical concept, even if the strict physical definition of it is described using math as a tool (as physics generally does). Also: if computer benchmarks belong to a scientific discipline, it is computer science, which is distinct from math, physics, etc. even if it builds on a complex combination of those and other fields. Within that context, and especially within this not being a scientific endeavor but a PR event - one focused on communication! - using strict scientific definitions of words that differ from colloquial meanings would be really dumb. That's how you get people misunderstanding you.
The reason there is an issue is because AMD used a term with a well understood colloquial meaning in a non conventional way, not that great an idea if you are meant to be focusing on communicaiton.
It isn't backwards - the measure is "smaller is better". Your opinion is that they should have converted it to a rate, which would have been "higher is better". You're welcome to that opinion, but you don't have the right to force that on anyone else, nor can you make any valid claim towards it being the only correct one.
They can display it as lower is better without issue. The problem comes when you write the blurb for that in terms of A is x% faster than Y and get the relative % incorrect. If AMD wanted to highlight the reduction in time over the increase in computational performance they needed to use a different term to faster. That is it. That is the issue, nothing more than that.
I guess it's a good thing marketing and holding a presentation for press and the public isn't a part of GCSE math or physics exams then ... almost as if, oh, I don't know, this is a different context where other terms are better descriptors?
Yes there are better descriptors you can use when trying to describe a reduction in time taken as a relative % value than faster.
Correct! But it would seem that you are implying that because those meanings are wrong for this use case, all meanings beyond yours are also wrong? 'Cause the data doesn't support your conclusions in that case; you're making inferences not supported by evidence. Please stop doing that. You're allowed to have an opinion that converting "lower is better" data to "higher is better" equivalents is more clear, easier to read, etc. You can argue for that. What you can't do is what this started out with: you arguing that because this data can be converted this way, that makes the numbers as presented wrong. This is even abundantly clear from your own arguments - that these numbers can be transformed into other configurations that represent the same things differently. On that basis, arguing that AMD's percentage is the wrong way around is plain-faced absurdity. Arguing for your preferred presentation being inherently superior is directly contradicted by saying that all conversions of the same data are equally valid. Pick one or the other, please.
Fast Quick or Quickly - Cambridge Dictionary. This is the evidence of the deliniation between fast, quick and quickly.
The numbers as presented are wrong when combined with the term faster because the convetional use of the term faster when using a relative % value refers to speed.