Pysyft: Remove Numpy from LargePrecisionTensor

[iamtrask]

Is your feature request related to a problem? Please describe.
We cannot use LargePrecisionTensor for remote executions or within plans if it depends on numpy.

Describe the solution you'd like
Implement the same functionality without using numpy. In other words, remove the numpy import from this file.

https://github.com/OpenMined/PySyft/blob/b0b8a13524150002524c15c6c283b4b14de62d40/syft/frameworks/torch/tensors/interpreters/large_precision.py

Describe alternatives you've considered
Hooking numpy is also an option, but it's not one we want to consider at the moment because it adds a great deal of complexity to intentionally use multiple frameworks.

[systemshift]

I can work on this, please assign me the issue.

[bharatnishant]

@iamtrask Does removing numpy import implies the use of an alternate library or making alternate implementation?

[systemshift]

@iamtrask Does removing numpy import implies the use of an alternate library or making alternate implementation?

Ideally to reimplement without importing any other library, but I've been scratching my head how replace numpy arrays with python lists without increasing code complexity too much, but I still believe this is still best approach.
The other option is to hook numpy, as mentioned above, but that should be our last option.

I have been looking at other options but nothing stands out, and I don't think it would be wise to add a new dependency just to solve this one issue.

[LaRiffle]

From what I experienced, when we don't use numpy tensor ops we use torch ones which is ok but put a big dependency on pytorch (we from an historical point of view of pysyft is 100% ok)

However, I have also the feeling that some expressions (in particular crypto protocols) are better expressed using numpy which is way faster (I'm working on one where I have a 10 times improvements). Additionally numpy is independent from the GAFAs^^

[iamtrask]

The top priority is cross platform support and Plan/Promise support, both of which numpy prevents. Using Torch tensors instead does not.

Sent from my iPhone

On 12 Jan 2020, at 10:13, Théo Ryffel [e-mail] wrote:


From what I experienced, when we don't use numpy tensor ops we use torch ones which is ok but put a big dependency on pytorch (we from an historical point of view of pysyft is 100% ok)

However, I have also the feeling that some expressions (in particular crypto protocols) are better expressed using numpy which is way faster (I'm working on one where I have a 10 times improvements). Additionally numpy is independent from the GAFAs^^

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

[mccorby]

If I remember correctly, we had to use numpy to work with very large numbers as it was not possible to implement the basic operations by using only the representation in smaller tensors of those numbers.

_internal_representation_to_large_ints: This is where we should put the focus to remove numpy. If we could have a tensor(dtype=object) then it could easy to replace numpy.

[karlhigley]

Is this a situation where PyTorch's new support for extending tensors would make this easier/simpler?

[LaRiffle]

Yeah - and I loop here again with the suggestion that if LargePrecision is not used it should be archived for the moment it would make our life simpler, @mccorby any thoughts?

[iamtrask]

Is this a situation where PyTorch's new support for extending tensors would make this easier/simpler?

Sadly no

[iamtrask]

Yeah - and I loop here again with the suggestion that if LargePrecision is not used it should be archived for the moment it would make our life simpler, @mccorby any thoughts?

Is it not being uesd?

[mccorby]

It is used when creating shares bigger than 2**62. If the new TensorBigInt does the same, it won't be necessary.
Initially LPT was necessary to allow these operations with big ints in the JVM.

I'll create a PR to delete it.

[mccorby]

Just in case, CRT is also using numpy

[mccorby]

Fixed in #2907