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 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

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