Are you saying that after using these macros, all juli code became slow, even code unrelated to the macro and you had to reinstall Julia?
I find it very hard to believe that this is what actually happened, but if it did that is a serious bug.
1 Like
You could start by testing the code I suggested. It may have bugs, but it’s a start. Next, you can try to only compare the parts of the rays surrounding the changed nodes (making sure the assumption is correct, of course).
After that you could move on to more advanced topics, like creating Ray types and so on.
Hi Mason!.
Yes. it DID happen like that. I tested other silly codes I have… all slower…
I am using JuliaPro… maybe is a bug in that version
Hi DNF.
I tried your comments and it is working very well!
Still need to try the “just compared a part of the ray” idea, cause I did it but it was a bit slower.
I will report back soon!
Thanks for the help
It would be good if you could put together a reproducible example so others can confirm, as Mason says it would be of serious concern if @fastmath (or indeed other macros) would affect completely unrelated code that they’re not being called on.
1 Like
Hi everyone!
I uploaded a Test1.jl (my main code) and the functions and a small input data to:
https://github.com/marianoarnaiz/JULIA
If anyone could help me check it a bit. It is very Matlab-ish because is the only thing I have used before.
All tips are welcome.
The algorithm should take an initial point and final point of a ray (united by a linear path) and bend the 8 nodes in the path to get the minimum traveltime across the velocity (I used slowness) model.
3 Likes
As posted above, I think the code can be cleaner if you take advantage of structures to organize data. One ray could be a structure and all rays a vector of those, instead of those multidimensional matrices.
3 Likes