Leaderboard

In machine code, an INC(rement) opcode (or an ADD, for that matter) acting on a register (assuming your int is already loaded into that register) or memory location is itself atomic, taking one clock cycle (or tick) on an ALU (which is part of your CPU), and depending on your architecture, multiple INCs (3 is common) can even be handled within a single clock tick, although other bottlenecks in the pipeline may limit this again). See these tables to get an idea of the basic latencies of various instructions. But in your high-level world of compiled or interpreted instructions, you're doing much more than that: you allocate some memory for your integer variable first, then you fill it with an initial value, you add unity to that memory location using an ADD or INC instruction, either directly or indirectly (if you had stored that value of one somewhere else before, and have to load it first), and then you may wish to evaluate the result and decide to do something depending on the outcome, as in trancexx's example. All of those steps cost clock ticks; some are handled by ALUs, others by AGUs, floating point maths is handled by your FPU, etc. Many instructions require multiple CPU units to interact, and some single opcodes require over one hundred clock ticks to complete. Special scheduling units attempt to keep the pipelines optimally filled, but cache misses, faults, exceptions, and even suboptimal memory alignment of addresses and buffer sizes all degrade performance. Now imagine this in an environment where dozens or hundreds of threads are vying for processing time and memory, and the CPU is always simultaneously playing catch-up and divide-and-conquer. So you're missing the point if you're thinking purely in terms of your single INC in a single thread. Your CPU itselfs consists of numerous parts working on numerous jobs, and constantly switching to keep as many tasks going in parallel as possible, as efficiently as possible. This means that any thread can be temporarily suspended at any point (and not necessarily always when a full instruction is completed, if that instruction takes more than one clock tick), so if any information is shared between threads, or acted upon and evaluated by multiple threads, race conditions may occur, unless the programmer explicitly adds safeguards to prevent this.

$txt = "my book 1 by Van Horne " & @crlf & _ "bye bye 2 by Adam Smith 2 " & @crlf & _ "stay by my side 3 by Philip Crosby Junior (part 2)" ;Msgbox(0,"", $txt) $txt = StringRegExpReplace($txt, '(?m)^(.+)\hby\h.+', "$1") Msgbox(0,"", $txt)

This might be a slightly better pattern. $txt = "my bytes 1 by Van Horne " & @crlf & _ "my book 2 by Adam Smith 2 " & @crlf & _ "my book 3 by Philip Crosby Junior (part 2)" $txt = StringRegExpReplace($txt, ' by .+', "") Msgbox(0,"", $txt)

@Cormin, you just had this same question locked. You obviously did not read the rules to which you were pointed, especially this part: Do not post anything like this again.

Well, the stuff about GDI+ / GDI I learned from the help file and from the resources of this forum. There are some GDI+ tutorials flying around but not in English. For the very basic steps the help file isn't that bad.

[NEW VERSION] - 7 Mar 16 Added: A new option for $iAdded (+ 512) allows you to select just one cell of the ListView rather than the whole row. A new function _GUIListViewEx_SetDefColours allows the user to set the default colours when using either or both the "colour" and "single cell selection" options. Another new function _GUIListViewEx_BlockReDraw which prevents ListView redrawing during looped Insert/Delete/Change calls - this greatly speeds up execution by avoiding lengthy redrawing when using either or both the "colour" and "single cell selection" options, use of which forces the redraw to use a WM_NOTIFY handler within the script. Changed: A number of minor internal changes to speed up the loading of the ListView when using either or both of the "colour" and "single cell selection" options. A slightly modified Example_6 script shows the new functions in use. The LH native ListView can have rows and columns added/removed using both the old and new functions and has a context menu to allow for colour selection. The contents of this ListView can be mirrored to the RH UDF-created ListView which has "single cell selection" enabled and allows the colours of any item (including the selected cell) to be changed programmatically. New UDF in the first post. M23

@czardas Duplicate Content

@TheSaint Thus, I created this topic in the public asking permission

I Know that's very old, thank for your help

There is no need to scan the array multiple times as it can be done in O(N) instead of O(kN). Durstenfeld variant of the Fisher–Yates algorithm works in a single pass, uses only one call to Random() and guarantees randomness not worst than the one provided by Random(). (And AutoIt Random is very good.) #Include <Array.au3> ;;;;;; SRandom(@AutoItPID) don't use that. Local Const $limit = 10000 Dim $Data[$limit] For $i = 0 To $limit - 1 $Data[$i] = $i Next _ArrayDisplay($Data) For $i = UBound($Data) - 1 To 1 Step -1 $j = Random(0, $i, 1) $Temp = $Data[$j] $Data[$j] = $Data[$i] $Data[$i] = $Temp Next _ArrayDisplay($Data) EDIT: I didn't mean to actually use SRandom() at all. To be honest I don't remember why it was left there...