Re: [Reduce-algebra-developers] error reporting

[Kostas O. <ko...@re...>]

A related, and perhaps simpler issue, is to improve 'rederr' when called
in algebraic mode, as the current implementation seems to be aimed more
at symbolic mode. 

If Reduce had a stop() or abort() command, it seems to me that this
would be solved by simply saying

write <arbitrary error message>
stop()


                                    Kostas


On 12/24/2014 02:57, Rainer Schöpf wrote:
> On Mon, 22 Dec 2014 at 18:14 -0000, Jarmo Hietarinta wrote:
>
>  > > I observe that I can generate a diagnostic as follows
>  > > 
>  > > 1: deg (sin x/cos y, x);
>  > >
>  > >       sin(x)
>  > > ***** -------- invalid as polynomial
>  > >        cos(y)
>  > >
>  > > so you can track through and see the (symbolic mode) code for the function
>  > > typerr that arranges to be able to embed an algebraic expression within a
>  > > message that gets sent back to the user.
>  > 
>  > When I deal with very large expressions I do not want error report to be of type
>  > 
>  > **** ((hundreds of lines of expression )) is not a polynomial,
>  > 
>  > I would rather prefer a more laconic form, such as
>  > 
>  > **** expression given to factorize is not a polynomial
>  > 
>  > Can one control the output of error reporting by a switch?
>
> It wouldn't be too difficult to implement something like this for the case in 
> question, since the error message is handled by the procedure typerr in 
> alg/intro.red. E.g., with the switch toggled it would print
>
>  ***** expression invalid as polynomial
>
> and store the faulty expression in a global variable.
>
> However, that wouldn't help for all other cases. For example, a lot of error 
> messages come from calling rederr. It prints its argument, ie there is no way to 
> know which part is the error message proper, and which part may be a big 
> expression to be suppressed.
>
> So, if someone were to come up with a better concept for error reporting 
> functions, we could start by implementing it, and eventually convert all error 
> reporting to call the new functions.
>
> To give an existing example: at one point rerror was introduced it takes three 
> arguments: a module name, an error code, and a error message to be passed to 
> rederr. I believe the idea behind it was to interface with interactive help to 
> show the documentation for this error.  To be effective, every call to rederr 
> should be converted to call rerror instead - but then one has to manage the 
> error codes and link them to the documentation. This is tedious work - partly 
> because the error codes right now are integers. It would be better to have 
> symbolic names for the errors. These names could be referenced in the manual and 
> automatically converted to links to the help.
>
>  Rainer
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> _______________________________________________
> Reduce-algebra-developers mailing list
> Red...@li...
> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers