reduce-algebra-developers — Discussion of development, administration and support for Reduce

Re: [Reduce-algebra-developers] On simplification

[Eberhard S. <esc...@ca...>]

Actually, I was just looking at this code as part of my year end cleanup 
of my mail.
Thanks Rainer for doing regression testing on it!
Just to remind what it is supposed to fix. The current code yields

1: q1 := 1/(x+3);

          1
q1 := -------
        x + 3

2: q2 := (x**2+5*x+6)/(x**2+6*x+9);

         2
        x  + 5*x + 6
q2 := --------------
         2
        x  + 6*x + 9

3: q1+q2;

  x + 3
-------
  x + 3


Obviously the simplification is incomplete. The updated version of addsq
results in 1 as one would expect.
If nobody objects I will commit the fix by tomorrow evening.

   Eberhard


On 12/29/2014 01:22 PM, Rainer Schöpf wrote:
> On Sun, 15 Dec 2013 at 15:46 +0100, Eberhard Schruefer proposed a change to
> addsq:
>
>   > symbolic procedure addsq(u,v);
>   >     % U and V are standard quotients.
>   >     % Value is canonical sum of U and V.
>   >     if null numr u then v
>   >      else if null numr v then u
>   >      else if denr u=1 and denr v=1 then addf(numr u,numr v) ./ 1
>   >      else begin scalar x,y,z;
>   >          if null !*exp then <<u := numr u ./ mkprod denr u;
>   >                               v := numr v ./ mkprod denr v>>;
>   >          if !*lcm then x := gcdf!*(denr u,denr v)
>   >           else x := gcdf(denr u,denr v);
>   >          z := canonsq(quotf(denr u,x) ./ quotf(denr v,x));
>   >          y := addf(multf(denr z,numr u),multf(numr z,numr v));
>   >          if null y then return nil ./ 1;
>   >          z := multf(denr u,denr z);
>   >          if (x := gcdf(y,x)) neq 1 then <<y := quotf(y,x);
>   >                                           z := quotf(z,x)>>;
>   >          if !*gcd then return if x=1 then y ./ z else canonsq(y ./ z);
>   >          return if (x := gcdf(y,z))=1 then canonsq(y ./ z)
>   >                  else canonsq(quotf(y,x) ./ quotf(z,x))
>   >      end;
>   >
>   > However, this slows down calculations a little bit.
>
> I ran the test suite against this change.  The run times differ at most by 5%
> (specfn), in some cases the test runs a bit faster after making the change.
>
> The only notable difference is in the assert test log: with the old code, the
> call
>
>   addsq(simp 'x, numr simp 'x);
>
> returns something whose structure is not a standard quotient, but with the new
> code it returns
>
>   (1 . nil)
>
> Ie. formally a s.q., but with zero denominator.
>
> Any objection to including this change into the core system?
>
>    Rainer

Re: [Reduce-algebra-developers] On simplification

[Rainer S. <rai...@gm...>]

On Sun, 15 Dec 2013 at 15:46 +0100, Eberhard Schruefer proposed a change to 
addsq:

 > symbolic procedure addsq(u,v);
 >     % U and V are standard quotients.
 >     % Value is canonical sum of U and V.
 >     if null numr u then v
 >      else if null numr v then u
 >      else if denr u=1 and denr v=1 then addf(numr u,numr v) ./ 1
 >      else begin scalar x,y,z;
 >          if null !*exp then <<u := numr u ./ mkprod denr u;
 >                               v := numr v ./ mkprod denr v>>;
 >          if !*lcm then x := gcdf!*(denr u,denr v)
 >           else x := gcdf(denr u,denr v);
 >          z := canonsq(quotf(denr u,x) ./ quotf(denr v,x));
 >          y := addf(multf(denr z,numr u),multf(numr z,numr v));
 >          if null y then return nil ./ 1;
 >          z := multf(denr u,denr z);
 >          if (x := gcdf(y,x)) neq 1 then <<y := quotf(y,x);
 >                                           z := quotf(z,x)>>;
 >          if !*gcd then return if x=1 then y ./ z else canonsq(y ./ z);
 >          return if (x := gcdf(y,z))=1 then canonsq(y ./ z)
 >                  else canonsq(quotf(y,x) ./ quotf(z,x))
 >      end;
 > 
 > However, this slows down calculations a little bit.

I ran the test suite against this change.  The run times differ at most by 5% 
(specfn), in some cases the test runs a bit faster after making the change.

The only notable difference is in the assert test log: with the old code, the 
call

 addsq(simp 'x, numr simp 'x);

returns something whose structure is not a standard quotient, but with the new 
code it returns

 (1 . nil)

Ie. formally a s.q., but with zero denominator.

Any objection to including this change into the core system?

  Rainer

Re: [Reduce-algebra-developers] error reporting

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

On 12/28/2014 02:55, Arthur Norman wrote:
> If you read the manual you will find that BYE or QUIT is the command
> to exit reduce. 

Yes, I was aware of "quit".  However, "quit" exits the whole Reduce
process, which is not what I had in mind. My notion of stop() or abort()
was that it would stop the currently running procedure and return to the
top level of Reduce.
> Note also the flag ERRCONT, because not everybody wishes to have the
> system unconditionally exit at the first error. 

