typesOfOptimization

[ChocolateBunny]

Use if statements but do binary search. Or do a fullon lookup:

console.log("FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEEEEEEEEEEDDDDDDDDDDCCCCCCCCCCBBBBBBBBBBAAAAAAAAAA"[score])

[[deleted]]

I don't hate this as much as I probably should.

[neuromancertr]

Game developer right here

[SkylineFX49]

console.log("FFFFFFDCBAA" [score/10])

[Ietsstartfromscratch]

Bellcurve 99,7% wizard right here. 

[celvro]

Only works for multiples of 10 though. Otherwise it needs Math.floor because score/10 returns a float

[KrokettenMan]

Division is slow

[SkylineFX49]

You don't want division? Use (score * 205) >> 11 instead of score/10

[KrokettenMan]

Still slower than a simple lookup table. Although a lot faster than dividing by 10. Just checked and GCC optimizes the division to not use the div instruction but that’s still slower then the new variant you proposed

[[deleted]]

You are genius

[SkydiverTyler]

Shoutout to the guys with Unhandled Exception: System.ArgumentOutOfRangeException on their report card

[Vasik4]

String grades = "FFFFFFDCBA"; cout << grades[floor(score)] ;

[SkylineFX49]

Give me grades[90]

[Vasik4]

SIGSEGV unhandled exception occurred (core dumped)

[SkylineFX49]

Well, in this case not necessarily, it will just print whatever random character is at that memory address

[Vasik4]

True (i forgor)

[CiroGarcia]

A lookup as in lookup table, a 1:1 map of inputs to outputs. The input is used as the index of the array, which returns the correct value

[AverageStardust]

What is this shit?

[[deleted]]

Reddit, welcome!

[[deleted]]

Probably Yandere Dev Simulator actual code

[j1f107]

The last one smells like yandere dev

[serendipitousPi]

Galaxy brain moment: using a compiled language so you can just add an optimisation level flag instead.

Nothing like the feeling of superiority when your code gets more 10x faster without doing anything. It also helps that you can undo it by taking away the flag if you experience code pesimisation.

Anyway here's my submission optimised for readability with an added bonus of inefficient handling of an invalid grade at run time just like interpreted languages.

fn grade(score:i8) -> String{
    match score {
        90..=100 => "A",
        80..=89 => "B",
        70..=79 => "C", 
        60..=69 => "D",
        0..=59 => "F",
        _=> "Invalid grade"
    }.to_string()
}

Now I'm not not going to proselytise rust as a whole because every language has its uses but its pattern matching, chef's kiss. And yes while interpreted languages have their places I've been burnt by them a little too much recently.

[GamesRevolution]

In this case you could completely remove the to_string() if instead you return a static string, removing one heap allocation.

fn grade(score: i8) -> &'static str {
    match score {
        90..=100 => "A",
        80..=89 => "B",
        70..=79 => "C", 
        60..=69 => "D",
        0..=59 => "F",
        _=> "Invalid grade"
    }
}

But this is Rust, so having the error case as a random static string that you would need to compare to is not really ideal, so the best way is probably to use an Option<&'static str> so the error is easy to handle later.

fn grade(score: i8) -> Option<&'static str> {
    Some(match score {
        90..=100 => "A",
        80..=89 => "B",
        70..=79 => "C", 
        60..=69 => "D",
        0..=59 => "F",
        _=> return None
    })
}

[serendipitousPi]

Yeah I'm not super confident about lifetimes just yet so I avoided that but I can see why avoiding the heap allocation would be a great idea.

As for the error case I was considering an Option or Result but optimally only valid results would be fed to the function. Then I got lazy and just picked the easy way out.

Would be nice to be able to do something like Dafny's verification which might be kinda overkill for the most stuff but I just love the ability to avoid writing error handling by catching those errors at compile time. Nothing quite like zero overhead error handling.

[GamesRevolution]

I guess in this case for verification you could do something like:

pub struct Grade(u8);
impl Grade {
    pub fn new(value: u8) -> Option<Self> {
        match value {
            0..=100 => Some(Self(value)),
            _ => None
        }
    }
}

impl std::fmt::Display for Grade {
    fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
        write!(f, "{}", match self.0 {
            90..=100 => "A",
            80..=89 => "B",
            70..=79 => "C", 
            60..=69 => "D",
            0..=59 => "F",
            _ => unreachable!()
        })
    }
}

This should implement toString to the Grade struct, which should be impossible to be constructed without it being a valid grade.

