Implement ndarray binary, unary and compare operators #390

derppening · 2024-03-28T01:12:55+08:00

derppening commented

2024-03-28 01:12:55 +08:00

Omissions (will be implemented in a separate PR):

Matrix multiplication
Chained comparison (e.g. 1 < 2 < np_identity(2))

Omissions (will be implemented in a separate PR): - Matrix multiplication - Chained comparison (e.g. `1 < 2 < np_identity(2)`)

derppening added 17 commits 2024-03-28 01:12:55 +08:00

c9d21abb96 core: Fix index-based operations not returning i32

c90724c738 core/builtins: Fix len() on ndarrays

8de76510ed core: Use more typed slices in APIs

2734a38635 core: Remove ArrayValue variants of accessors

0636398f3c core: Extract codegen portion of gen_binop_expr

This allows binops to be generated internally using LLVM values as
input. Required in a future change.

160cfa500a core/typedef: Add Type::obj_id to replace get_obj_id

d47c18bdcb core/helper: Add PrimitiveDefinitionIds::iter

cf482cdeac core/magic_methods: Allow unknown return types

These types can be later inferred by the type inferencer.

eb56259005 core/type_inferencer: Allow both int32 and isize when indexing ndarray

cd9fdf3bad core: Implement calculations for broadcasting ndarrays

4e4a61d4ac core/toplevel/numpy: Split ndarray type var utilities

e89bab64c8 core/magic_methods: Add typeof_*op

Used to determine the expected type of the binary operator with
primitive operands.

1f0ac6341d core: Implement elementwise binary operators

Including immediate variants of these operators.

0537e816a5 core/codegen/expr: WIP - Split unaryop

5450147007 core: Implement elementwise unary operators

d457e6c986 core/codegen/expr: WIP - Split cmpop

29ae48faad core: Implement elementwise comparison operators

derppening force-pushed enhance/issue-149-ndarray/operators from 29ae48faad to e69fab866c

2024-04-01 17:35:07 +08:00

Compare

derppening force-pushed enhance/issue-149-ndarray/operators from e69fab866c to 847d19077e

2024-04-02 16:56:58 +08:00

Compare

derppening changed title from ~~WIP: Implement ndarray binary, unary and compare operators~~ to Implement ndarray binary, unary and compare operators

2024-04-02 16:57:12 +08:00

derppening requested review from sb10q 2024-04-02 16:57:16 +08:00

sb10q reviewed 2024-04-02 16:59:04 +08:00

nac3core/src/toplevel/builtins.rs Outdated

													
				@ -524,6 +545,20 @@ pub fn get_builtins(primitives: &mut (PrimitiveStore, Unifier)) -> BuiltinInfo {

				            methods: vec![

				                ("copy".into(), ndarray_copy_ty.0, DefinitionId(PRIMITIVE_DEF_IDS.ndarray.0 + 1)),

				                ("fill".into(), ndarray_fill_ty.0, DefinitionId(PRIMITIVE_DEF_IDS.ndarray.0 + 2)),

				                ("__add__".into(), ndarray_add_ty.0, DefinitionId(PRIMITIVE_DEF_IDS.ndarray.0 + 3)),

sb10q commented

2024-04-02 16:59:04 +08:00

All this manual and error-prone definitionid allocation will have to be cleaned up at some point.

sb10q reviewed 2024-04-02 17:00:32 +08:00

nac3core/src/symbol_resolver.rs Outdated

													
				@ -233,0 +246,4 @@

				    }

				}

				impl TryFrom<SymbolValue> for i128 {

sb10q commented

2024-04-02 17:00:32 +08:00

Why do we need i128 anywhere?

derppening commented

2024-04-03 16:41:29 +08:00

Poster

Copied with the conversation in Mattermost:

it's for implicit promotion for const generics. currently, the ndims typevar for ndarray is implemented either as a u32 or u64 depending on the size of size_t of the target platform, so i thought it would make more sense that ndarray[float, 1] could be implicitly promoted into ndarray[float, uint64(1)] while also preserving compile-time checks (as it is a compile-time constant)

then, in the unifier implementation, i just need to cast the expected and actual const generic type into a common numeric type (in this case, i128), to check whether they are compatible

[we don't use u64 as the common type because] const generics can also be signed numbers, and u64 cannot represent signed numbers

i128 is used in the implementation of the unifier, so the common integral type needs to take into consideration future code that may use signed const generics as well

Copied with the conversation in Mattermost: > it's for implicit promotion for const generics. currently, the `ndims` typevar for `ndarray` is implemented either as a `u32` or `u64` depending on the size of `size_t` of the target platform, so i thought it would make more sense that `ndarray[float, 1]` could be implicitly promoted into `ndarray[float, uint64(1)]` while also preserving compile-time checks (as it is a compile-time constant) > > then, in the unifier implementation, i just need to cast the expected and actual const generic type into a common numeric type (in this case, `i128`), to check whether they are compatible > > [we don't use `u64` as the common type because] const generics can also be signed numbers, and `u64` cannot represent signed numbers > > `i128` is used in the implementation of the unifier, so the common integral type needs to take into consideration future code that may use signed const generics as well