mathlib-develop

[Mathlib-develop] Path Function & problems with funcion calls

[mark <msp...@ya...>]

I've changed the path function so that it's an internal function defined =
in=20
the StandardFunction.java file.

I've done this so that if the search path is corrupted it is still possib=
le to=20
use the path function in order to check what state the search path is in.

While testing it I notived a problem with function calls

entering
>path=20
runs the path function and sets the ans variable but doesn't display anyt=
hing

while entering
>path()
displays the result of the function call.


Best Regards

Mark

Re: [Mathlib-develop] Path Function & problems with funcion calls

[Stefan M. <st...@he...>]

> While testing it I notived a problem with function calls
> 
> entering
> 
>>path 
> 
> runs the path function and sets the ans variable but doesn't display anything
> 
> while entering
> 
>>path()
> 
> displays the result of the function call.
I'll have a look into it.

Kind regards,
   Stefan.

-- 
------------------------------------
Dr.-Ing. Stefan Mueller
email: St...@he...
------------------------------------

Re: [Mathlib-develop] Path Function & problems with funcion calls

[mark <msp...@ya...>]

On Thursday 20 Feb 2003 7:40 pm, Stefan Mueller wrote:
> > While testing it I notived a problem with function calls
> >
> > entering
> >
> >>path
> >
> > runs the path function and sets the ans variable but doesn't display
> > anything
> >
> > while entering
> >
> >>path()
> >
> > displays the result of the function call.
>
> I'll have a look into it.
>
> Kind regards,
>    Stefan.


This seems to be connected to the function being treated as a variable ra=
ther=20
than a function when the brackets are ommitted.

There is a similar problem if there is a space between the function name =
and=20
the brackets. If you enter
>sin (5)

then you get a null pointer error.

After checking it seems that MathLib treats VariableTokens and FunctionTo=
kens=20
in the same way. It first checks for a variable with that name then for a=
=20
function.

Therefore it might be an idea to combine VariableTokens and FunctionToken=
s=20
into one class (Say ReferenceToken) since this would ensure consistent=20
behaviour regardless of how the function or variable is entered.

One difficulty is the fact that VariableToken descends from OperandToken =
while =20
FunctionToken descends from OperatorToken. RefereenceToken would have to =
be a=20
subclass of OperandToken which would mean that it would have to store any=
=20
parameters being passed to the variable or function.

Though this would have the advantage of making functions more consistent =
with=20
keyword functions such as IF and WHILE.

Best Regards

Mark

Re: [Mathlib-develop] Path Function & problems with funcion calls

[Stefan M. <st...@he...>]

mark wrote:
> On Thursday 20 Feb 2003 7:40 pm, Stefan Mueller wrote:
> 
>>>While testing it I notived a problem with function calls
>>>
>>>entering
>>>
>>>
>>>>path
>>>
>>>runs the path function and sets the ans variable but doesn't display
>>>anything
>>>
>>>while entering
>>>
>>>
>>>>path()
>>>
>>>displays the result of the function call.
>>
>>I'll have a look into it.
>>
>>Kind regards,
>>   Stefan.
> 
> 
> 
> This seems to be connected to the function being treated as a variable rather 
> than a function when the brackets are ommitted.
> 
> There is a similar problem if there is a space between the function name and 
> the brackets. If you enter
> 
>>sin (5)
> 
> 
> then you get a null pointer error.
> 
> After checking it seems that MathLib treats VariableTokens and FunctionTokens 
> in the same way. It first checks for a variable with that name then for a 
> function.
> 
> Therefore it might be an idea to combine VariableTokens and FunctionTokens 
> into one class (Say ReferenceToken) since this would ensure consistent 
> behaviour regardless of how the function or variable is entered.
> 
> One difficulty is the fact that VariableToken descends from OperandToken while  
> FunctionToken descends from OperatorToken. RefereenceToken would have to be a 
> subclass of OperandToken which would mean that it would have to store any 
> parameters being passed to the variable or function.
> 
> Though this would have the advantage of making functions more consistent with 
> keyword functions such as IF and WHILE.

You're right, the mentioned approach looks very nice. There is also
another advantage. To move functions into a descendent of OperandToken
would clean up the handling of Expression-Tokens. In the future
expression-tokens should only handle operands like +,*/^   this will
simplify handling of priorities and evaluation of expressions.

I'll start working on it right away. I propose to call the new
token FunctionVariable-token since it cannot be determined during
parsing if a token is a variable or a function.

Kind regards,
   Stefan.

Re: [Mathlib-develop] Path Function & problems with funcion calls

[Stefan M. <st...@he...>]

mark wrote:
> On Thursday 20 Feb 2003 7:40 pm, Stefan Mueller wrote:
> 
>>>While testing it I notived a problem with function calls
>>>
>>>entering
>>>
>>>
>>>>path
>>>
>>>runs the path function and sets the ans variable but doesn't display
>>>anything
>>>
>>>while entering
>>>
>>>
>>>>path()
>>>
>>>displays the result of the function call.
>>
>>I'll have a look into it.
>>
>>Kind regards,
>>   Stefan.
> 
> 
> 
> This seems to be connected to the function being treated as a variable rather 
> than a function when the brackets are ommitted.
> 
> There is a similar problem if there is a space between the function name and 
> the brackets. If you enter
> 
>>sin (5)
> 
> 
> then you get a null pointer error.
> 
> After checking it seems that MathLib treats VariableTokens and FunctionTokens 
> in the same way. It first checks for a variable with that name then for a 
> function.
> 
> Therefore it might be an idea to combine VariableTokens and FunctionTokens 
> into one class (Say ReferenceToken) since this would ensure consistent 
> behaviour regardless of how the function or variable is entered.
> 
> One difficulty is the fact that VariableToken descends from OperandToken while  
> FunctionToken descends from OperatorToken. RefereenceToken would have to be a 
> subclass of OperandToken which would mean that it would have to store any 
> parameters being passed to the variable or function.
> 
> Though this would have the advantage of making functions more consistent with 
> keyword functions such as IF and WHILE.

I've changed FunctionToken to be an OperandToken. I also fixed the
bugs "path" and "path   ()"

I'd like to change the opinion of one of my last emails. I didn't 
introduce a
ReferenceToken class. In my opinion the VariablenToken and FunctionToken
classes are somehow still more different, than the same.
The variable token needs to handle stuff like  some_variable.some_field
while the function token needs to handle java-functions and
script-files. These are not huge differences, but the individual purpose
is still different.
The change from operator token to operand token for the functions also
simplified some code in the Expression-class. It seems to be working
quite okay right now. I'm still into simplifying some code.

Kind regards,
   Stefan.