2 ms·

> What would e.g. happen if you mix both types? Like in int32 y=INT_MAX mod32 x=1 y+=x ? You'd get y==INT_MAX. Or did you mean something more involved

> What would e.g. happen if you mix both types? Like in int32 y=INT_MAX mod32 x=1 y+=x ? You'd get y==INT_MAX. Or did you mean something more involved ? > you can overload the + operator I fail to see the need. (Sorry I'm a bit tired). In this thread context of static languages, your compiler knows the target type of an assignement (clip/mod) and so applies the right correction. > in python there's simply no overflow, every int is an object that can be as big as needed I guess there's a huge speed penalty in wrapping values into objects.

nuancebydefault 3y ago
I'm not sure if the target type is always clear. Y=(x+x)+y What is the target type for x+x? You could argue that you can have the same problem with operator overloading. But then again, it is best to implement the class just for a specific (type of) algo whithin which you use the overloaded + operator (or maybe better another symbol, resembling a + sign) in an unambiguous way. Also the class might have more functionality specifically suited for that type of algo. The benifits are less ambiguity and, that normal operations keep being fast (directly use the cpu arithmetic functions); the code is only slower where clipping or something the like is needed. Python is indeed slow and resource intensive, that's where libraries like numpy fit in. It uses vectorized native types (numpy ints and floats are native machine types), together with vector operations running in a precompiled low level language. Python only sees the 'outside' of the vectors as python objects. I once wondered why my language did not have native support for fixed point type operations. Once i started implementing custom types for and a class supporting fixed point, i noticed the sheer amount of design choices that were needed. A concise generic implementation of it is nearly impossible.
- alcover 3y ago
  (Hoping you see this. HN's lack of reply-alert is not super practical) > What is the target type for x+x? There's no 'target' except the assigned 'y'. The compiler would just do y = CLIP((x+x)+y) with x and y cast to int64 in the expression or smth like this. > i noticed the sheer amount of design choices that were needed I was just imagining these types. You are most certainly right that it would be pretty involved to get right.
  - nuancebydefault 3y ago
    Okay that type of 'target' i have never seen in pactice, it would mean that if you would write the same equation using 2 statements, the casting would be different because you then would have 2 targets. Anyway, there are endless ways of designing a language, all with pros and cons. Nice exercise of thought.

nuancebydefault 3y ago

I'm not sure if the target type is always clear. Y=(x+x)+y What is the target type for x+x? You could argue that you can have the same problem with operator overloading. But then again, it is best to implement the class just for a specific (type of) algo whithin which you use the overloaded + operator (or maybe better another symbol, resembling a + sign) in an unambiguous way. Also the class might have more functionality specifically suited for that type of algo. The benifits are less ambiguity and, that normal operations keep being fast (directly use the cpu arithmetic functions); the code is only slower where clipping or something the like is needed. Python is indeed slow and resource intensive, that's where libraries like numpy fit in. It uses vectorized native types (numpy ints and floats are native machine types), together with vector operations running in a precompiled low level language. Python only sees the 'outside' of the vectors as python objects. I once wondered why my language did not have native support for fixed point type operations. Once i started implementing custom types for and a class supporting fixed point, i noticed the sheer amount of design choices that were needed. A concise generic implementation of it is nearly impossible.

alcover 3y ago
(Hoping you see this. HN's lack of reply-alert is not super practical) > What is the target type for x+x? There's no 'target' except the assigned 'y'. The compiler would just do y = CLIP((x+x)+y) with x and y cast to int64 in the expression or smth like this. > i noticed the sheer amount of design choices that were needed I was just imagining these types. You are most certainly right that it would be pretty involved to get right.
- nuancebydefault 3y ago
  Okay that type of 'target' i have never seen in pactice, it would mean that if you would write the same equation using 2 statements, the casting would be different because you then would have 2 targets. Anyway, there are endless ways of designing a language, all with pros and cons. Nice exercise of thought.