Windsor 6000+ X2 Not a valid Pi Fast time

[Barton]

This is NOT a valid entry. The PiFast screenshot shows "Errors In Computation".

 

Accordingly, under the rules, it should be removed.

 

http://www.hwbot.org/community/submission/713353_svikens_pifast_athlon_64_6000_x2_33.89_sec

 

Open up the Pi Fast Screenshot and take a look at it.

 

Don't know if we can link to screenshots, if so, here it is:

 

http://www.hwbot.org/signature.img?iid=97910&thumb=false&iehack=.jpg

 

..

[Sweet]

Thanks Barton, that's right, this sub is blocked.

 

Regards

[Antinomy]

Dead wrong here. The result has been submitted on 21.03.2008. The rule was added on 31.08.2010

http://www.hwbot.org/forum/showpost.php?p=69072&postcount=24

 

So each time we add a new rule, we ban all the old results? It's the way it was with me. But it's not the way I think it is right.

[Sweet]

Antinomy, "Dead Wrong Here" maybe is Too much.

 

***ERROR in computation***

 

I think it is right.

 

 

This is wrong benchmark , Yesterday, today and tomorrow., block this , is correct anytime.

 

Anyone can have right to be wrong in judging something, please moderate expressions, as they can bring misunderstandings

 

Thanks and Regards

Edited January 27, 2011 by Sweet

[Antinomy]

Excuse me, it was about "according to the rules" expression. This expression (in my opinion) can't be applied to results submitted before the rule was implemented. This is the only thing I wanted to say.

 

I don't judge the rules and I don't judge the submissions.

 

If I'm wrong, we should start blocking submissions made not according to the present rules. Ridiculously, it will mean to delete all non 1.5XS Superpi runs and non 1.55 wPrime even to submissions that are dated before 1.55 version was developed.

 

That's what I've meant claiming "dead wrong".

 

Once again, forgive me if it was too offensive.

[Christian Ney]

Yeah, sure but here the fact is that the run was bugged, so even if this bug has been added to the rules after, it's still a bugged run. So even if the rule wasn't added, this run has to be deleted long time ago if someone saw it before.

 

Regarging the 1.5XS and WPrime 1.55, no we can't delete these entries that are older than the rules.

Unfortunately (I haven't managed to beat WPrime 1.43 scores even with higher frequency)

[Antinomy]

It's not a bugged run like 3DMark runs are. So this case is not completely clear. And things that are clarified by the rules are applied to older submissions.

[Mr.Scott]

I think "ERROR IN COMPUTATION" makes it quite clear. Old or new rules make no difference in this case. ERROR means invalid.

[Antinomy]

Only rules make it clear. I've got some CPU-Z validations claiming they are invalid even without overclocking no matter what version I use (in face, it came out only with the newer ones, after 1.44) - should I delete them?

[Mr.Scott]

You're comparing apples to oranges there. A little common sense goes a long way here. Splitting hairs to find loopholes in the rules is a tough road to travel my friend. I'm just sayin'.......

[Antinomy]

Unfortunately, usually we find a thing as a cheat and not a loophole the hard way.

[DrSwizz]

Instead of thinking "all or nothing" regarding benchmark scores that are not 100% correctly validated I think it would make more sense to add a 20-30% point penalty to such scores of they don't seem to be suspiciously high. That way those scores could still remain in the database and be awarded some points, but the incentive to always submit correctly validated scores would still remain more or less the same, even in relation to future rule changes. :-)

[Mr.Scott]

Instead of thinking "all or nothing" regarding benchmark scores that are not 100% correctly validated I think it would make more sense to add a 20-30% point penalty to such scores of they don't seem to be suspiciously high. That way those scores could still remain in the database and be awarded some points, but the incentive to always submit correctly validated scores would still remain more or less the same, even in relation to future rule changes. :-)

Ridiculous. You want to reward entries with errors now? Bring it on. I can make a lot of mistakes.

[knopflerbruce]

I can't recall ANY of these submissions being validated. Ever. Old submissions or new.

 

it would be easier if the program would just stop running after the error happened, but apart from that it's just as when a superpi run stops at loop 14. It makes no sense to call the result valid, as the computation is different from the results you compare it to.

[DrSwizz]

Ridiculous. You want to reward entries with errors now? Bring it on. I can make a lot of mistakes.

 

There are already plenty of hwbot submissions that are not 100% correct that are being given rewards (just browse the databse and you will see it yourself) It is not what I desire, but it is the reality that we have to deal with.

What I proposed is just one way of handling all those faulty submissions.

[Mr.Scott]

There are already plenty of hwbot submissions that are not 100% correct that are being given rewards (just browse the databse and you will see it yourself) It is not what I desire, but it is the reality that we have to deal with.

What I proposed is just one way of handling all those faulty submissions.

I HAVE seen it for myself. I report a few every day. Unfortunately, trying to get them fixed takes an act of congress, because everybody has an excuse. Rewarding faulty submissions is not the cure, it's welfare, and will stop nothing.

[Barton]

Unfortunately, usually we find a thing as a cheat and not a loophole the hard way.

 

I don't believe that is a cheat, Antinomy. It's a simple error that needs to be corrected.

 

The poster probably wasn't even aware that the run had errors in it. It's easy to overlook that when a run finishes with a good time and you're excited about that.

 

Still, under the previous rulings, the score is not valid so it needs to be removed.

 

Perhaps the best thing to cure all the old ills in the data base would be to dump the whole thing and have us all start over by submitting new runs for everything and making sure that all the runs comply to the rules and that they all include valid proof images with the submissions. IMO, there are way too many entries in the data base with no proof at all.

Edited January 30, 2011 by Barton

[Antinomy]

to dump the whole thing and have us all start over by submitting new runs for everything and making sure that all the runs comply to the rules and that they all include valid proof images with the submissions.

I absolutely agree on this one.

The only thing that I want to show is judging old results by new rules - that's what's not OK for me.

 

For example,

#1

 

I didn't post a GPU-Z screenshot since it shows nothing. Like it is here: http://hwbot.org/community/submission/1067271_antinomy_3dmark2001_se_630__656_marks

You can clearly see that GPU-Z is rubbish here and suppose I didn't have enough space to stick it in (but I used other utilities that could identify the GPU).

 

#2 Same case, but an updated GPU-Z is capable of showing the correct GPU now. So my result goes banned because I didn't put the rubbish on the screen that time while GPU-Z now does show it right. Who cares about the rules and situation in the past, when the result was made and submitted!

Oh, you're ripping the time-space continuum

 

That's the kind (not exact case, of course) logic involved from the Rules point of view. What exactly is wrong using the current rules is just additional info.

[knopflerbruce]

If old scores without proof look unreasonable, they will be removed.

[Sweet]

Antinomy, isn't same case, here, in this thread, one Pifast not complete because this is bugged.

In this case, necessarily correspond to block.

 

I dont remember a sub blocked, with the problem you mentioned

 

Regards

Edited January 30, 2011 by Sweet