• @Womble@lemmy.world
    link
    fedilink
    English
    41 month ago

    But how far should that be taken should 8 == 8 return false because one is an unsigned int and the other is signed? Or 0.0 == 0.0 where they are floats and doubles? You can make a case for those due to a strong type system but it would go against most peoples idea of what equality is.

    • @muntedcrocodile@lemm.ee
      link
      fedilink
      English
      11 month ago

      If bits aren’t same then i dont want it to tell me they are the same. And python just has one implementation for int and float.

      I like python cos everything’s an object i dont want different types of objects to evaluate the same they are fundamentally different objects is that not what u would expect?

      • @Womble@lemmy.world
        link
        fedilink
        English
        21 month ago

        Even in python you can have control of what types of numbers are used under the hood with numpy arrays (and chances are if you are using floats in any quantity you want to be using numpy). I would be very surprised if array([1,2,3], dtype=uint8) == array([1,2,3], dtype=int16) gave [False, False, False]. In general I think == for numbers should give mathematical equivalence, with the understanding that comparing floats is highly likely to give false negatives unless you are extremely careful with what you are comparing.

          • @Womble@lemmy.world
            link
            fedilink
            English
            2
            edit-2
            1 month ago

            More Fortran than C, but its the same for any language doing those sorts of array mathematics, they will be calling compiled versions of blas and lapack. Numpy builds up low level highly optimised compiled functions into a coherant python ecosystem. A numpy array is a C array with some metadata sure, but a python list is also just a C array of pointers to pyobjects.