List(OrderedVariableList([a,b,c,d,e,f,g,h,i,j])) (17) -> l(2.. by
2) There are no library operations named BY having 1 argument(s)
though there are 1 exposed operation(s) and 0 unexposed
operation(s) having a different number of arguments.
This is parsing issue.
Is it possible that you can fix this?
Well there are two possibilities:
1) In generic implementation signal error when 'by' is present 2) add
apropriate primitive operation(s) to category and implement them in
specific domains domains
First investigation says that we could have a proper implementation in
StreamAggregate, if the respective domains implement something like
multisect.
For Stream itself we could just move it from
StreamTaylorSeriesOperations.
https://github.com/fricas/fricas/blob/master/src/algebra/sttaylor.spad#L445
In fact, looking at the functions in StreamTaylorSeriesOperations, I
wonder why not many of them could live directly in Stream. The arguments
are mostly bound to "Stream" anyway. Maybe open for discussion.
Implementation of multisect for List, is probably not that hard, except
that one must take care of cyclic lists.
It seems that only Stream and List are the most important instances for
this elt function, although there are more like AssociationList.
So what do you think about implementation of multisect in List and Stream?
Signaling error has disadvantage thaty putting restrictions in
documentation adds bulk and distract users ("do this restriction
affects my use case?"). OTOH if users hit undocumented restriction,
they will be dissatisfied.
I am not sure how important is 'elt' with 'by'.
Oh, probably not that important since nobody has asked for it for so
many years, but I came across the Mathematica "span" syntax "a;;b;;s".
https://reference.wolfram.com/language/ref/Span.html
And there is also list slicing in Python ... "[start : stop : steps]".
https://www.geeksforgeeks.org/python-list-comprehension-and-slicing/
I thought we can just make things work properly in FriCAS.
Admitedly, I make little use of 'elt' with segments, but I consider
it an important feature. If 'elt' with 'by' is important enough to
explicitely spell out restricition in documentation, then I think it
is important enough to implement properly (without restriction).
I'd prefer for proper implementation.
We also seem to have a bug (although I question that al(1..1) would be
anything useful.
(22) -> AL ==> AssociationList(String, List String)
(23) -> al := empty()$AL
(23) table()
Type: AssociationList(String,List(String))
(24) -> al."fire" := ["red", "orange", "yellow"]
(24) ["red", "orange", "yellow"]
Type: List(String)
(25) -> al."water" := ["blue"]
(25) ["blue"]
Type: List(String)
(32) -> al(1..1) -- doesn't stop
C-c C-c
>> System error:
Interactive interrupt at #x534C5682.
Ralf
--
You received this message because you are subscribed to the Google Groups "FriCAS -
computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/22a4cf17-82d3-0c4b-807b-9bf7948fd94b%40hemmecke.org.
