Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 02:52
    harrisonlabollita synchronize #496
  • Jul 26 21:29
    umbriquse commented #504
  • Jul 26 16:25
    umbriquse commented #504
  • Jul 26 16:15
    mfherbst commented #504
  • Jul 26 16:01
    umbriquse commented #504
  • Jul 26 15:57
    umbriquse commented #504
  • Jul 26 15:53
    umbriquse commented #504
  • Jul 26 15:41
    antoine-levitt commented #504
  • Jul 26 15:16
    umbriquse opened #504
  • Jul 26 14:58
    mfherbst synchronize #496
  • Jul 26 14:56
    mfherbst synchronize #496
  • Jul 26 09:50
    antoine-levitt synchronize #487
  • Jul 26 09:50

    antoine-levitt on stresses_API

    remove extra functions (compare)

  • Jul 26 09:22
    mfherbst commented #496
  • Jul 26 09:07
    mfherbst commented #496
  • Jul 26 09:07
    mfherbst commented #496
  • Jul 26 09:06
    mfherbst commented #487
  • Jul 26 09:01
    antoine-levitt commented #496
  • Jul 26 09:00
    mfherbst commented #496
  • Jul 26 09:00
    mfherbst commented #496
Michael F. Herbst
@mfherbst
By the way: Be careful about the ordering. spglib uses a different convention for the ordering of the lattice vectors and cell objects in C++ and python, see https://spglib.github.io/spglib/python-spglib.html#crystal-structure-cell
Louis Ponet
@louisponet
yea, column vs row right? In DFTK I think it's also column?
Antoine Levitt
@antoine-levitt
Yes like in Julia
Louis Ponet
@louisponet
I think I've got spglib work, except for the error messages part
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