i'm making my python prof wanna strangle me again, it's 100% the same as the example output, for those wondering why i do this to him it's because he said he "favors speed over readability" so i'm doing as he asks


print("\nThe cost of the item is "+str((float(input("Enter the retail value: "))/(1+float(input("enter the markup percentage (e.g. 0.9): ")))))+"\n\nEnd of Report")

  • 8
    Thats a div by zero error....
  • 1
    @magicMirror if you're dumb, yes. it's not meant to error trap and get fancy, it's meant to do the thing, as is TOTALLY PROPER to teach as habit!
  • 7
    Show me benchmarks of this. You're (again) throwing your third grader python oneliners around you telling us about your shitass teachers.

    Check the facts you dingus.
  • 0
    @nitwhiz i mean, i'm not entirely sure how %timeit works and how to actually invoke it properly, plus the comparison is one line against like 12 or 13
  • 3
    Python Rules:

    If it takes more than 10 lens your doing it wrong.

    If your using more than a couple of variables your doing it wrong.

    Learn the language.


  • 0
  • 3
    @Parzi how about you do 3-5 runs of it via unix `time`? Since were going for thousands of nanoseconds here. Because the interesting thing is not just that part of your code. Interesting would be how long the engine needs to start up, parse and run your script and cleanup + shutdown with once your oneliner, once with some variables and readability.
  • 4
    Im gonna go ahead and say that concatenation is probably slower than whatever pythons version of templating is
  • 0
    @yellow-dog i never said it was perfect, just that it's prolly faster.
  • 2
    @Parzi literally the only way to say that it's faster is to provide benchmarks. Otherwise because even Python has a compile step and a rudimentary optimizer and an interpreter that uses several tricks to go faster than naive interpretation, you really can't say anything about performance (unless it's something really obvious or you really, really know your shit).

    A one liner isn't much different from a program with variables for even a halfway smart compiler/interpreter. Plus this is a trivial program.

    Numbers, please.
  • 0
    @RememberMe if I can figure out how to do so, then sure.
  • 0
    @Parzi `time python shitcode.py` and then `time python readable.py` both multiple times, take the median of the results of the runs for each, you have it.

    Given, python code is run by `python code.py`. If not, I really don't get why this engine is even used.
  • 0

    well, that was unexpected as hell.

  • 1
    @Parzi see?

    mind sharing the spaced code, too?
  • 2
    @Parzi not the be spiteful, but no it wasn't. A computer reads 1's and 0's and contemporary compilers are pretty fucking good at arranging even the stupidest program to a good set of 1's and 0's.
  • 1
    Favours speed over readability? As long as your not flashing your program on a PROM, that's bullshit.

    On a PROM, everything is fair game. If you can make it a little more efficient, a less powerful processor is needed. Don't push as much on the stack? Less ram. Shorter? Smaller PROM. It translates into millions saved for embedded devices.

    That's still some coding.
  • 1
    @TheCommoner282 it's python, anything needing any amount of heavy lifting is gonna be slow as balls. Hopefully, with decent code juggling, slightly less so...
  • 1
    @Parzi I think that's unfair. It's a common misconception of JIT in general. Native faster than interpreted. True. But how much faster?

    I think in 99% of the cases speed is a result of a low algorithmic complexity. I just postulate that a list with ten thousand random integers is quicker sorted in python with merge sort than in C with bubble sort.

    Not a lot of us will constantly run in issues that requires to optimise past the algorithmic complexity.

    And as far as I know there are a few neat tricks in pythons standard library. For instance when you sort a list, then it checks the length first and then decides about the used algorithm.

    But I don't like python anyway. Won't forgive it for not being type safe, so what is it my business to defend it...
  • 0
    @TheCommoner282 C will outmuscle Python at anything complex and we both know it. I've managed to optimize an MD5 collision engine I wrote to the best of my ability, and any file size over 32 bytes or so is amazingly slow. Couple hundred tries/sec isn't shit when you've got several quintillion or more on a 3GHz CPU. (Granted, if threading in Python wasn't garbage, it'd be a lot better, but y'know...)
    it's so optimized i'm even using spooled RAM to read/write each try as fast as possible, and i'm playing odds by using PRNG fill instead of sequential data as it's statistically more likely to be whatever the PRNG spits out than a fuckton of empty space and then like 4 bytes of data.

    The same engine in C would probably be pulling millions of tries per second at 32 bytes, with threading.
  • 0
Add Comment