mob/Login()
htm.add("Kozuma3",444)
htm.add("YLYL",777)
htm.add("Compile2Exe",69)
htm.add("rEkt",1337)
src << htm.get("Kozuma3")
var/htm/htm = new
htm
var list/data = new(11)
htm
proc
hash(string)
string = "[string]"; var sum = 0
for(var/pos = 1 to length(string))
sum += text2ascii(string,pos)
return (sum % 11) + 1
add(string,value)
var hash = hash(string)
if(!(islist(data[hash])))
data[hash] = list()
data[hash][string] = value
get(string)
return data[hash(string)][string]
1
2
ID:2533830
Dec 31 2019, 12:46 pm (Edited on Dec 31 2019, 6:06 pm)
|
|
Bases
proc/dbi_Bases() proc/dbi_Mods() |
Demo
world/New() |
All you need is the string/name of the item within the database, and you can retrieve values as such.
var def = db_get("Iron Helm")["def"] |
proc/db_add(item,value) // Adds the item to the db pointing to its value |
Loop Data Structure :D
lds //loop data structure world/New() |
mob/verb/Execute() Allows you to be able to use/add giant numbers, 488 digits worked. Good luck making divide and subtract. |
In response to Kozuma3
|
|
throw EXCEPTION
DM has exceptions now? I must be missing something because I do bot see how to print decimals. Also, I have a question: why not .dll or .so instead? Pass back and forth as strings and avoid any overhead from fiddling with lists and converting to string. |
In response to Major Falcon
|
|
It stores things in binary, and to convert from binary to decimal you need to be able to compute remainders. That code doesn't yet have division, so at the moment there's no way to convert to base ten. The library is not yet finished (I got hung up on something small, I can't remember what) which is why it's not on the hub.
And I wanted to do it entirely in DM. |
Oh, and something I forgot to mention which is important is that the reason it has to convert to a string is that in that library data is stored as a list of integers (in essence you can think of it as storing a number in base 216 but in a two's complement sort of analogue). I then break the data up into the "right" way when performing operations, let the processor do the heavy lifting, and then put everything back together in the correct order.
There's a lot of logic in doing it, but the speed gains are substantial. There's a few libraries on the hub that do what Koz's code does—storing things as a string in decimal—but this is much slower. In the projects thread in On Topic I have some speed tests I did too really show the difference. The big one I remember is computing 300! (the factorial of 300, which is 300! = 300*299*298*297*...*4*3*2*1, which is a very, very big number). BigInt computes this in less than a second iirc while these other libraries take 30 seconds or more. The tradeoff to these operations being so much faster is that converting to decimal representation takes more work since you need to compute remainders. It also means the representation in a list is rather essential to the whole thing [edit] Here's a link to one places where I mentioned factorials, though it's actually 150! rather than 300!. Can't find where I compared it against string-based libraries, but I thought it was in there somewhere. Maybe I posted that somewhere else. |
Your library is complicated. I tried to put this into terms of your library but I did not download your code to try and compile it.
pif_BigInt/proc/PrintDecimal() |
Here is the original I know works based on https://stackoverflow.com/questions/2652760/ nvert-a-gi-normous-integer-in-string-format-to-hex-format-c/ 2653006#2653006
pif_BigInt/proc/PrintDecimal() |
In response to Popisfizzy
|
|
Popisfizzy wrote:
It stores things in binary, and to convert from binary to decimal you need to be able to compute remainders. That code doesn't yet have division, so at the moment there's no way to convert to base ten. The library is not yet finished (I got hung up on something small, I can't remember what) which is why it's not on the hub. It's a fantastic library to have done in DM. I would have used C considering speed is likely important when dealing with large numbers, but your proof-of-concept is sufficiently and impressively fast; I am bewildered. One thing to note is that the underlying bitset is not abstracted away. Any performance considerations for that? I would think you have a library laying around somewhere. |
In response to Major Falcon
|
|
Hmm. In retrospect, that approach is stupidly obvious and I can't believe I overlooked it before. I'll have to update the related method in my pif_LongInt library, because it's much faster than computing remainders.
It's a fantastic library to have done in DM. I would have used C considering speed is likely important when dealing with large numbers, but your proof-of-concept is sufficiently and impressively fast; I am bewildered. Thank you, but I think for matters you'd want to use large integers for such as something like RSA I still feel it's far too slow. It was an interesting project, nevertheless. I had the idea for quite some time, but it was only a couple years ago when I was between leaving school and finding a job that I got around to actually doing it. Had to learn more about how integers are represented in memory, since I only knew a little bit about it at the time. Binary I knew of course, but other details took more looking into. One thing to note is that the underlying bitset is not abstracted away. Any performance considerations for that? I would think you have a library laying around somewhere. Can you clarify what you mean, exactly? |
As a bitset datum containing an array of bytes, indexed by the bit. Usually used for holding a large array of bit flags in a compact space, but they have many purposes and speed advantages over using bytes for booleans due to being closer in memory.
I was just wondering because the logic is already on your code. Last time I was here I developed a bitset library; I could have sworn you had one on the hub. [Edit] And therefore I asked because there must be a reason it wasn't abstracted into its own based on my assumptions. |
In response to Major Falcon
|
|
Yeah, to my knowledge I've never had any library for that. If I ever go back to working on BigInt, though, I might put in a few helper methods to make it easier to use as a bitset since it wouldn't be all that hard
|
1
2
Defines.dm
Database Itself