- std::sort-issue - 13 Updates
- Strong typedefs. - 4 Updates
| Bonita Montero <Bonita.Montero@gmail.com>: May 21 03:42PM +0200 I've got a strange sorting-problem: I've got an array of uintptr_t's. This area is halfed so that the first half contains a number of hashes and the second half contains a number of pointers. Both arrays should be sorted against the hash. But if I give std::sort the pointers to the first array the swapping on the second array obviously doesn't happen. So how do I incorporate the second array in the sort? I don't see a solution. |
| Paavo Helde <eesnimi@osa.pri.ee>: May 21 05:39PM +0300 21.05.2020 16:42 Bonita Montero kirjutas: > But if I give std::sort the pointers to the first array the swapping on > the second array obviously doesn't happen. So how do I incorporate the > second array in the sort? I don't see a solution. This is a table sort, you want to sort two columns by a common order. For that you first sort an array of indices iota(0, N) (complexity O(N*log(n)), then reorder both columns to the new order (2*O(n)). |
| Bonita Montero <Bonita.Montero@gmail.com>: May 21 06:47PM +0200 >> second array in the sort? I don't see a solution. > This is a table sort, you want to sort two columns by a common order. > For that you first sort an array of indices iota(0, N) ... That would involve rearrangement afterwards. I've found a more efficient solution; but thanks. |
| Paavo Helde <eesnimi@osa.pri.ee>: May 21 09:48PM +0300 21.05.2020 19:47 Bonita Montero kirjutas: >> For that you first sort an array of indices iota(0, N) ... > That would involve rearrangement afterwards. > I've found a more efficient solution; but thanks. If you have found a more efficient solution to sort things than O(N*log(N)), then please let us know. This would mean a major breakthrough in computer science! |
| Bonita Montero <Bonita.Montero@gmail.com>: May 21 08:57PM +0200 >> I've found a more efficient solution; but thanks. > If you have found a more efficient solution to sort things than > O(N*log(N)), then please let us know. ... That wasn't what I said. You can't read. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 21 12:06PM -0700 On 5/21/2020 11:57 AM, Bonita Montero wrote: >> If you have found a more efficient solution to sort things than >> O(N*log(N)), then please let us know. ... > That wasn't what I said. You can't read. Why are so nice? |
| Bonita Montero <Bonita.Montero@gmail.com>: May 21 09:10PM +0200 >> That wasn't what I said. You can't read. > Why are so nice? If he wants to sell me as stupid I'll return the favor. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 21 09:12PM +0200 > Why are so nice? BTW: Have you tried my code and found appropriate parameters that prove that mutex-spinning makes sense ? This program would be anything you need if Öö Tiib's assumptions were correct. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 21 12:20PM -0700 On 5/21/2020 12:12 PM, Bonita Montero wrote: > BTW: Have you tried my code and found appropriate parameters that > prove that mutex-spinning makes sense ? This program would be anything > you need if Öö Tiib's assumptions were correct. I have performed many tests way back with all sorts of mutexes, almost 20-years ago. A highly contended lock for a short critical section, say mutating two or three variables. Well, an adaptive mutex is usually beneficial by being able to skip many calls into the OS for blocking. Aka, trying to avoid the slow path! Any time a call into the kernel is avoided, is a good time... ;^) Spinning a couple of times is much better than going to the kernel to actually block in these types of scenarios. Btw, spinning can be used to try other things rather than just execute a pause instruction. A try_lock can be used to try other things before trying to lock again... ;^) |
| Bonita Montero <Bonita.Montero@gmail.com>: May 21 09:23PM +0200 > avoided, is a good time... ;^) > Spinning a couple of times is much better than going to the kernel to > actually block in these types of scenarios. That's not a proof. Give me the parameters for my program to prove this! The timing-loop is one loop per clock-cycle on any OoO-CPU of the last 20 years so that I could verify that on my computer. |
| Ian Collins <ian-news@hotmail.com>: May 22 08:10AM +1200 On 22/05/2020 07:06, Chris M. Thomasson wrote: >>> O(N*log(N)), then please let us know. ... >> That wasn't what I said. You can't read. > Why are so nice? Why do you keep feeding it? |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 21 01:38PM -0700 On 5/21/2020 1:10 PM, Ian Collins wrote: >>> That wasn't what I said. You can't read. >> Why are so nice? > Why do you keep feeding it? Its strange. She keeps making me remember things from the past. |
| The Real Non Homosexual <cdalten@gmail.com>: May 21 03:00PM -0700 FIGHT FIGHT |
| Daniel P <danielaparker@gmail.com>: May 20 05:05PM -0700 On Wednesday, May 20, 2020 at 7:07:16 PM UTC-4, Öö Tiib wrote: > Same [did not observe significant benefits] happened with enum class when > used as kind of strong typedef of underlying type. Idea feels good but > reality does not confirm it. What do you think of std::byte? Did we need that? Daniel |
| "Öö Tiib" <ootiib@hot.ee>: May 20 11:51PM -0700 On Thursday, 21 May 2020 03:06:03 UTC+3, Daniel P wrote: > > used as kind of strong typedef of underlying type. Idea feels good but > > reality does not confirm it. > What do you think of std::byte? Did we need that? I again like the idea. What std::byte hopefully fixes is for example that the raw chars are source of illusions as these are eagerly and silently promoted to signed int by most operations. Since if char is signed or not is implementation defined result of such promotion is also implementation defined. But by C++17 the std::byte was made worse. It said that: | A value of integral or enumeration type can be explicitly converted | to a complete enumeration type. The value is unchanged if the original | value is within the range of the enumeration values (10.2). Otherwise, | the behavior is undefined. Where char was signed there half of direct conversions of char to std::byte were formally undefined behavior. However most raw data from most APIs are chars. So some implementation-defined illusions blocked but even worse undefined behaviors added. That is fortunately fixed in C++20. Above kind of illustrates my uncertainly about such things, everything tends to enter standard with good promises but on closer inspection with even worse bear traps attached. |
| The Real Non Homosexual <cdalten@gmail.com>: May 21 10:36AM -0700 I think you all just confused that dumbass Thiago. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: May 21 06:23PM On Thu, 2020-05-21, The Real Non Homosexual wrote: > I think you all just confused that dumbass Thiago. A tip: repeated posts like that one makes /you/, not Thiago, look bad. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment