minerva icon indicating copy to clipboard operation
minerva copied to clipboard

terminate called after throwing an instance of 'std::out_of_range'

Open RalphMao opened this issue 10 years ago • 7 comments

Here is my python codes:

import owl, numpy a = numpy.zeros((300,400)) b = owl.from_numpy(a)

And it just gave me such an error: terminate called after throwing an instance of 'std::out_of_range' what(): _Map_base::at Aborted (core dumped)

help...

RalphMao avatar Nov 01 '15 12:11 RalphMao

Update: a = owl.ones(3)

It also caused the same error

RalphMao avatar Nov 01 '15 12:11 RalphMao

Hi,

Have you initialized the system and created devices before running the code? You should add codes like:

import sys, owl owl.initialize(sys.argv) gpu = owl.create_gpu_device(0) owl.set_device(gpu)

before running the codes.

Minjie ​

On Sun, Nov 1, 2015 at 7:12 AM, RalphMao [email protected] wrote:

Update: a = owl.ones(3)

It also caused the same error

— Reply to this email directly or view it on GitHub https://github.com/dmlc/minerva/issues/51#issuecomment-152822153.

Minjie Wang New York University | Computer Science 715 Broadway, New York, NY, 10009

jermainewang avatar Nov 01 '15 16:11 jermainewang

I was using the starting script run_owl_shell.sh It gave additional error information: Exception TypeError: "'int' object is not iterable" in 'owl.libowl._list_to_vector' ignored

RalphMao avatar Nov 02 '15 00:11 RalphMao

I have tried it on another machine. The same problem.

RalphMao avatar Nov 02 '15 12:11 RalphMao

OK I find the problem. It does not support the numpy-like way: ones(n) . Anyway I do not think such a problem should cause the python environment to collapse.

RalphMao avatar Nov 02 '15 13:11 RalphMao

Hi,

You are right. This should not cause the python environment to collapse. This is because the current way to support numpy-like operation is by wrapping all the interface by ourselves. However, it is never easy to cover all the interfaces. Therefore, we are now working on another project that directly uses numpy's interface but replace the computation (more efficient) behind the curtain with fallback to original numpy if the computation has not be implemented yet. In such way, the above problem won't happen at all since there is no difference than writing a numpy code. We are actively developing toward this goal. Please stay hold and we will release it as soon as possible.

Thank you for you suggestion!

Minjie

On Mon, Nov 2, 2015 at 8:00 AM, RalphMao [email protected] wrote:

OK I find the problem. It does not support the numpy-like way: ones(n) . Anyway I do not think such a problem should cause the python environment to collapse.

— Reply to this email directly or view it on GitHub https://github.com/dmlc/minerva/issues/51#issuecomment-153010054.

Minjie Wang New York University | Computer Science 715 Broadway, New York, NY, 10009

jermainewang avatar Nov 02 '15 18:11 jermainewang

Wow, that's definitely what I am looking for. I am looking forward to being your first group of users :)

RalphMao avatar Nov 03 '15 15:11 RalphMao