Replies: 1 comment 5 replies
-
|
Does it work if you turn parallelism off? i.e., |
Beta Was this translation helpful? Give feedback.
-
|
We had tried Here is our PySRRegressor object... model = PySRRegressor(
niterations=10, # < Increase me for better results
populations= 10,
binary_operators=["+", "*", "/", "-"],
unary_operators=[
"exp",
# "inv(x) = 1/x",
# "square"
# "sqrt"
],
maxsize=7,
nested_constraints={"exp": {"exp":0}},
bumper= False,
extra_sympy_mappings={"inv": lambda x: 1 / x},
procs=0,
multithreading=False,
# ^ Define operator for SymPy as well
# elementwise_loss="loss(prediction, target) = (prediction - target)^2",
# ^ Custom loss function (julia syntax)
loss_function= "my_custom_objective",
equation_file="/export/zimmerman/soumikd/symbolic_regression/cheml-pysr/tests/test_data/test.csv"
) |
Beta Was this translation helpful? Give feedback.
-
|
Hm. Maybe try turning off the following line in your local copy of PySR? Line 1746 in 476f573 This line turns off PythonCall garbage collection – required for doing any multithreading stuff in Julia, but perhaps it causes memory issues if you are trying to call back into Python? I'm not really sure. |
Beta Was this translation helpful? Give feedback.
-
|
By the way, I should say I would try to avoid Python if you can. The speed of the loss function is quite important, and calling Python every single time is going to be super super slow. So in addition to the memory issues you are seeing, it might also help with speed. Unless you HAVE to call Python. But if you don't, I would try to translate your loss function to Julia if possible. A lot of the stuff you can probably just do directly on the equation type using the utility functions. Make a new discussion thread if you want some help. Converting to SymPy every step is a bit overkill and will result in like a 10,000x slowdown. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for your feedback. We're considering both numerically computed asymptotic constraints like mentioned here as well as symbolic asymptotic constraints. We figured there would be a penalty in cost per evaluation for symbolic evaluation but that more accurate feedback might reduce the number of iterations necessary so we planned to benchmark both. But we didn't realize the cost would be so dramatic. If you're confident that evaluating the loss function would become a prohibitively expensive bottleneck if we call back into python / sympy, we could try to stick to what can be quickly evaluated in Julia. I just found this pull request that looks like it has similar goals to some of the things we're trying to do. |
Beta Was this translation helpful? Give feedback.
-
I am pretty confident that this is true. calling into python within the loss function will be a massive bottleneck. Especially if it is SymPy code which is mostly pure-Python based (rather than a Python library with a compiled backend like numpy). Better to operate directly on the equation datatype (just post another thread describing what you want to do and maybe I or others can help). Worst case you could try SymbolicUtils.jl. It will be a bit slower than sticking with the Node type but it’s more SymPy-like. |
Beta Was this translation helpful? Give feedback.
-
I'm working with @SoumiKDaS1701 trying to customize PySR to constrain aspects of the generated functions like the asymptotic limit or its derivative at long range. In order to do this, we're trying to call sympy inside of a custom loss function using PythonCall which seems like the inverse of how PySR calls into Julia. Here's our code, which looks similar to this example.
Both of us are new to Julia and the interfacing between Python and Julia so we're having some difficulty getting this to work.
Our immediate issue is getting a segmentation fault which might be related to this issue
We would appreciate some guidance either on this specific issue or more broadly on how we would go about constraining the functions generated by PySR based on analytical properties.
Beta Was this translation helpful? Give feedback.
All reactions