Yes, neither do I.   Perhaps I misunderstand 'errcont', but 'on
errcont;' doesn't make a difference in the behavior of quit.
> Indeed further be aware of the (internal-level, not available to
> algebraic mode level coders) function ERRORSET which evaluates
> something trapping errors. ERRORSET is used in a number of places
> within the code to try one procedure for solving a problem and if that
> scheme raises an error rather than completing happily to proceed to a
> fallback. For use with that idiom something that unconditionally
> displayed a message and unconditionally terminated computation would
> not be useful.
>
> So in your own user mode code there is nothing to prevent you from
> going WRITE/QUIT. And because different parts of Reduce were written
> at different times by different people there is no guarantee of absolute
> constistency about when output is generated. The lisp-level variable
> !*msg
> is often used to control "messages" that are diagnostics but not utter
> crash reports.
>
> I think it is also fair to say that in the original design for Reduce
> the expectation was that algebraic mode would be used for user-level
> scripting and that significant packages to be distributed for use by
> others would end up with at least serious chuns of them ending up in
> symbolic mode where the coder would have full access to all the messy
> low level capabilities needed to refine the behaviour of their code
> utterly - but of course that also means that at that level the coder
> needs to cope with all the extra complexity and history revealed by
> digging under the surface.

Yes, having access to all of the low level is both "good" and "bad".  My
problem is to terminate an algebraic-mode procedure when some condition
is detected.  So my solution is

procedure xxxx(....);
begin;
    <stuff>
    if <error> then <<
        write <error message, expressions, etc>;
        rederr "";
    >>;
    <stuff>
end;


>
>     Arthur

Re: [Reduce-algebra-developers] error reporting

[Arthur N. <ac...@ca...>]

On Sun, 28 Dec 2014, Kostas Oikonomou wrote:
> On 12/28/2014 02:55, Arthur Norman wrote:
>> If you read the manual you will find that BYE or QUIT is the command
>> to exit reduce.=
> Yes, I was aware of "quit".  However, "quit" exits the whole Reduce
> process, which is not what I had in mind. My notion of stop() or abort()
> was that it would stop the currently running procedure and return to the
> top level of Reduce.
>> Note also the flag ERRCONT, because not everybody wishes to have the
>> system unconditionally exit at the first error.
>
> Yes, neither do I.   Perhaps I misunderstand 'errcont', but 'on
> errcont;' doesn't make a difference in the behavior of quit.

No not at all. This is me misunderstanding your use of the words "stop" 
and "abort". What happens in Reduce is that a (symbolic level) function 
erroser is used to catch errors. When something is evaluated via errorset 
then errors within that evaluation do not quite the system - they just 
unwind to the next enclosing. Based on a flag (also passed to errorset, 
which is often called with the value of !*backtrace for that flag) the 
unwinding optionally displays a backtrace.

>
> Yes, having access to all of the low level is both "good" and "bad".  My
> problem is to terminate an algebraic-mode procedure when some condition
> is detected.  So my solution is
>
> procedure xxxx(....);
> begin;
>    <stuff>
>    if <error> then <<
>        write <error message, expressions, etc>;
>        rederr "";
>    >>;
>    <stuff>
> end;
>
The definition of rederr is

symbolic procedure rederr u;
    begin if not !*protfg then lprie u; error1() end;

and the definition of lprie is

symbolic procedure lprie u;
    begin scalar x;
         if !*int then go to a;
         x:= !*defn;
         !*defn := nil;
     a:  erfg!* := t;
         lpriw ("*****",u);
         if null !*int then !*defn := x
    end;

so to get an effect as of rederr but without that call actually 
displaying anything you could define your own function as

  symbolic procedure myerror();
    begin
     erflg!* := t;
     error1()
    end;

Then you just call
   lisp myerror();

When you trace through the source code to lpriw you will observe that is 
is concerned that an error may be raised when the user has selected an 
alterative output destination, so it arranges to select the standard 
output on a temporary basis so that error messages go there. I do not know 
if you are concerned about that sort of things for the diagnostics you 
wish to generate.


>
>>
>>     Arthur
>
>

Re: [Reduce-algebra-developers] Merely loading avector hurts other code

[Rainer S. <rai...@gm...>]

I found this while cleaning my mailbox....

The avector package itself uses "cross" as operator, never ^. Ie. it is safe to 
remove the redefinition of the ^ token from the package.

The package redefines rcons from rlisp/list.red, which needed an update as well.

  Rainer