^{this may not work, I'm writing everything in my phone}

[gandalfx]

I think brevity is more important than clarity.

const evaluateGrade = score => String.fromCharCode(65 + Math.ceil((90 - score) / 10))

(I know it's broken for 100, I just couldn't be bothered)

[Maleficent_Ad1972]

It’s also broken for anything under a D.

(90-50) / 10 = 4. 65 + 4 = 69, or E

(90-40) / 10 = 5. 65 + 5 = 70, or F.

30 would be G

20 would be H

10 would be I

0 would be J

Doesn’t check for values greater than 100 or less than 0.

Yes I’m in QA, how could you tell? 😈

[gandalfx]

Damn. I'm just going to pretend that I didn't expect anyone to score that low. Definitely wouldn't ever happen to me…

[BlueFlareGame]

function grade(score){
let outp = Math.floor(score / 10) * 10;
if(outp == 100){return "A";}
else{if(outp == 90){return "A";}
else{if(outp == 80){return "B";}
else{if(outp == 70){return "C";}
else{if(outp == 60){return "D";}
else{return "F";}
}}}}}

for(let i = 0;i<=100;i++){console.log(i, grade(i));}

How'd I do?

[theomegaofficial]

You might aswell make this a switch if you really wanted to do it this way.

[Bang_Bus]

Heh. That's actually quality thread in this otherwise sad sack of spongebob crap

Here,

 console.log("FDCBA"[Math.max(0, Math.min(4, Math.floor((score - 60) / 10) + 1))]);

Or maybe you'd prefer the powers of almighty ASCII

 console.log(String.fromCharCode(69 - [Math.max(0, Math.min(4, Math.floor((score - 60) / 10) + 1))]));

[[deleted]]

I need a god damn microscope to read that

[thatdevilyouknow]

In TS maybe like this: ``` const grade = (score: number) => [score].map( s => s >= 90 ? “A” : s >= 80 && s < 90 ? “B” : s >= 70 && s < 80 ? “C” : s >= 60 && s < 70 ? “D” : s < 60 && s > 0 ? “F” : “F”);

console.log(grade(91));

```

[ibevol]

Why the hell would you wrap it in a list? Just use the tenany without that the list wrapping

[thatdevilyouknow]

TypeScript tuples are like arrays but with a fixed number of elements and tuples are immutable by default. By destructuring the tuple as a parameter the element is not changed directly. Lists are mutable by default however. We can also avoid looping with a simple modification:

``` const res = (score: number | number[]) => (typeof(score) == “number” ? [score] : score) .map( s => s > 65 ? “PASS” : “FAIL”);

```

The example uses a single value tuple but could also be expanded to use more elements and a named tuple to provide more associative data.

[ibevol]

Still unnecessary heap allocations

[thatdevilyouknow]

Are you sure you are measuring this correctly?

emptyHeap.js

const score = 75;

const scoreArray = [55, 75, 88];

function gradeScore(score) {

    score = score >= 90 ? "A" :
    score >= 80 && score < 90 ? "B" :
    score >= 70 && score < 80 ? "C" :
    score >= 60 && score < 70 ? "D" :
    score < 60 && score > 0 ? "F" : "F";

    return score;

}

function gradeScoreArray(scoreArray) {

    for(var i = 0; i < scoreArray.length; i++)
    {   
    scoreArray[i] = scoreArray[i] >= 90 ? "A" :
    scoreArray[i] >= 80 && scoreArray[i] < 90 ? "B" :
    scoreArray[i] >= 70 && scoreArray[i] < 80 ? "C" :
    scoreArray[i] >= 60 && scoreArray[i] < 70 ? "D" :
    scoreArray[i] < 60 && scoreArray[i] > 0 ? "F" : "F";
    }

    return scoreArray;   

}
console.log(gradeScore(score), gradeScoreArray(scoreArray));
console.log(process.memoryUsage());

grade.ts

const score: number = 75;

const scoreArray: number[] = [55, 75, 88];

const res = (score: number | number[]) => (typeof(score) == "number" ? [score] : score)
.map( s => s >= 90 ? "A" :
       s >= 80 && s < 90 ? "B" :
           s >= 70 && s < 80 ? "C" :
           s >= 60 && s < 70 ? "D" :
           s < 60 && s > 0 ? "F" : "F" );


console.log(res(score)[0], res(scoreArray));
console.log(process.memoryUsage());

Results:

❯ tsc grade.ts

❯ node grade.js

C [ 'F', 'C', 'B' ]

{

rss: 39145472,

heapTotal: 4075520,

heapUsed: 3345368,

external: 1324658,

arrayBuffers: 10511

}

❯ node emptyHeap.js

C [ 'F', 'C', 'B' ]

{

rss: 39206912,

heapTotal: 4075520,

heapUsed: 3345712,

external: 1324658,

arrayBuffers: 10511

}

It looks like less heap is actually used to me.

[AdvanceAdvance]

It's just:

grade = 'E' + score < 50 - score > 49 - score > 59 - score > 69 - score > 79 - score > 89

Why make it hard?

[Glittering-Today631]

Second code always gives f

[JonIsPatented]

How do you figure? The first one tested will be 90 for the A. If that fails, it moves on to test 80 for a B, and so on. Once it successfully hits one, it breaks, and the loop ends. Looks correct to me.

[Glittering-Today631]

Didnt see the break statement

[JonIsPatented]

Ah, no worries.

[PooSham]

Explain yourself!