|
|
All of the random number generators based on a commodity's price produce "brown" noise - the price varies in a manner similar to Brownian motion.
Any idea how to convert this to "white" noise?
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
There are some things I learn about and I am just amazed.
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
I prefer the Randall Algorithm[^] myself.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
 
It's intended for an 8 bit processor and can be asembled for 8 bit random values or for 16 bit. When i tested it. it had a nice Gaussean bell curve distribution, so the random values are indeed random enough for noncritical applications.
; =========================================================================================
; Generates a 16 bit or 8 bit (pseudo) random number
;
; Parameters:
; RF 16 bit random return value
; RF.0 8 bit random return value
;
; Internal:
; RE Pointer to random state
; RD.0 Loop counter
; =========================================================================================
GetRandom: GLO RE ; save registers RE and RD.0 on the stack
STXD
GHI RE
STXD
GLO RD
STXD
LDI lo(RandomState) ; load the address of the random state
PLO RE
LDI hi(RandomState)
PHI RE
IF RandomSize == 16
LDI 10H ; set up the loop counter to shift 16 bits
PLO RD
ELSE
LDI 08H ; set up the loop counter to shift 8 bits
PLO RD
ENDIF
GRA_ShiftLoop: GLO RF ; shift the value in RF
SHL
PLO RF
IF RandomSize == 16
GHI RF ; extend to 16 bits
RSHL
PHI RF
ENDIF
LDN RE ; shift random state
SHL
IF RandomSize == 16
STR RE ; extend to 16 bits
INC RE
LDN RE
RSHL
ENDIF
BNF GRA_BitZero
GRA_BitOne: XRI 0A7H ; XOR over the random state
STR RE
IF RandomSize == 16
DEC RE ; extend to 16 bits
LDN RE
XRI 03EH
STR RE
ENDIF
GLO RF ; add the bit to RF
ORI 01H
PLO RF
LBR GRA_TestLoop
GRA_BitZero: XRI 035H ; XOR over the random state
STR RE
IF RandomSize == 16
DEC RE ; extend to 16 bits
LDN RE
XRI 07AH
STR RE
ENDIF
GRA_TestLoop: DEC RD ; loop until all bits have been shifted
GLO RD
BNZ GRA_ShiftLoop
INC R2 ; restore registers RE and RD.0
LDXA
PLO RD
LDXA
PHI RE
LDN R2
PLO RE
SEP R5
;------------------------------------------------------------------------------------------
; =========================================================================================
; Data
; =========================================================================================
RandomState: db 2 dup (?)
;------------------------------------------------------------------------------------------
I have lived with several Zen masters - all of them were cats.
|
|
|
|
|
What processor? I don't recognize "GLO" and "PLO", etc.
|
|
|
|
|
|
I have not checked, but it may even work on a CDP1801, and certainly it will also run on a CDP1804. CDP1805 or a CDP1806.
I have lived with several Zen masters - all of them were cats.
|
|
|
|
|
Cool, it even as a SEX instruction. 
|
|
|
|
|
Now you have hit my nose on a potential bug!
The X register designates the stack pointer. The SEX instruction sets the value of X and this way makes one of the registers the current stack pointer. Typically this is register 2 and does not change as long as the program runs.
At the end of the little routine I restore some registers from values which I saved on the stack at the beginning. The INC R2 and LDN R2 instructions near the end assume that R2 is the stack pointer. If it's not, the registers will not be restored properly and the stack pointe will be corrupted.
INC R2 must be replaced by IRX (increment the register designated by the value of X) and LDN R2 must be replaced by LDX (load via the register designated by X). This way the code will work properly, no matter which register is currently the stack pointer.
What a dumb mistake, and I bet it will show up in even more places! That's code that has worked for many years, but obviously only because I did not do much juggling with different stack pointers.
I have lived with several Zen masters - all of them were cats.
|
|
|
|
|
CodeWraith wrote: Now you have hit my nose on a potential bug!
Crazy, the way things work sometimes. I make a flippant remark, and you find a bug! Just last week I was having a conversation with someone that resulted in solving a design flaw that I've been noodling on for a couple years!
|
|
|
|
|
Is that a synonym for the NOP instruction ?
I'd rather be phishing!
|
|
|
|
|
Nope. With this instruction you can make any of the 16 registers the current stack pointer. It's short for SET X because the X register determines which register is used as the stack pointer. But sure, that mnemonic is not an accident.
I have lived with several Zen masters - all of them were cats.
|
|
|
|
|
I see you already got a very correct answer.
GLO and PLO get the low byte (GLO) or put the low byte of any of the 16 general purpose registers to or from the accumulator. If you can guess the instructions to get or put the high byte of a register, you actually already know 64 of the processor's 255 instructions.
Let's increase that to 96 instructions: INC and DEC increment or decrement registers, interesting enough about the only instructions that are 16 bit wide.
I think in an hour I would have you writing programs for this processor. There are no fancy addresing modes. Everything is done over the registers. Back then many called the processor weird for that, later it was called RISC.
I have lived with several Zen masters - all of them were cats.
|
|
|
|
|
 That's a really nice answer!
"Go forth into the source" - Neal Morse
|
|
|
|
|
Miss your no-longer-annual 12 Days of Christmas post.
|
|
|
|
|
You know what? I actually thought of posting it the week after thanksgiving as I usually do, but with the new crowd here, I was not sure how it'd go. Most people would have just not gotten it
|
|
|
|
|
Not if you add all the previous links to it. I miss the Lotus in particular.
|
|
|
|
|
|
10-18 cores for affordable home PCs ($4000-ish).
|
|
|
|
|
And it has AVX512 which would be my reason for getting one, but it's still more expensive than it's worth to me. It also doesn't have a lot of the more advanced AVX512 extensions yet, such as AVX512-VBMI, or AVX512-BITALG.
|
|
|
|
|
Visual C++ supports AVX 512, but I am not entirely sure if the .NET GIT supports it today.
|
|
|
|
|
SIMD in .NET is in an unusable state anyway, but I've heard they're working on an API overhaul.
|
|
|
|
|
I haven't but I would like to try one and a ThreadRipper too. I work on a very parallelized program (using OpenMP) and these are exactly the kind of machines it likes. I would love to have one of each and compare them with my program. As it is, we can't get enough power in one box so we have to have two or three more as clients. We would like to be able to have one box with a couple of those chips in it to the do the whole job.
|
|
|
|
|
I am not sure I can convince myself to buy one at its current price. But I am still thrilled that it is available and that a home user can buy it if he/she really wants to. Expensive for sure but not out of reach.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