On Thu, 16 Feb 2012 at 07:59 -0000, Arthur Norman wrote:

 > 1: load_package avector;
 > 
 > *** ^ redefined
 > 
 > 2: on backtrace;
 > 
 > 3: int(1/(x^6-1), x);
 > +++ Error: getv nil
 > Inside: vectorcrossprod
 > Arg1: (x 6)
 > apply: vectorcrossprod
 > Inside: vecsm!*
 > Arg1: (cross x 6)
 > Inside: vecsm!*
 > Arg1: (difference (cross x 6) 1)
 > Inside: vecsm!*
 > Arg1: (quotient 1 (difference (cross x 6) 1))
 > Inside: vecsm!*
 > Arg1: (int (quotient 1 (difference (cross x 6) 1)) x)
 > 
 > 4:
 > 
 > I am posting this so it is in the list of things to deal with sometime - 
 > is there an "avector" expert in the house? Well actually I guess this is 
 > just that avector changes the syntax so that "x^6" is a cross product not 
 > a power of x, but this really seems to me to be a horrid trap and a 
 > substantial number of the test scripts use "^" rather than "**".
 > 
 > The simplest patch I can think of at present is to make the syntax in 
 > avector use say ^^ for a cross product rather than merely ^. That would be 
 > an incompatible change that would hurt avector users but would make it 
 > easier for people who do not use avector at present to load the package 
 > and maybe sometimes benefit from it.
 > 
 > Thoughts about that - or other solutions? And suggestions for a procedure 
 > for deciding that changes that break things for some people can be 
 > accepted - it feels dangerous to take unilateral action.
 > 
 > ==============
 > 
 > load_package invbase;
 > in "packages/alg/alg.tst";
 > 
 > fails with "fluid gg invalid as array"
 > 
 > because invbase make gg fluid. I bet other packages make things fluid in 
 > ways that gratuitously pollute the name-space for users. Again does 
 > anybody have a neat suggestion for a way to improve matters? In this case
 > I can just rename the variable in invbase to be "more obscure" (eg say 
 > invbase_gg) and not feel too nervous, but it would be good to detect and
 > mend ALL such cases!
 > 
 >   Arthur
 > 
 > 
 > ------------------------------------------------------------------------------
 > Virtualization & Cloud Management Using Capacity Planning
 > Cloud computing makes use of virtualization - but cloud computing 
 > also focuses on allowing computing to be delivered as a service.
 > http://www.accelacomm.com/jaw/sfnl/114/51521223/
 > _______________________________________________
 > Reduce-algebra-developers mailing list
 > Red...@li...
 > https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers
 > 

   Rainer Schöpf

Re: [Reduce-algebra-developers] error reporting

[Arthur N. <ac...@ca...>]

On Fri, 26 Dec 2014, Kostas Oikonomou wrote:
> 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
If you read the manual you will find that BYE or QUIT is the command 
to exit reduce. Note also the flag ERRCONT, because not everybody wishes 
to have the system unconditionally exit at the first error. Indeed further 
be aware of the (internal-level, not available to algebraic mode level 
coders) function ERRORSET which evaluates something trapping errors. 
ERRORSET is used in a number of places within the code to try one 
procedure for solving a problem and if that scheme raises an error rather 
than completing happily to proceed to a fallback. For use with that idiom 
something that unconditionally displayed a message and unconditionally 
terminated computation would not be useful.

So in your own user mode code there is nothing to prevent you from going 
WRITE/QUIT. And because different parts of Reduce were written at 
different times by different people there is no guarantee of absolute
constistency about when output is generated. The lisp-level variable !*msg
is often used to control "messages" that are diagnostics but not utter 
crash reports.

I think it is also fair to say that in the original design for Reduce the 
expectation was that algebraic mode would be used for user-level scripting 
and that significant packages to be distributed for use by others would 
end up with at least serious chuns of them ending up in symbolic mode 
where the coder would have full access to all the messy low level 
capabilities needed to refine the behaviour of their code utterly - but of 
course that also means that at that level the coder needs to cope with all 
the extra complexity and history revealed by digging under the surface.

     Arthur

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

Re: [Reduce-algebra-developers] error reporting

[Rainer S. <rai...@gm...>]

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

Re: [Reduce-algebra-developers] error reporting

[Arthur N. <ac...@ca...>]

No there is no switch to flip between the fuller error message and a 
short-form one, and no mechanism to print potentially big expressions with 
a "..." after the first bit of them. Your question is a sort of almost 
inevitable consequence of the previous poster's queries in terms of 
seeking more and more refined diagnostics!

Of course ALL the code for Reduce is there and so *ANYBODY* who wants can 
inspect it and in particular track down just where the error messages are 
generated. They could then propose changes: they could without any 
question make whatever changes they wanted in their own local copy of the 
code and if they could make a case that what they were doing was thorough 
and generally beneficial and would not upset others whose work patterns 
differed then what they had would be a candidate for inclusion in the main 
source tree.

Predicting how much detail will suit other people in a diagnostic is 
something I find hard and I probably even expect that the same test code 
and the same individual will have different desires on different days, and 
that few people will remember the details of a new function or switch that 
controls stuff... but if you can work out a plausible idea please do and 
get it back to us all...
   Arthur



On Mon, 22 Dec 2014, 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?
>
> Jarmo Hietarinta

[Reduce-algebra-developers] error reporting

[Jarmo H. <hie...@ut...>]

> 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?

Jarmo Hietarinta

Re: [Reduce-algebra-developers] some problems with the latest Reduce

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

On 12/22/2014 04:37, Arthur Norman 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.
>
> Raising a diagnostic with simple things in it is not too hard and MANY
> places in Reduce arrange that the message that gets issued is little
> more than a string. Doing more complicated things is more complicated!!!!
> Futhermore you raising this causes me to look further and the code for
> typerr in alg/intro.red, while messy. is still not good enough becuse
> the test on outputhandler!* leads to it displaying ugly output when
> "on fancy" is active. I am not going to view improving that as a high
> priority, but I do present it to you as an indication that while you
> may believe that what you think you want to do is obvious and simple
> it is not as trifling as you might have hoped.

