Live data from Hacker News

Data structures and algorithms I actually used while working at tech companies

blog.pragmaticengineer.com

541–547 of 547 posts

Re: Data structures and algorithms I actually used while working at tech companies

#541
post #526
post #525

Earlier quoted context omitted.

Your version is definitely more performant, but the three liner is just a bit nicer to read (especially for beginners) :)

Yes. It depends on what you want to show. Your version shows how to define functions and some simple pattern matching.

Having worked with Haskell for a year now I still can't read much more than functions and pattern matching! :D

Re: Data structures and algorithms I actually used while working at tech companies

#542
post #540

Earlier quoted context omitted.

> Just to be more pedantic: it did use tail calls, but the recursive calls weren't the tail calls. I was talking about this code: def fib(n): if n = Not sure what you mean by tail calls here. I don't see Python-level tail calls. The interpreter will call C code for tuple packing, but those aren't in tail position with respect to the Python code either.

The last call (to a function or operator) is in the tail position. In this case, it is tuple packing. Why wouldn't the tuple packing be in tail position in the Python code?

Because after tuple packing returns (a C return) you still need to perform a Python return. The C tuple packing function cannot return directly from the Python function.

Looking at https://github.com/python/cpython/blob/master/Python/ceval.c, here is the code that needs to be executed after the tuple is constructed:

        case TARGET(RETURN_VALUE): {
            retval = POP();
            assert(f->f_iblock == 0);
            assert(EMPTY());
            f->f_state = FRAME_RETURNED;
            f->f_stackdepth = 0;
            goto exiting;
        }

    // ...

    exiting:
    if (tstate->use_tracing) {
        if (tstate->c_tracefunc) {
            if (call_trace_protected(tstate->c_tracefunc, tstate->c_traceobj,
                                     tstate, f, PyTrace_RETURN, retval)) {
                Py_CLEAR(retval);
            }
        }
        if (tstate->c_profilefunc) {
            if (call_trace_protected(tstate->c_profilefunc, tstate->c_profileobj,
                                     tstate, f, PyTrace_RETURN, retval)) {
                Py_CLEAR(retval);
            }
        }
    }

    /* pop frame */
    exit_eval_frame:
    if (PyDTrace_FUNCTION_RETURN_ENABLED())
        dtrace_function_return(f);
    _Py_LeaveRecursiveCall(tstate);
    tstate->frame = f->f_back;

    return _Py_CheckFunctionResult(tstate, NULL, retval, __func__);
I guess you could duplicate all this code in a special "pack tuple and return from Python function" C function which you could then really tail call.

Re: Data structures and algorithms I actually used while working at tech companies

#543

Earlier quoted context omitted.

Most wood workers likely won’t know or care how to build their tools from scratch

In the sense of going from rocks to iron to steel to finished tool, no, but otherwise, yes. Making specialised saws, scrapers, chisels, spokeshaves, planes and so forth are part of the luthier's, cabinetmaker's, and shipwright's existence. And that's just the tools, leaving workholding aside. Add in jigs and fixtures and there's a whole lot more. Not everything you need to do the job can be had off the shelf.

That’s quite niche and by and large not the majority of wood workers...

Re: Data structures and algorithms I actually used while working at tech companies

#544
post #370

Earlier quoted context omitted.

Yup if you are willing to explain the algorithm to the candidate and not dock them any "points" (or whatever) for having to explain the algorithm, then this works fine. I have no qualms about having a discussion about an algorithm that's tricky, and seeing how the candidate works through it. That's not what I see in practice though. Not remembering the whole algorithm at best ends up wasting half of the interview (co…

> That's not what I see in practice though. Not remembering the whole algorithm at best ends up wasting half of the interview (code the remainder in 20 minutes??), and at worst gets explicit language from the interviewer like "TC couldn't figure out and I had to explain the algorithm to them explicitly, WEAK/BORDERLINE on algorithms". It is kind of hilarious to get an algorithm problem which took eminent computer sci…

If I liked spending time memorizing long stretches of text, I'd be a doctor, not a software developer.

Re: Data structures and algorithms I actually used while working at tech companies

#545

Early in my career, I interviewed at Google. One of the interviewer asked me to recite the algorithm for constructing a Convex Hull. Since I hadn't done anything related to convex hulls since my algorithms class as a sophomore in college (several years earlier), I couldn't remember all the details. At some point, I said, I know where in CLRS ( https://www.amazon.com/Introduction-Algorithms-3rd-MIT-Press... ) this is.…

“Never memorize something that you can look up.” - Albert Einstein

https://www.goodreads.com/quotes/24194-never-memorize-someth...

Re: Data structures and algorithms I actually used while working at tech companies

#546
post #540

Earlier quoted context omitted.

The last call (to a function or operator) is in the tail position. In this case, it is tuple packing. Why wouldn't the tuple packing be in tail position in the Python code?

Because after tuple packing returns (a C return) you still need to perform a Python return. The C tuple packing function cannot return directly from the Python function. Looking at https://github.com/python/cpython/blob/master/Python/ceval.c , here is the code that needs to be executed after the tuple is constructed: case TARGET(RETURN_VALUE): { retval = POP(); assert(f->f_iblock == 0); assert(EMPTY()); f->f_state =…

Oh, yes, I was only saying that as far as the Python language is concerned the tuple packing is in the tail position.

Any specific implementation, and in this case cpython, could do arbitrary weird things after.

Thanks for looking up the code!

Re: Data structures and algorithms I actually used while working at tech companies

#547

Earlier quoted context omitted.

In the sense of going from rocks to iron to steel to finished tool, no, but otherwise, yes. Making specialised saws, scrapers, chisels, spokeshaves, planes and so forth are part of the luthier's, cabinetmaker's, and shipwright's existence. And that's just the tools, leaving workholding aside. Add in jigs and fixtures and there's a whole lot more. Not everything you need to do the job can be had off the shelf.

That’s quite niche and by and large not the majority of wood workers...

It leaves out framing carpenters, basically. I could have added patternmakers, timber fitters and so on, but there comes a time when adding to the list just for the sake of adding to the list becomes tedious. I, personally, have never been more than a hobbyist, but I've made my own tools both for woodworking and metalworking. This whole "get it at the store" thing is pretty new, and has mostly to do with building out of nothing but sheet goods using only power tools.
Post reply on HN