Martin R wrote:
>
> Because of limited time I can only make a rather short comment:
>
> it is easiest to make the sage interface work with a representation (I used
> InputForm) that allows you to recreate the object in FriCAS.
Well, there is one representation that allows you to recreate
the
It is relatively easy to add a function that appends missing type
information to InputForm. For example:
diff --git a/src/algebra/catdef.spad b/src/algebra/catdef.spad
index ce919f6..2efbfca 100644
--- a/src/algebra/catdef.spad
+++ b/src/algebra/catdef.spad
@@ -1444,10 +1444,14 @@ SetCategory() :
Because of limited time I can only make a rather short comment:
it is easiest to make the sage interface work with a representation (I used
InputForm) that allows you to recreate the object in FriCAS.
In other words, a domain "GeneralForm" that drops some of the information
is *not* useful.
oldk1331 wrote:
>
> OK, a summarization:
>
> Currently the InputForm has very limited purposes, while what
> we want is some kind of (typed) code printer: I want a Spad code
> printer, Martin wants a Sage code printer, etc. We might want
> a code printer that prints to other CAS language.
>
>
On 28 February 2017 at 07:14, oldk1331 wrote:
> On Tue, Feb 28, 2017 at 8:06 PM, Bill Page wrote:
>> What do you mean by "code printer"? I suppose suppose that you must
>> mean something more than just producing a string which when parsed and
>>
On 02/28/2017 01:14 PM, oldk1331 wrote:
> My point is, from typed Spad value to untyped SExpression, there'll
> be loss of information.
Very true.
> If you encode type into SExpression, you have to decode it later. So
> the only way is to "from typed Spad value directly to target language
>
On Tue, Feb 28, 2017 at 8:06 PM, Bill Page wrote:
> What do you mean by "code printer"? I suppose suppose that you must
> mean something more than just producing a string which when parsed and
> interpreted re-produces the give code? That is what InputForm
>
What do you mean by "code printer"? I suppose suppose that you must
mean something more than just producing a string which when parsed and
interpreted re-produces the give code? That is what InputForm
provides. Which code? Just a function? Or an entire domain written in
Spad?
I don't think it
OK, a summarization:
Currently the InputForm has very limited purposes, while what
we want is some kind of (typed) code printer: I want a Spad code
printer, Martin wants a Sage code printer, etc. We might want
a code printer that prints to other CAS language.
Currently, both InputForm and
On 24 February 2017 at 01:47, Waldek Hebisch wrote:
> Bill Page wrote:
>> This is the result when the interpreter fails
>>
>> (3) -> interpret(4::InputForm)$InputFormFunctions1(PF 5)
>>
>>An expression involving @ PrimeField(5) actually evaluated to one of
>>
Bill Page wrote:
> This is the result when the interpreter fails
>
> (3) -> interpret(4::InputForm)$InputFormFunctions1(PF 5)
>
>An expression involving @ PrimeField(5) actually evaluated to one of
> type PositiveInteger . Perhaps you should use :: PrimeField(5) .
>
> This causes me
> If you mean ability to store partial results,
> we have it: there is history mechanizm, Library and KeyedAccesFile
> domais which allow storing values in files for later retrieval.
I mean "store partial results". I'll try this.
>> I want to add a use case for InputForm:
>> treat InputForm as
>
> On Thu, Feb 23, 2017 at 6:42 AM, Waldek Hebisch
> wrote:
> >>
> >> I think UP and SUP should be able to convert to InputForm.
> >
> > Why?
>
> This is a XY-problem. In debugging, I want to know a variable's value.
> Since we don't have breakpoints, I have to print
The following hack
(1) -> hack(x:InputForm):InputForm == convert([convert 'coerce,x])
Function declaration hack : InputForm -> InputForm has been added to
workspace.
Type: Void
(2) -> hack(4::InputForm)
Compiling
This is the result when the interpreter fails
(3) -> interpret(4::InputForm)$InputFormFunctions1(PF 5)
An expression involving @ PrimeField(5) actually evaluated to one of
type PositiveInteger . Perhaps you should use :: PrimeField(5) .
This causes me trouble in some of the things I
Am Donnerstag, 23. Februar 2017 13:16:16 UTC+1 schrieb Bill Page:
>
> 'Martin R' wrote:
> > For the record: I always thought that InputForm would be intended to
> provide
> > a means to obtain a construction of an object. Put differently,
> converting
> > an object x to InputForm and
'Martin R' wrote:
> For the record: I always thought that InputForm would be intended to provide
> a means to obtain a construction of an object. Put differently, converting
> an object x to InputForm and evaluating the result should equal x.
>
The issue is the type of the object. InputForm
On 02/23/2017 02:04 AM, oldk1331 wrote:
> I want to add a use case for InputForm:
> treat InputForm as a special output form, after unparsing,
> gives 1-d output that can be entered back to REPL.
> It's like "literals" for other types.
Look a few commits back in my (always rebased mathjax
For the record: I always thought that InputForm would be intended to
provide a means to obtain a construction of an object. Put differently,
converting an object x to InputForm and evaluating the result should equal
x.
With this idea in mind, I wrote several testcases in FriCAS, and recently
On 22 February 2017 at 20:04, oldk1331 wrote:
>
> I want to add a use case for InputForm:
> treat InputForm as a special output form, after unparsing,
> gives 1-d output that can be entered back to REPL.
> It's like "literals" for other types.
>
It has always my opinion that
On Thu, Feb 23, 2017 at 6:42 AM, Waldek Hebisch
wrote:
>>
>> I think UP and SUP should be able to convert to InputForm.
>
> Why?
This is a XY-problem. In debugging, I want to know a variable's value.
Since we don't have breakpoints, I have to print them.
Not print
>
> I think UP and SUP should be able to convert to InputForm.
Why?
> The reason UP/SUP can't convert to InputForm is
> SingletonAsOrderedSet doesn't have ConvertibleTo InputForm.
>
> Simply add ConvertibleTo InputForm to SingletonAsOrderedSet
> and we will get conversion to InputForm for
On 02/22/2017 09:45 AM, oldk1331 wrote:
> Should SUP be able to convert to InputForm?
> Is it meaningful to distinguish a SUP(R) and UP('?,R)?
Difficult question. My personal opinion: there is no variable in SUP(R).
However, the reality, i.e., the code speaks differently.
I think UP and SUP should be able to convert to InputForm.
The reason UP/SUP can't convert to InputForm is
SingletonAsOrderedSet doesn't have ConvertibleTo InputForm.
Simply add ConvertibleTo InputForm to SingletonAsOrderedSet
and we will get conversion to InputForm for UP/SUP.
But they are
24 matches
Mail list logo