thanks for the link, Jimmie.
Enrique.
Hi Lindsay,
yes, Picolisp has been a great tool for me as well to explore algorithms
and datastructures.
You used the high level implementation of fastNth (took around 15 seconds)
instead of the
low level implementation (it took 3 seconds).
In fact, taken both implementations in isolation
For a much faster solution than the idx mechanism, look at this:
http://www.mail-archive.com/picolisp@software-lab.de/msg05199.html
It would be nice if Picolisp had this generic fastNth function,
in order to solve this kind of lookup accesses.
Enrique.
initSeed() should be improved, by doing more than simply adding up the
32-bit or 64-bit digits, at least in case of symbols. Any proposals?
I discovered these collisions while comparing the picolisp hash function
with the djb2 string hash function, that didn't have that problem.
May be a
Hello,
I found some strange behaviour in the hash function.
When applied to numbers, it works ok, but when applied
to strings, it leads to a huge number of collisions.
An example:
# ==
(setq N 5
Lnumbers (range 1 N)
Alternatively, you might consider putting it inline into the Lisp source
(load @lib/gcc.l)
(gcc fast NIL 'fastNth)
any fastNth(any ex) {
any x = cdr(ex);
...
}
/**/
thank you, I will try that.
--
UNSUBSCRIBE:
This is a system to access very large lists by index.
First of all, let me say, that the idea for this started
in another thread some days ago. There, I proposed another
idea, with the same goal.
I have to say that overall, Alex, you were right. I insisted
too much, defending that system.
It is
I've changed my mind.
If we have a linear list for which we need fast access, we can do
another thing: Instead of substituting the list with an array
structure, we can keep the list and use an array as a helper of the
original list.
That means that instead of storing the elements of a linear
On 2015-02-15 02:29, Alex Gilding wrote:
One cheap workaround for this would simply be to have a nogc function that
temporarily disables the GC around a piece of code. If you're crunching data
in
arrays, you probably want to isolate that operation in its own little
high-performance block
thanks for your ideas and elaborations!
thank you for having created picolisp
Personally, I must say
1) A pragmatic solution
2) Some timing results and a workaround
1) A PRAGMATIC SOLUTION
---
Is there a price to be paid for having arrays in the language?
Well, if the picolisp machine has to be changed, in order to support
another data type, more tag bits, then I would say
Hi,
I released a new version, with an improved 'ctty'. Now the standard I/O
channels are better initialized: 'ctty' checks the console parameters,
and properly clears the buffers, so that reading from standard input
(both raw or cooked) should work.
This is awesome!
Thank you, now it works
(call test -t 0)
thanks Alex,
now one can make a pager like the unix 'more' utility in Picolisp. Reading
the text from stdin and reading the keyboard to move around the text.
Enrique.
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Dear list,
I am writing a script that reads stdin and uses the function
(key). But when I call it like:
$ cat file.txt |script.l
(key) does not wait for a keypress.
How could I force (key) to wait for a keypress?
This is the script:
***
#!/usr/bin/picolisp
Hello Enrique =?iso-8859-1?Q?S=E1nchez?= petenr...@gmail.com :-)
You are now subscribed
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
15 matches
Mail list logo
