|
From: | Markus Mützel |
Subject: | [Octave-bug-tracker] [bug #60818] delaunayn - 2D code path vectorization doesn't match nD algorithm |
Date: | Tue, 29 Jun 2021 13:05:47 -0400 (EDT) |
User-agent: | Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.114 Safari/537.36 Edg/91.0.864.59 |
Update of bug #60818 (project octave): Status: None => In Progress _______________________________________________________ Follow-up Comment #8: That is a pity. It could probably have saved a lot of work, had we found bug #53942 before. Sorry for not noticing earlier. There are probably a lot of other good patches on the tracker that went unnoticed for years. With respect to the patch here. I haven't tested it as of now. But I am wondering why it is possible to check all simplices against the same `eps(max(R))`. The previous algorithm used a reference that was different for each simplex. But maybe I am missing something obvious. The patch did apply for me. I amended it with a few comments and fixed what I think was a minor inaccuracy in the 2-D case. See the attachment. Is that all OK? We might want to tweak the introductory comment a bit more once I better understand the part about `eps(max(R))`. If the number of simplices is very high, would it make sense to break the calculation into subsets of these simplices and use the new algorithm for each subset? Or is this overkill? (file #51624) _______________________________________________________ Additional Item Attachment: File name: bug60818-delaunayn-v2.patch Size:3 KB <https://file.savannah.gnu.org/file/bug60818-delaunayn-v2.patch?file_id=51624> _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?60818> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/
[Prev in Thread] | Current Thread | [Next in Thread] |