Dear all. Thanks for creating NuMojo. I have some issues, and perhaps this is just due to the early stage of this project, but i'll submit this anyway.

Describe the bug
All array operations involving slices seem to fail.

To Reproduce

import numojo as nm


def main():
    var A = nm.NDArray[nm.f64](shape=List[Int](3,3), random=True)

    # These work as expected
    print(A.mean())
    print(nm.math.stats.meanall(A))
    print(nm.math.stats.sumall(A))
    print(A.cumsum())
    
    # All these operations throw the same error
    #nm.math.stats.min(A) # Does not work
    #nm.math.stats.prod(A,axis=0) # Does not work
    #nm.math.stats.sum(A, axis=0) # Does not work
    #A.sum(axis=0) # Does not work
    #nm.math.stats.mean(A) # Does not work

and the resulting error message is this

/NuMojo/numojo/core/ndarray.mojo:1341:9: error: @stdlib::@builtin::@builtin_slice::@Slice::@"__copyinit__(stdlib::builtin::builtin_slice::Slice=&,stdlib::builtin::builtin_slice::Slice)_thunk" does not reference a KGEN declaration
mojo: error: failed to run the pass manager

Expected behavior
Being able to calculate mean along a given axis, fetching elements using slices etc.

Desktop (please complete the following information):

• OS: MacOS 14.6.1
• Latest Mojo version
• VSCode

Currently, the default data type of a NDArray is DType.float32. This is somehow different from numpy which uses float64 as default type. For example, numpy.ones().

I am wondering whether it would be nice to change the default data type of NDArray from float32 to float64 also for numojo, so that it is aligned with numpy and is of higher precision.

I do not think it is a top priority but we can have an open discussion on this.

The Mojo team has confirmed in the nightly changelog that they will deprecate the DTypePointer, and they suggest migrating to UnsafePointer.

They have also changed the methods of the UnsafePointer.

This will require to change the way we initialize the pointers for the data of the NDArrays.

I can help on the migration using Max Nightly for the NDArray struct.

Current situation

Currently, the dimension of the ndarray is inferred from the shape at the run time. This would lead to extra cost.

Proposal

As the dimension is known at initialisation, it might be nice to make ndim a parameter and known at compile time. Example:

var NDArray[2, DType.float64](1000, 1000, random=True)  # Creating a 1000x1000 2-D array (matrix)

Additional benefits

Making dimension a parameter at compile time may have additional benefits. For example, we can define alias to NDArrays more easily.

alias Vector = NDArray[1, _]
alias Matrix = NDArray[2, _]

Not too difficult to accomplish and would improve releases

To reduce the number of initializer overloads for ndarray we could take the __inits__ that are identical other than having either random or fill and make initializers that default to filling with zeros, and do not allow for the fill to be nonzero if the random argument is true.

fn __init__( inout self, *shape: Int, random: Bool = False, order: String = "C" ) raises:

and

fn __init__( inout self, *shape: Int, fill: Scalar[dtype], order: String = "C" ) raises:

becomes

fn __init__( inout self, *shape: Int, fill: Scalar[dtype]=0, random:Bool=False, order: String = "C" ) raises:
    if random == True and fill !=0:
        raise Error("numojo/core/ndarray:NDArray: __init__(*shape, fill, random)): Error if random is true you cannot set a fill value")

This would turn 8 of our initializers into 4 thus reducing our number of initializers from 14 to 10.

Thoughts?

Describe the bug
Creating a NDArray by specifying the data and shape raises an error that both keyword arguments are unknown.

To Reproduce

var array = nm.NDArray[nm.f32](data=List[Int](1,2,3,4,5,6), shape=List[Int](2,3))

Error raised:

error: Expression [4]:2:31: no matching function in initialization
var array = nm.NDArray[nm.f32](data=List[Int](1,2,3,4,5,6), shape=List[Int](2,3))
            ~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Expression [0] wrapper:17:5: candidate not viable: unknown keyword arguments: 'data', 'shape'

Screenshots

This proposal is for long term.

Situation

Currently, we have many overloads for __init__() of NDArray struct. On the one hand, overload is a good feature that allows more flexibility. On the other hand, it prevents developers/users conveniently checking the arguments during programming, and it means that we are using different overloading functions in other functions/modules. This causes ambiguity and difficulties in maintenance. Thus, we should try to avoid using overloads unless it is necessary.

Solution

For numpy, the solution is quite straightforward: there is only one initializer, which reads in (1) shape (tuple), (2) buffer (can left empty), (3) order (C or F), etc. For other constructors (fill a value, randomize, from string), use separate construction functions.

This makes the function signature clear and makes the ndarray type a pure container.

I think we can also follow this. For NDArray, we only keep ONE initializer: fn __init__[dtype](shape, buffer, order). All other constructors should be included in the module array_creation_routines.

Obstacle

The biggest obstacle at the moment is that the Tuple type is not iterable. This means that we cannot calculate size, strides, etc, from the shape (as Tuple). In future, when Tuple becomes iterable, we can completely align the arguments with numpy.

Hello,

First off, thanks for taking on the project of making Mojo's version of Numpy! For the issue I'm seeing, there seems to be something going on when calling the array.dim_list.__getitem__() method for the ndarray implementation. After calling the function once, the next call balloons to a large number (ex. in my case 1.4e14). This becomes extremely problematic when calling the array.arr_print() function as the loop is now out of bounds for the size of the array. Below is the code I used to created the issue:

from ndarray.arraynd import Array
alias array = Array[DType.float64, 4]
let f64funcs = array()

var x = f64funcs .zeros(10)

print(x.size) # -> 10

print(x.tshape[0], x.tshape[1]) # -> 10, 0

# first call to __getitem__
print(x.dim_list[0]) # -> 1

# second call to __getitem__
print(x.dim_list[0]) # -> 140378715213677

# third call to __getitem__
print(x.dim_list[0]) # -> 140378715213677

I'm not sure if this is an issue with the VariadicList during initialization or during each function call, or something else. I know this package is in its infancy, but I just wanted to bring this to your attention.

Thank you for your time and please let me know if there's any additional information you need. (First time submitting one of these!)

I would like to know if possible to change the behavior of sort() in an array to make it an inplace method.

The expected behavior would be like:

var array = nm.NDArray[nm.i64](List[Int64](8, 3, 5, 7, 2, 1, 4, 6), shape=List[Int](8))
array.sort()
print(array)

[Output]: 
[	1	2	3	...	6	7	8	]
Shape: [8]  DType: int64

I understand that there are times when you don't want to change the original array and the intention is to create a new array, but renaming the current sort() to sorted() may be an option.

Let me know what you think