<v_m_v>
oh damn....why do floating-point operations have to be that broken in pil?
<abu[m]>
It is not broken. There is no float. It is FIXpoint.
<abu[m]>
IMHO much better in some regards
<v_m_v>
in some...but not for math and user friendly and readable results :)
<abu[m]>
It is a core mechanism. You can roll your own output with e.g. 'round'
<abu[m]>
You should know that PicoLisp by design has only 3 data types
<abu[m]>
(integer) numbers, symbols and lists
<abu[m]>
No room for floats
<abu[m]>
besides that floats are limited and one primary design feature to pil was as limitless as possible
<abu[m]>
So with fixpoint there are no limits in size and precision
<v_m_v>
I see your point. I mean it is hackable with format and good variables naming.
<abu[m]>
So, sorry, no way 😇
<v_m_v>
Each time when I am approaching a new programming language I am wringing in it a little game. It is always the same "game". This is PIL version: https://pastebin.com/a4hy40rU
<v_m_v>
To be honest it is quite fast ...
<v_m_v>
Faster than Janet (lisp dialect). I have to measure the differences, but it should be faster.
<abu[m]>
Nice ☺
<abu[m]>
BTW, have you looked at the flight simulator in PicoLisp? It is around since early times.
<v_m_v>
Is there something like "".join(["a","b","c"]) in PIL?
<v_m_v>
Nope, I have to check it.
<v_m_v>
That small "game" is simple and stupid benchmark. It is showing how fast language can deal with 2d arrays, objects and lots of iterations.
<abu[m]>
What does 'join' do?
<v_m_v>
"a,b,c,d,e" from a list ["a", "b", "c","d"] and separator ","
<abu[m]>
Ah, it is 'glue'
<v_m_v>
thx. I will check it in docu :)
<abu[m]>
(glue ", " '(a b c))
<v_m_v>
:D
<v_m_v>
I've tried do it with pack
<abu[m]>
yes, glue is internally 'pack'
<abu[m]>
btw, there is a board system in @lib/simul.l
<abu[m]>
Used in many cases in rosetta, but also in Pil chess
<v_m_v>
My PIL version is one magnitude paster than Janet's version. Janet is compiled lisp language designed to be fast. Is it possible that PIL is that fast?! I mean ...how?
<abu[m]>
Intersting
<abu[m]>
Perhaps it compiles to some bytecode which is then interpreted?
<v_m_v>
I mean it even feels faster...That game is trying to find a solution for a movement on a chess board. It is using bruteforce.
<v_m_v>
I've to compare those results with Chicken Scheme and Erlang. In both I have the same logic.
<abu[m]>
Cool, please keep us informed
v_m_v has quit [Quit: Client closed]
pfd has quit [Ping timeout: 252 seconds]
rob_w has joined #picolisp
<abu[m]>
BTW v_m_v, in case you read this later: There is a way for internal floating point calculations in Pil with @lib/math.l
<abu[m]>
It is still fixpoint/integer on the Pil level though, but supports trigonometric functions
<abu[m]>
osm/er.l is a good example too, especially for big DB sizes
<abu[m]>
The demo has several hundred million objects iirc
<abu[m]>
But access is without delay
v_m_v has quit [Quit: Client closed]
Regenaxer has left #picolisp [#picolisp]
Regenaxer has joined #picolisp
rob_w has quit [Remote host closed the connection]
v_m_v has joined #picolisp
<v_m_v>
I still don't get it. When I should use bigger indexes? on fields that would contain bigger chunks of data? Or on a entities which would be more popular (I would have them more then others).
<v_m_v>
In the demoApp example, someone has used 4 for Date .... even if Date field is not that big
<abu[m]>
Yes, in both cases. The expected sizes of nodes (e.g. indexing long strings versus numbers) and the number of nodes
<v_m_v>
should I use indexes for numbers/
<v_m_v>
?
<abu[m]>
You can index anything, also nested lists
<abu[m]>
Which date did you mean?
<abu[m]>
(4 (+Ord nr dat cus)) ?
<v_m_v>
in file er.l line: (4 (+Ord nr dat cus)) # J:1024
<v_m_v>
Why such big ingex on dat field?
<v_m_v>
and nr
<v_m_v>
those fields would be rather small
<abu[m]>
4 means a block size of 1024
<abu[m]>
You may have millions of orders
<v_m_v>
yes but in the same time (1 +Ord) means that the amount of orders would be rather small
<v_m_v>
right?
<v_m_v>
it is a couple of lines above
<abu[m]>
A date itself is a number in Pil, needs about 4 bytes. Plus the ref structures so you have perhaps 10 bytes per entry in the tree
<abu[m]>
Yes, one order should fit in one or two blocks
<abu[m]>
I check always with 'size' to estimate what is needed
<v_m_v>
soo it would have more sense to put (0 (+Ord dat)) because 64 is a way bigger then 14
<abu[m]>
An order object probably fits not into 64 bytes
<abu[m]>
ah, sorry, you mean the index
<v_m_v>
and (4 +Ord) because as you have said there could be a milions of Orders
<abu[m]>
No, the index is more efficient if you have more nodes in a block
<v_m_v>
I am lost
<abu[m]>
one block is 1024 bytes
<v_m_v>
ok
<abu[m]>
can hold 100 index entries perhaps
<abu[m]>
Sorry, must go. bbl
<v_m_v>
ok, is there any good article about this?
<v_m_v>
I would be later but I am going to check logs. If someone could explain me the dbs I would be reallllly happpy:)
calle has joined #picolisp
v_m_v has quit [Quit: Client closed]
calle has quit [Ping timeout: 252 seconds]
aw- has quit [Quit: Leaving.]
<abu[m]>
I'm afraid there is not more about dbs than what is in the reference
<abu[m]>
I'd recommend to browse an existing DB, e.g. demoApp
<abu[m]>
looking at the sizes
<abu[m]>
This would also be a good theme for PilCon
aw- has joined #picolisp
v_m_v has joined #picolisp
<v_m_v>
What would happen it I would put my indexes wrong? Can I change it later ?
<abu[m]>
Yes, and even if not perfect the effect is not very big
<abu[m]>
Normally you start with a new db several times initially
<abu[m]>
First create some test data
<abu[m]>
and browse to see how they look like
<v_m_v>
so once again (0 +MyObj) would describe how many MyObjects I would have in my db. (1 (+MyObj field1 field2 field3)) is describin how big fields from MyObj would be
<abu[m]>
typical entity sizes
<abu[m]>
No. (0 +MyObj) means that a typical object of that class is around 64 bytes in size
<abu[m]>
(size '{A0})
<abu[m]>
Entities and tree nodes differ here
<abu[m]>
An entity takes at least one block
<abu[m]>
possibly more
<v_m_v>
aaaaa
<abu[m]>
A tree node holds as many entries as fit, then it is split into two
<abu[m]>
Look up B-Trees
<abu[m]>
You can browse a DB with 'show' or better 'vi'
<abu[m]>
(v {1}) then klick through the whole DB with Shift-K
<abu[m]>
Must go again. bbl
v_m_v has quit [Quit: Client closed]
v_m_v has joined #picolisp
<v_m_v>
ok, so if (0 +Obj) means that typical +Obj would be that size ...so how the fields would have (4 (+Obj dat)) ?
<v_m_v>
The fields can not be bigger then object
<v_m_v>
the example has (0 +Pos) which i understand...but also (4 (+Pos itm))
<v_m_v>
itm is an link into Item
clacke has quit [Remote host closed the connection]