Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Dec 05 17:06
    mfherbst synchronize #552
  • Dec 05 17:06

    mfherbst on kpoint_refactor

    Update docs (compare)

  • Dec 05 17:04
    mfherbst synchronize #552
  • Dec 05 17:04

    mfherbst on kpoint_refactor

    Opportunity for enumerate Save on computing qs (compare)

  • Dec 05 16:49
    mfherbst synchronize #552
  • Dec 05 16:49

    mfherbst on kpoint_refactor

    Opportunity for enumerate (compare)

  • Dec 05 16:38
    mfherbst synchronize #552
  • Dec 05 16:38

    mfherbst on kpoint_refactor

    Save on computing qs (compare)

  • Dec 05 16:23
    mfherbst synchronize #552
  • Dec 05 16:23

    mfherbst on kpoint_refactor

    More refactor (compare)

  • Dec 04 09:45
    mfherbst synchronize #552
  • Dec 04 09:45

    mfherbst on kpoint_refactor

    Fancy G+k (compare)

  • Dec 03 21:30

    mfherbst on kpoint_basis_ref

    (compare)

  • Dec 03 20:27
    mfherbst opened #552
  • Dec 03 20:26

    mfherbst on kpoint_refactor

    Remove model from Kpoint struct… (compare)

  • Dec 03 20:25

    mfherbst on kpoint_refactor

    Fixup wannier example (compare)

  • Dec 03 20:23

    mfherbst on kpoint_refactor

    Remove model from Kpoint struct… Fixup wannier example (compare)

  • Dec 03 19:30
    mfherbst ready_for_review #551
  • Dec 03 19:21
    mfherbst synchronize #551
  • Dec 03 19:21

    mfherbst on eneops_refactor

    Refactor ene_ops interface Annotate more types in operators Fixes and 2 more (compare)

Antoine Levitt
@antoine-levitt
Awesome! Error handling for spglib is not so important...
Michael F. Herbst
@mfherbst
Yes thanks for the PR! Awesome work. I made a few review comments ... I hope I'm not being too picky on you!
Louis Ponet
@louisponet
I've fixed them, running tests now!
There was one thing I was wondering about, in general I always tend to add types to the arguments in my code (didn't do it now because it seems in DFTK in general that's not done), because it kind of helps me to understand what a function expects me to throw in. Is this a deliberate choice not to do that in DFTK?
Michael F. Herbst
@mfherbst
yes it is. The less types you put the more flexible is your interface
Louis Ponet
@louisponet
yea, I agree on that, but wouldn't it make sense to the add the widest type allowed rather than basically ::Any?
Michael F. Herbst
@mfherbst
so if you (or someone else) implements an interface which deliberately or by accident resembles let's say an Array interface or a matrix or something like that that the code will just work
well but doing nothing is equivalent to ::Any
Ah sorry ... misunderstood
well no because the point is that you want to decouple the brain of the developer as much as possible from the brain of the user
Louis Ponet
@louisponet
this is for example one of the issues I have very often working with python code, I look at a function and it's arguments, and I have no clue what it expects of me
then I need to go through the function body to understand what it's doing
Michael F. Herbst
@mfherbst
just because you think that should be an AbstractArray does not mean that I as the user intend to use it with an AbstractArray. But if the code still works with my user defined type than it's really annoying if the type annotation prevents it
well ideally the function and argument name makes it clear
or the documentation
but in DFTK we also follow the philosophy that our code should be an open book
so we actually expect and encourage people to read the code in order to understand what is going on
also we follow conventions in the argument names (or we try to)
so that it is clear just from the argument name what sort of thing is expected
Louis Ponet
@louisponet
on the first point I'd say that then the user probably should be subtyping AbstractArray anyway
Michael F. Herbst
@mfherbst
not neccessarily
Louis Ponet
@louisponet
hmm yea I mean I can see both sides
Michael F. Herbst
@mfherbst
in my opinion what makes julia more flexible than C++ or python is exactly that the interfaces are not set in stone
rather they are conventions
and if I just want to quickly try something quick and dirty
I do not want to spend 30min to look up and satisfy the interface
so without type annotations I don't have to fully do an AbstractArray
I just implement what is needed and I am ready to go
to do it properly in library code of course you should follow the convention
but that's the second step from my point of view
first get it to work, then get it fast and clean ;)
Louis Ponet
@louisponet
Yea, that's the idea but in reality often I get errors at some part of the code because I didn't throw in the thing that the code expected
Michael F. Herbst
@mfherbst
sure but then you just implement that extra bit
eventually you will have the full interface
but on the way you already got at least some stuff to work
I agree that it is two sides of the coin
Louis Ponet
@louisponet
Okay, then I'll follow that idea for other things I may implement :) but personally I still think just having types on the arguments is like a part of documentation on it's own almost
Michael F. Herbst
@mfherbst
I often had it the other way round with strongly object-oriented code that I needed my object to satisfy two interfaces to work with certain codes, but there were conflicts ...
Louis Ponet
@louisponet
but indeed if the argument's name makes clear what is expected that ofcourse also works
I see
well I'd say that's just shit code then ;D
Michael F. Herbst
@mfherbst
Agree, but sometimes you don't have a choice in science
Louis Ponet
@louisponet
true
Michael F. Herbst
@mfherbst
and better you can hack something and get a PhD, rather than rewrite a library for that reason
Louis Ponet
@louisponet
haha agreed
Michael F. Herbst
@mfherbst
actually I think what is most important is that the philosophy of the code agrees with the philosophy of the language
and julia definitely went the route of "only type when needed"
Louis Ponet
@louisponet
But isn't the philosophy of Julia exactly to type as strong as needed but not stronger?
Michael F. Herbst
@mfherbst
just look at the standard library
exactly