remove std_ prefix from math library

[rachitnigam]

No description provided.

[rachitnigam]

Hm, the current problem with this is the relay backend generates the functions with the same name as the input relay function. This means that the sqrt call in sqrt.relay generates a component called sqrt which conflicts with the definition of sqrt imported from the library. @cgyurgyik any thoughts on how to fix this? We could come up with a naming convection for the methods generated from the relay frontend.

[cgyurgyik]

Hm, the current problem with this is the relay backend generates the functions with the same name as the input relay function. This means that the sqrt call in sqrt.relay generates a component called sqrt which conflicts with the definition of sqrt imported from the library. @cgyurgyik any thoughts on how to fix this? We could come up with a naming convection for the methods generated from the relay frontend.

Haha yep that's initially why I threw on the std_ prefix. Naming convention for components seems like an easy fix. Perhaps just some type of prefix appended (given its pretty simple), such as r_, which isn't very informative, but is short. I'm open to better suggestions. I wonder how difficult a less error-prone solution would be, such as:

component relay::sqrt(...) -> (...) { ... }

, or

relay {
  component sqrt(...) -> (...) { ... }
}

I imagine this won't be the last time where name collisions occur.

[rachitnigam]

Name resolution is hairy business. If we aren't careful with it, it can get complicated. This also ties into @sampsyo's discussion on modules. Maybe we can start a thread there.

[cgyurgyik]

As suggested, the Relay components now have their arity appended, e.g. relu with output Tensor[1, 10] will be named: relu_1_10.

[rachitnigam]

Great, thanks!