No doubt.  But we do have a conflict here between what a user regards as
"simple" or "trifling", and the intricacies of the system's
implementation.  And I say this with some experience in developing
software of my own, and hearing comments from people that have tried
using it.  What I regard as subtleties others regard as nuisances.

>
> [with "on fancy" the above example says
>   ***** (quotient (sin x) (cos x)) invalid as a polynomial
> rather than displaying the expression with infix operators and raised
> exponents...]
>
> So unless you want to delve fully deeply into the Reduce sources and
> see all the things that could interact with mathematical display your
> easiest solution is to arrange that the diagnostic you issue is merely
> a simple message without any embedded expressions.

I am all for simplicity, but useability is an important factor.  Here is
my ugly solution for the time being:

symbolic(rederr {<string>, x, <string>});

This, coupled with a 'share' declaration for x, works in all the
(algebraic) cases I've tried it.

> I have not looked at (and am not about to either) other places where
> other authors have called rederr to see how disciplined they have been
> or to work out exactly what the boundaries are of what can be coped
> with - that looks like a longer job than I have time for just now!
>
> Arthur
>

Re: [Reduce-algebra-developers] some problems with the latest Reduce

[Arthur N. <ac...@ca...>]

>> If you look in the manual you will see that what it says about rederr
>> there takes a string so you are going beyond that there.
>
> Yes, the manual says that.  The Melenk "Primer" in sec. 6.1 has the
> usage I'm talking about.  But I now see it is referring to
> usage in symbolic mode.  I have used rederr {...} before, but I guess
> all of the usages were in symbolic mode, and it's not a version issue.
> I got mixed up.
>
> But the now the question is, how can I issue  the same kind of error
> message in algebraic mode?
> All I can think of is
>
> write "my value is", x;
> rederr "";
>
> But that's awkward.
>
>                            Kostas

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.

Raising a diagnostic with simple things in it is not too hard and MANY 
places in Reduce arrange that the message that gets issued is little more 
than a string. Doing more complicated things is more complicated!!!!
Futhermore you raising this causes me to look further and the code for 
typerr in alg/intro.red, while messy. is still not good enough becuse the 
test on outputhandler!* leads to it displaying ugly output when "on fancy" 
is active. I am not going to view improving that as a high priority, but I 
do present it to you as an indication that while you may believe that what 
you think you want to do is obvious and simple it is not as trifling as 
you might have hoped.

[with "on fancy" the above example says
   ***** (quotient (sin x) (cos x)) invalid as a polynomial
rather than displaying the expression with infix operators and raised 
exponents...]

So unless you want to delve fully deeply into the Reduce sources and see 
all the things that could interact with mathematical display your easiest 
solution is to arrange that the diagnostic you issue is merely a simple 
message without any embedded expressions.

I have not looked at (and am not about to either) other places where other 
authors have called rederr to see how disciplined they have been or to 
work out exactly what the boundaries are of what can be coped with - that 
looks like a longer job than I have time for just now!

Arthur

Re: [Reduce-algebra-developers] some problems with the latest Reduce

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

On 12/21/2014 18:21, Arthur Norman wrote:
>
>> However, the rederr behavior didn't use to occur in earlier versions of
>> Reduce, and it is a problem.
>> Agreed?
>
> No I do not agree. I just dug out a binary using revision 2120 dates
> 2013-07-09 and see the same behaviour.
>
> If you look in the manual you will see that what it says about rederr
> there takes a string so you are going beyond that there. 

Yes, the manual says that.  The Melenk "Primer" in sec. 6.1 has the
usage I'm talking about.  But I now see it is referring to
usage in symbolic mode.  I have used rederr {...} before, but I guess
all of the usages were in symbolic mode, and it's not a version issue. 
I got mixed up.

But the now the question is, how can I issue  the same kind of error
message in algebraic mode?
All I can think of is

write "my value is", x;
rederr "";

But that's awkward.

                            Kostas

Re: [Reduce-algebra-developers] some problems with the latest Reduce

[Arthur N. <ac...@ca...>]

On Sun, 21 Dec 2014, Kostas Oikonomou wrote:

> The set(mkid()) is not a critical problem/bug for me, but I did want to
> report it.

Yes by all means report things.

> However, the rederr behavior didn't use to occur in earlier versions of
> Reduce, and it is a problem.
> Agreed?

No I do not agree. I just dug out a binary using revision 2120 dates 
2013-07-09 and see the same behaviour.

If you look in the manual you will see that what it says about rederr 
there takes a string so you are going beyond that there. However I see a 
number of places in the Reduce source code that go
   rederr {blah, blah, blah};
that you have presumably spotted and are copying. But what you will (I 
rather believe) find is different is that they are all in symblic mode 
code where actually I would never write "{" and "}" but would go
   rederr list(blah, blah, blah)
so I knew just what I was saying.

By using rederr in algebraic mode you are getting its argument treated in 
algebraic mode but rederr does not have any clever processing to handle 
that - it just takes the actual argument you are passing as a bit of Lisp 
style data and displays it in a fairly naive manner. If it is a Lisp style 
list it displays eack item in it in turn.

Now the algebraic mode list you create by using { blah, blah } in 
algebraic mode code has the keyword "list" on the front so that the reduce 
algebra engine can know what it is. The rederr function is displaying 
this. You will see similar oddities if you try
   rederr ((x+6)^10);
where you will see a sequence ot items each being consecutive items in the 
data structure representing the expression. So you see "plus" then (expt x 
10) and so on down to eventually 60466176.

Now if you think that the example you give "worked in a previous version" 
by the magic of subversion you can go
    svn -r NNNN update
to take your locally checked out version down to revision NNNN. Then 
rebuild and test. When I need to do this I tend then to do binary search 
to narrow down the exact revision where something changed, and that lets 
me see who changed something when to alter behaviour. That lets me see 
what they were doing at the time and allows me to explore why the effect I 
see has happened!

>
> 8: x := 123;
>
> x := 123
>
> 9: rederr {"My value is", x};
>
> ***** list My value is 123
>
The following shows both that rederr is not designed to display algebraic 
chunks in a message and how you can call it so that the value of an 
algebraic mode variable is retrieved and converted to a prefix 
representation for you...

Reduce (Free CSL version), 18-Dec-14 ...

1: a := 22/7;

       22
a := ----
       7

2: rederr {"my value is", a};

***** list my value is (quotient 22 7)

