oldk1331 wrote:
> What's your opinion on removing IndexedList?
IndexedList is useful if somebody wants to port code which
uses differernt indexing. Sure, speed will be suboptimal,
but frequently minimizing coding effort wins. And given
that Common Lisp uses 0-based indexing there is substantial
oldk1331 wrote:
> > BTW2: If you are worried that [...] is slower than
> > MAKELIST you should rather work on increasing speed
> > of list comprehesion (that is []). Current
> > version constructs list in reverse order and then
> > destructively reverses the result.
>
> It is possible to avoi
> Also, there is tricky balance
> between speed and code size: for rarely executed code
> the main cost is reading it from RAM and evicting
> from cache more useful code. That can negate gains
> from faster execution.
Well, MAKELIST$Lisp is surely most RAM efficient and
fastest. I want to know w
> IndexedList is useful if somebody wants to port code which
> uses differernt indexing.
My point is, for List, one should not use index to get its element,
because it's O(n) to do index. In C++, std::list does not have
operator[], "all STL sequences that support operator[] should
do it in amorti
oldk1331 wrote:
>
> > Also, there is tricky balance
> > between speed and code size: for rarely executed code
> > the main cost is reading it from RAM and evicting
> > from cache more useful code. That can negate gains
> > from faster execution.
>
> Well, MAKELIST$Lisp is surely most RAM efficie
Hi Waldek,
Thanks for applying previous patch.
When you did this you made some changes and one of these changes
introduced a bug, so here is a fix for this bug:
Updated file is here:
https://github.com/martinbaker/multivector/blob/master/computation.spad
and patch is here:
https://github.com/
Martin Baker wrote:
>
> Thanks for applying previous patch.
>
> When you did this you made some changes and one of these changes
> introduced a bug, so here is a fix for this bug:
I got caught by Spad weirdness. In Spad
"string"::OutputForm
is the same as
"string"@OutputForm
which gi
On 09/18/2016 04:26 PM, oldk1331 wrote:
> My point is, for List, one should not use index to get its element,
> because it's O(n) to do index. In C++, std::list does not have
> operator[], "all STL sequences that support operator[] should
> do it in amortized constant time".
> I would even sugges
Hello Martin
As promised (before vacation) below two examples which I'm unable to
interpret (otherwise I recognized that you've improved your code and
that it's now included in fricas -- great :). A lot more examples work
now (i.e same results as Kenzo).
BTW: why didn't you allow '0'? NNI=0,1,2,.