[fricas-devel] why Fricas allows Float as argument to function defined to accept Integer?
I am learning little Fricas. But confused about this
(21) -> g2(x: Integer): Integer == x^2
Function declaration g2 : Integer -> Integer has been added to
workspace.
Is the above function supposed to accept only Integer type as input and
return Integer? Then why does this call work:
22) -> g2(7.0)
Compiling function g2 with type Integer -> Integer
(22) 49
Type:
PositiveInteger
It seems to have casted 7.0 to 7? And should not the type returned be
Integer and not PositiveInteger?
23) -> typeOf(7.0)
(23) Float
Fricas does however catch the error when passing string:
24) -> g2("hello")
Conversion failed in the compiled user function g2 .
Cannot convert the value from type String to Integer .
Compare to Maple
-
g2:=proc(x::integer)::integer;
x^2;
end proc;
g2(7.0);
Error, invalid input: g2 expects its 1st argument, x, to be of type
integer, but received 7.0
---
And that is what I was expecting, given that Fricas is very strongly typed.
Did I do something wrong or do I need to turn some setting on or something?
Fricas 1.3.9
Thanks
--Nasser
--
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 fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/f91e9438-5e07-4e2b-a9b8-4f320bd97c2cn%40googlegroups.com.
Re: [fricas-devel] Re: Sage and Rename 'rootOfADE' to 'ADEseq'
On Sun, Dec 24, 2023 at 01:36:07PM -0800, 'Martin R' via FriCAS - computer algebra system wrote: > Thank you for notifying! > > (May I ask for the reason of the change of name? Will rootOfRec also be > renamed? Disclaimer: I introduced these operators to FrICAS) 'rootOfADE' is confusing: the only reasonable meaning of root of ADE is a solution, that is a function. One should be able to compute derivatives of of such object and plug them into a differential equation. Object defined in RECOP is a sequence, it behaves in quite different way. 'rootOfRec' is fine, it is solution to reccurence equation. BTW: I tried to contact you via private mail, got no answer in a week. -- Waldek Hebisch -- 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 fricas-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/ZYipw_he8XTnIPXB%40fricas.org.
[fricas-devel] Re: Sage and Rename 'rootOfADE' to 'ADEseq'
Thank you for notifying!
(May I ask for the reason of the change of name? Will rootOfRec also be
renamed? Disclaimer: I introduced these operators to FrICAS)
Best wishes,
Martin
On Sunday 24 December 2023 at 02:10:09 UTC+1 oldk1331 wrote:
> In Sagemath's FriCAS interface, there is:
>
> register_symbol(lambda *args:
> explicitly_not_implemented("rootOfADE"), {'fricas': 'rootOfADE'}, 2)
>
> Although it is not implemented, the rename will affect the interface.
>
> This should be kept in mind when FriCAS gets version bump in Sage.
>
> - Qian
>
--
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 fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/be1f3cf5-92b1-466a-8033-9d59bf6b6d7an%40googlegroups.com.
Re: [fricas-devel] Recursive call to interpreter
OK, this might not be that complicated after all, hear my analysis: 1. Assume there is only 1 (global) scope for $timedNameStack, and it is only modified by push or pop, never gets assignment. When an exception is thrown in somewhere and catched somewhere else, now there's a "stopTimingProcess A", but the head of $timedNameStack is B. We can simply attribute the stats to A, and continue. (Current "savedTimerStack" is attributing the stats to B.) The only downside is that $timedNameStack will grow indefinitely. 2. Now let's have a dynamic scope for $timedNameStack for each nested "processInteractive". Problem solved. No need to wrap around every CATCH. $timedNameStack will not grow indefinitely. What I'm saying is: 1. dynamic scoping for $timedNameStack 2. do not use savedTimerStack around CATCH 3. do not check with "peekTimedName" in "stopTimingProcess". (aka allow unbalanced $timedNameStack, which is a price has to be paid for exception handling) - Qian On 12/24/23 18:48, Waldek Hebisch wrote: On Sun, Dec 24, 2023 at 09:55:03AM +0800, Qian Yun wrote: On 12/24/23 09:41, Waldek Hebisch wrote: Well, with this '$timedNameStack' is balanced. But there is still trouble with acconting: since 'stopTimingProcess' was not called we will either ignore or assign to wrong context resources used in context that did 'THROW'. If there's throw to top level, then stats will not be printed, so there's no need to continue collect stats. Forget about toplevel. This tread is above recursive calls. In particular algebra may perform call to interpreter and catch errors. When algebra returns to outer interpreter we should print statistics. Similar thing happens inside interpreter. BTW: It is debatable if not printing stats in case of errors is right thing to do. "When algebra returns to outer interpreter", the $timedNameStack in outer interpreter is not affected by inner interpreter. The total time spent in inner interpreter is accounted under "evaluation" of outer interpreter. Well, deciding what to do in such situation is part of solving problem. AFAICS before your patches inner interpreter messed statistic variables of outer one, and printing nothing in outer interpreter masked the trouble. IMO when some code is aborted, but error is caught and computation continues, we should count time spent in aborted code. Which means that we should ensure consitent statistics. This may require use of different function than 'processInteractive' (or change to 'processInteractive'). To put this differently: there is 'read' which separately times toplevel expressions in a file, which requires recursive timing. But we also have calls from algebra to interpreter and those IMO should be timed togethere with toplevel call. If we assume that recursive calls via 'processInteractive' only deal with 'read' than you change looks OK. Can you give an example (inner interpreter catches exception) so that I can verify if it messes up stats accounting? In algebra we can use: 'trapNumericErrors', 'trappedSpadEval' and 'eval_with_timeout'. More can be added if needed. Code executed by constructs above may call 'interpret', 'interpret_block' or other interpeter constructs. There is also possibility of passing interpeter functions to algebra code. Normaly, such functions are compiled, but sometimes interpreter really interpret functions. I am not sure if interpretation is allowed for functions passed to algebra, but one can argue that they should be supported. Note: part of problem is deciding which calls should do recursive timings and how those should behave. Past behaviour is of limited help here, as we want to fix trouble with current code which probably will involve changing behaviour to more desirable one. -- 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 fricas-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/1263558d-26b4-4d13-846d-baf1d6dc1449%40gmail.com.
Re: [fricas-devel] Recursive call to interpreter
On Sun, Dec 24, 2023 at 09:55:03AM +0800, Qian Yun wrote: > > > On 12/24/23 09:41, Waldek Hebisch wrote: > > > > > > > > Well, with this '$timedNameStack' is balanced. But there is still > > > > trouble with acconting: since 'stopTimingProcess' was not called > > > > we will either ignore or assign to wrong context resources used > > > > in context that did 'THROW'. > > > > > > If there's throw to top level, then stats will not be printed, > > > so there's no need to continue collect stats. > > > > Forget about toplevel. This tread is above recursive calls. > > In particular algebra may perform call to interpreter and > > catch errors. When algebra returns to outer interpreter > > we should print statistics. Similar thing happens inside > > interpreter. > > > > BTW: It is debatable if not printing stats in case of errors > > is right thing to do. > > > > "When algebra returns to outer interpreter", the $timedNameStack > in outer interpreter is not affected by inner interpreter. > The total time spent in inner interpreter is accounted under > "evaluation" of outer interpreter. Well, deciding what to do in such situation is part of solving problem. AFAICS before your patches inner interpreter messed statistic variables of outer one, and printing nothing in outer interpreter masked the trouble. IMO when some code is aborted, but error is caught and computation continues, we should count time spent in aborted code. Which means that we should ensure consitent statistics. This may require use of different function than 'processInteractive' (or change to 'processInteractive'). To put this differently: there is 'read' which separately times toplevel expressions in a file, which requires recursive timing. But we also have calls from algebra to interpreter and those IMO should be timed togethere with toplevel call. If we assume that recursive calls via 'processInteractive' only deal with 'read' than you change looks OK. > Can you give an example (inner interpreter catches exception) > so that I can verify if it messes up stats accounting? In algebra we can use: 'trapNumericErrors', 'trappedSpadEval' and 'eval_with_timeout'. More can be added if needed. Code executed by constructs above may call 'interpret', 'interpret_block' or other interpeter constructs. There is also possibility of passing interpeter functions to algebra code. Normaly, such functions are compiled, but sometimes interpreter really interpret functions. I am not sure if interpretation is allowed for functions passed to algebra, but one can argue that they should be supported. Note: part of problem is deciding which calls should do recursive timings and how those should behave. Past behaviour is of limited help here, as we want to fix trouble with current code which probably will involve changing behaviour to more desirable one. -- Waldek Hebisch -- 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 fricas-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/ZYgMh-72ec1ofoq5%40fricas.org.