3: lisp rederr {"my value is", prepsq simp aeval 'a};

***** my value is (quotient 22 7)


>
> (By the way, I changed my subscription address because Arthur was
> experiencing email bounces.)
Thank you very much for that.
>
>                                    Kostas
>
>
> On 12/21/2014 17:01, Eberhard Schruefer wrote:
>> On 12/21/2014 08:26 PM, Rainer Schöpf wrote:
>>> On Sun, 21 Dec 2014 at 12:27 -0500, Kostas Oikonomou wrote:
>>>
>>>  > Does anyone else have these problems?
>>>
>>> Don't worry, I see the same behaviour (in PSL).
>>>
>>>  > 1: set(mkid(a,4), "junk");
>>>  >
>>>  > ***** String junk invalid as identifier
>>>
>>> The "set" operator is implemented separately and differently from an assignment.
>>> This is surprising and should be changed.
>> Semantically they are different things. It is similar to setq and set on
>> the Lisp level.
>> The restriction that the second argument in the algebraic set command
>> must be a scalar expression, however,
>> would be worth a generalization (I don't have the time at the moment for
>> that though).
>>
>>    Eberhard
>>
>>>  > 2: set(mkid(a,4), mat(0,1,2,3));
>>>  >
>>>  > Memory access violation detected
>>>
>>> This has nothing to do with set.
>>>
>>>   mat(0,1,2,3);
>>>
>>> alone exhibits the same behaviour. It should be a syntax error, but there is
>>> some interaction with autoloading the matrix package - which is why it works the
>>> second time. I have just committed a correction.
>>>
>>>  > 5: x := 1;
>>>  >
>>>  > x := 1
>>>  >
>>>  > 6: if x = 1 then rederr {"Can't be:", x};
>>>  >
>>>  > ***** list Can't be: 1
>>>  >
>>>  > % Where does "list" come from?
>>>
>>> It's the internal representaion of {"Can't be:", x} which is
>>>
>>>   (list "Can't be:" x)
>>>
>>>   Rainer
>>>
>>> ------------------------------------------------------------------------------
>>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>>> Get technology previously reserved for billion-dollar corporations, FREE
>>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Reduce-algebra-developers mailing list
>>> Red...@li...
>>> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers
>>
>> ------------------------------------------------------------------------------
>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>> Get technology previously reserved for billion-dollar corporations, FREE
>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Reduce-algebra-developers mailing list
>> Red...@li...
>> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> Reduce-algebra-developers mailing list
> Red...@li...
> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers
>

Re: [Reduce-algebra-developers] some problems with the latest Reduce

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

10: eval_mode;

algebraic

11: x := 123;

x := 123

12: rederr {"My value is", x};

***** list My value is 123

13:


On 12/21/2014 18:12, Eberhard Schruefer wrote:
> On 12/21/2014 11:41 PM, Kostas Oikonomou wrote:
>> The set(mkid()) is not a critical problem/bug for me, but I did want to
>> report it.
>>
>> However, the rederr behavior didn't use to occur in earlier versions of
>> Reduce, and it is a problem.
>> Agreed?
> Are you sure or did you call rederr in symbolic mode before?
>
>>

Re: [Reduce-algebra-developers] some problems with the latest Reduce

[Eberhard S. <esc...@ca...>]

On 12/21/2014 11:41 PM, Kostas Oikonomou wrote:
> The set(mkid()) is not a critical problem/bug for me, but I did want to
> report it.
>
> However, the rederr behavior didn't use to occur in earlier versions of
> Reduce, and it is a problem.
> Agreed?

Are you sure or did you call rederr in symbolic mode before?

>
> 8: x := 123;
>
> x := 123
>
> 9: rederr {"My value is", x};
>
> ***** list My value is 123
>
>
> (By the way, I changed my subscription address because Arthur was
> experiencing email bounces.)
>
>                                      Kostas
>
>
> On 12/21/2014 17:01, Eberhard Schruefer wrote:
>> On 12/21/2014 08:26 PM, Rainer Schöpf wrote:
>>> On Sun, 21 Dec 2014 at 12:27 -0500, Kostas Oikonomou wrote:
>>>
>>>    > Does anyone else have these problems?
>>>
>>> Don't worry, I see the same behaviour (in PSL).
>>>
>>>    > 1: set(mkid(a,4), "junk");
>>>    >
>>>    > ***** String junk invalid as identifier
>>>
>>> The "set" operator is implemented separately and differently from an assignment.
>>> This is surprising and should be changed.
>> Semantically they are different things. It is similar to setq and set on
>> the Lisp level.
>> The restriction that the second argument in the algebraic set command
>> must be a scalar expression, however,
>> would be worth a generalization (I don't have the time at the moment for
>> that though).
>>
>>     Eberhard
>>
>>>    > 2: set(mkid(a,4), mat(0,1,2,3));
>>>    >
>>>    > Memory access violation detected
>>>
>>> This has nothing to do with set.
>>>
>>>    mat(0,1,2,3);
>>>
>>> alone exhibits the same behaviour. It should be a syntax error, but there is
>>> some interaction with autoloading the matrix package - which is why it works the
>>> second time. I have just committed a correction.
>>>
>>>    > 5: x := 1;
>>>    >
>>>    > x := 1
>>>    >
>>>    > 6: if x = 1 then rederr {"Can't be:", x};
>>>    >
>>>    > ***** list Can't be: 1
>>>    >
>>>    > % Where does "list" come from?
>>>
>>> It's the internal representaion of {"Can't be:", x} which is
>>>
>>>    (list "Can't be:" x)
>>>
>>>    Rainer
>>>
>>> ------------------------------------------------------------------------------
>>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>>> Get technology previously reserved for billion-dollar corporations, FREE
>>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Reduce-algebra-developers mailing list
>>> Red...@li...
>>> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers
>> ------------------------------------------------------------------------------
>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>> Get technology previously reserved for billion-dollar corporations, FREE
>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Reduce-algebra-developers mailing list
>> Red...@li...
>> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> Reduce-algebra-developers mailing list
> Red...@li...
> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers

Re: [Reduce-algebra-developers] some problems with the latest Reduce

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

The set(mkid()) is not a critical problem/bug for me, but I did want to
report it.

However, the rederr behavior didn't use to occur in earlier versions of
Reduce, and it is a problem.
Agreed?

8: x := 123;

x := 123

9: rederr {"My value is", x};

***** list My value is 123


(By the way, I changed my subscription address because Arthur was
experiencing email bounces.)

                                    Kostas


On 12/21/2014 17:01, Eberhard Schruefer wrote:
> On 12/21/2014 08:26 PM, Rainer Schöpf wrote:
>> On Sun, 21 Dec 2014 at 12:27 -0500, Kostas Oikonomou wrote:
>>
>>   > Does anyone else have these problems?
>>
>> Don't worry, I see the same behaviour (in PSL).
>>
>>   > 1: set(mkid(a,4), "junk");
>>   >
>>   > ***** String junk invalid as identifier
>>
>> The "set" operator is implemented separately and differently from an assignment.
>> This is surprising and should be changed.
> Semantically they are different things. It is similar to setq and set on 
> the Lisp level.
> The restriction that the second argument in the algebraic set command 
> must be a scalar expression, however,
> would be worth a generalization (I don't have the time at the moment for 
> that though).
>
>    Eberhard
>
>>   > 2: set(mkid(a,4), mat(0,1,2,3));
>>   >
>>   > Memory access violation detected
>>
>> This has nothing to do with set.
>>
>>   mat(0,1,2,3);
>>
>> alone exhibits the same behaviour. It should be a syntax error, but there is
>> some interaction with autoloading the matrix package - which is why it works the
>> second time. I have just committed a correction.
>>
>>   > 5: x := 1;
>>   >
>>   > x := 1
>>   >
>>   > 6: if x = 1 then rederr {"Can't be:", x};
>>   >
>>   > ***** list Can't be: 1
>>   >
>>   > % Where does "list" come from?
>>
>> It's the internal representaion of {"Can't be:", x} which is
>>
>>   (list "Can't be:" x)
>>
>>   Rainer
>>
>> ------------------------------------------------------------------------------
>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>> Get technology previously reserved for billion-dollar corporations, FREE
>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Reduce-algebra-developers mailing list
>> Red...@li...
>> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> Reduce-algebra-developers mailing list
> Red...@li...
> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers

Re: [Reduce-algebra-developers] some problems with the latest Reduce

[Eberhard S. <esc...@ca...>]

On 12/21/2014 08:26 PM, Rainer Schöpf wrote:
> On Sun, 21 Dec 2014 at 12:27 -0500, Kostas Oikonomou wrote:
>
>   > Does anyone else have these problems?
>
> Don't worry, I see the same behaviour (in PSL).
>
>   > 1: set(mkid(a,4), "junk");
>   >
>   > ***** String junk invalid as identifier
>
> The "set" operator is implemented separately and differently from an assignment.
> This is surprising and should be changed.

Semantically they are different things. It is similar to setq and set on 
the Lisp level.
The restriction that the second argument in the algebraic set command 
must be a scalar expression, however,
would be worth a generalization (I don't have the time at the moment for 
that though).

   Eberhard

>
>   > 2: set(mkid(a,4), mat(0,1,2,3));
>   >
>   > Memory access violation detected
>
> This has nothing to do with set.
>
>   mat(0,1,2,3);
>
> alone exhibits the same behaviour. It should be a syntax error, but there is
> some interaction with autoloading the matrix package - which is why it works the
> second time. I have just committed a correction.
>
>   > 5: x := 1;
>   >
>   > x := 1
>   >
>   > 6: if x = 1 then rederr {"Can't be:", x};
>   >
>   > ***** list Can't be: 1
>   >
>   > % Where does "list" come from?
>
> It's the internal representaion of {"Can't be:", x} which is
>
>   (list "Can't be:" x)
>
>   Rainer
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> Reduce-algebra-developers mailing list
> Red...@li...
> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers

Re: [Reduce-algebra-developers] some problems with the latest Reduce

[Arthur N. <ac...@ca...>]

Firstly I observe that on version sof Reduce from some while back
    mat(0,1,2,3);
crashes on both CSL and PSL. As explained in the manual if you wanted a 
single row matrix you would have needed to write mat((0,1,2,3)) with an 
extra pair of parens.

If you yse bootstrapreduce rather than redcsl or redpsl then all car/cdr 
accesses are checked and you can get a slighly clearer diagnostic.

$ bin/bootstrapreduce -w
Reduce (Free CSL version), 20-Nov-14 ...

1: on backtrace;

2: mat(0,1,2,3);

+++ Error attempt to take car of an atom: 0
Inside: formlis
Arg1: 0
Arg2: nil
Arg3: algebraic
Inside: formmat
Arg1: (mat 0 1 2 3)
Arg2: nil
Arg3: algebraic
Arg1: (mat 0 1 2 3)
Arg2: nil
Arg3: algebraic
apply: formmat
Inside: form1
Arg1: (mat 0 1 2 3)
Inside: command

and perhaps as a result of your example we will check that the syntax is 
correct rather than assuming that people do the right thing!

The issue of trying to set something to a string is related to the fact 
that the code that imlements SET works using
    let0 ... simp!* ...
and the creation there of a form (!*sq ...) manually using mk!*sq means 
that the RHS has to be something that can be a genuine algebraic 
expression. And strings can not.

It MIGHT be possible to change

      let0 list(list('equal,x,mk!*sq(u := simp!* cadr u)));
      return u

into a call something along the lines of
      setk(x, u := aeval cadr u);
      return simp!* u

but I am really not comfortable enough that I understand all potential 
ramifications and consequences to drop everything now and consider such a 
change. Even though use of SET may be really uncommon I would not wish to 
break some other use of it by trying to mend this case.

Strings are mostly there in Reduce just to be directly printed!

So in short, I believe that the behaviour you report is long standing and 
not a trivial glitch to slap an easy band-aid on.

      Arthur


On Sun, 21 Dec 2014, Kostas Oikonomou wrote:

> Does anyone else have these problems?
>
>                            Kostas
>
>
> Reduce (Free CSL version), 21-Dec-14 ...
>
> 1: set(mkid(a,4), "junk");
>
> ***** String junk invalid as identifier
>
> 2: set(mkid(a,4), mat(0,1,2,3));
>
> Memory access violation detected
>
> % Should be syntax error?
>
> 3: clear a4;
>
> 4: set(mkid(a,4), mat((0,1,2,3)));
>
> *****
>
> [0  1  2  3]
>
> invalid as scalar
>
> 5: x := 1;
>
> x := 1
>
> 6: if x = 1 then rederr {"Can't be:", x};
>
> ***** list Can't be: 1
>
> % Where does "list" come from?
>
> 7:
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> Reduce-algebra-developers mailing list
> Red...@li...
> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers
>

Re: [Reduce-algebra-developers] some problems with the latest Reduce

[Rainer S. <rai...@gm...>]

On Sun, 21 Dec 2014 at 12:27 -0500, Kostas Oikonomou wrote:

 > Does anyone else have these problems?

Don't worry, I see the same behaviour (in PSL).

 > 1: set(mkid(a,4), "junk");
 > 
 > ***** String junk invalid as identifier

The "set" operator is implemented separately and differently from an assignment. 
This is surprising and should be changed.

 > 2: set(mkid(a,4), mat(0,1,2,3));
 > 
 > Memory access violation detected

This has nothing to do with set. 

 mat(0,1,2,3);

alone exhibits the same behaviour. It should be a syntax error, but there is 
some interaction with autoloading the matrix package - which is why it works the 
second time. I have just committed a correction.

 > 5: x := 1;
 > 
 > x := 1
 > 
 > 6: if x = 1 then rederr {"Can't be:", x};
 > 
 > ***** list Can't be: 1
 > 
 > % Where does "list" come from?

It's the internal representaion of {"Can't be:", x} which is

 (list "Can't be:" x)

 Rainer

[Reduce-algebra-developers] some problems with the latest Reduce

[Kostas O. <k.o...@at...>]

Does anyone else have these problems?

                            Kostas


Reduce (Free CSL version), 21-Dec-14 ...

1: set(mkid(a,4), "junk");

***** String junk invalid as identifier

2: set(mkid(a,4), mat(0,1,2,3));

Memory access violation detected

% Should be syntax error?

3: clear a4;

4: set(mkid(a,4), mat((0,1,2,3)));

*****

[0  1  2  3]

 invalid as scalar

5: x := 1;

x := 1

6: if x = 1 then rederr {"Can't be:", x};

***** list Can't be: 1

% Where does "list" come from?

7:

Re: [Reduce-algebra-developers] package-remake problems

[Arthur N. <ac...@ca...>]

Perhaps the first request is that you email me directly from an address 
that does not bounce when I try to reply. If the one at att.net is 
unreliable then one of the other public systems might be useful. Sorry 
about that but defaled support for you will be way better if we can 
exchange messages directly without ALL of it needing to be via the public 
list.

The issue of !@reduce etc applies in the CSL version and setting !@reduce 
:= "junk"; is not liable to help unless just is the path-name to where the 
Reduce sources live!!!!

Let's exchange private message so I can see EXACTLY what you are doing and 
help out.
   Arthur

On Thu, 18 Dec 2014, Kostas Oikonomou wrote:

> In the process of developing a new package, in my case named "nlopt",
> the command
>
> package!-remake 'nlopt;
>
> is very convenient.  Unfortunately it produces this error:
>
> ***** Missing file $reduce/packages/nlopt/nlopt.red
>
> Now it is not true that this file is missing, but, according to a
> previous conversation with Arthur,
> Reduce wants the Lisp variable !@reduce or !$reduce set to the right value.
>
> Nevertheless, if I do, as a test,
>
> -----------------------------------------------------------------------
> 3* !@reduce := "junk";
> "junk"
>
> 4* !$reduce := "junk";
> "junk"
>
> the problem persists
>
> 5* package!-remake 'nlopt;
>
> ***** Missing file $reduce/packages/nlopt/nlopt.red
>
> -----------------------------------------------------------------------
>
> Am I doing something wrong here?
>
>
> I also tried in a shell window
>
> -----------------------------------------------------------------------
> $ export reduce=junk
> $ redcsl
> -----------------------------------------------------------------------
> with the same results.
>
>
> Can someone help with this?  It would be very convenient to get
> package!-remake to work.
>
>                            Kostas
>
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> Reduce-algebra-developers mailing list
> Red...@li...
> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers
>

[Reduce-algebra-developers] package-remake problems

[Kostas O. <k.o...@at...>]

In the process of developing a new package, in my case named "nlopt",
the command

package!-remake 'nlopt;

is very convenient.  Unfortunately it produces this error:

***** Missing file $reduce/packages/nlopt/nlopt.red

Now it is not true that this file is missing, but, according to a
previous conversation with Arthur,
Reduce wants the Lisp variable !@reduce or !$reduce set to the right value.

Nevertheless, if I do, as a test,

-----------------------------------------------------------------------
3* !@reduce := "junk";
"junk"

4* !$reduce := "junk";
"junk"

the problem persists

5* package!-remake 'nlopt;

***** Missing file $reduce/packages/nlopt/nlopt.red

-----------------------------------------------------------------------

Am I doing something wrong here?


I also tried in a shell window

-----------------------------------------------------------------------
$ export reduce=junk
$ redcsl
-----------------------------------------------------------------------
with the same results.


Can someone help with this?  It would be very convenient to get
package!-remake to work.

                            Kostas

Re: [Reduce-algebra-developers] sequence of "dummy variables" inside a procedure

[Eberhard S. <esc...@ca...>]

On 12/16/2014 11:25 PM, Kostas Oikonomou wrote:
> Eberhard,
>
> Thanks very much.  This works, in that  Reduce does not consider 'x' to
> be  an operator outside of my procedure.
> And this is what I wanted.
>
> I read in the primer about gensym(), and I think I know what
>
> put('anonymous_id,'psopfn,'gensym);

Actually this statement should better read

put('anonymous_id,'psopfn,'(lambda (x) (gensym)));

to avoid number of arguments mismatch (as pointed out to me privately by 
Arthur).

>
> does, but I don't totally understand how all of this works in
>
> procedure s1s2(...);
>      begin scalar x;
>          x := anonymous_id();
>          operator x;
>          ...
>
>
>                                  Kostas
>
> On 12/16/2014 15:17, Eberhard Schruefer wrote:
>> It uses a not interned id
>> for the operator name and therefore would not clash with anything.

Re: [Reduce-algebra-developers] sequence of "dummy variables" inside a procedure

[Kostas O. <k.o...@at...>]

Eberhard,

Thanks very much.  This works, in that  Reduce does not consider 'x' to
be  an operator outside of my procedure.
And this is what I wanted. 

I read in the primer about gensym(), and I think I know what

put('anonymous_id,'psopfn,'gensym);

does, but I don't totally understand how all of this works in

procedure s1s2(...);
    begin scalar x;
        x := anonymous_id();
        operator x;
        ...


                                Kostas

On 12/16/2014 15:17, Eberhard Schruefer wrote:
> It uses a not interned id
> for the operator name and therefore would not clash with anything.