If there only a few exceptions why not use a switch statement, that way
your parser output will be correct for 99.9% of situations and it will only
be for the 0.1% cases AND if the User studies the parser output that they
will notice something strange - and even then you can cover that. Something
like:
on closeField
put me into enteredFormula
switch
case (enteredFormula contains "ln(0)")
replace "ln(0)" with "undefined" in enteredFormula
put "some statement" into parserOutput --spit out an explanation
of change/situation
--do whatever you need to do with the modified enteredFormula
break
case (enteredFormula contains --any other exceptions)
break
default
--this portion of the script runs 99.9% of the time
--do whatever you need to with the enteredFormula
end switch
end closeField
On Tue, Jan 6, 2015 at 12:38 AM, Graham Samuel <livf...@mac.com> wrote:
> Hi Craig - thanks for the reply.
>
> Yes, that’s what I’m having to do - but since my app allows the user to
> write formulae directly, I need to cheat so the user writes
>
> ln(x)
>
> and I intervene and redirect this to my adjusted version of the function,
> myLn. Luckily at the heart of the my app is a parser which can host this
> intervention, so it’s almost OK - as long as the user doesn’t take the
> option to look at the parser output. Still, it would have been nice to be
> able to redefine it: of course, if I did that I would either have to recode
> the fundamentals of the original function or somehow access it despite
> having replaced it from the point of view of the outside world.
>
> Graham
>
> > On 5 Jan 2015, at 15:41, dunb...@aol.com wrote:
> >
> > Graham
> >
> >
> > I thought the ability of HC to allow this was a plus. The best example
> was the "round" function, which, with a ".5" in the decimal portion of an
> argument, alternately rounded the integer portion up or down depending on
> whether that integer was odd or even.
> >
> >
> > Most people, like me, intercepted that function, and always rounded a
> ".5" up, like I was taught.
> >
> >
> > Anyway, when you ask for a "trick", why not just create "myLn". After
> all, you are the author.
> >
> >
> > Craig
> >
> >
> >
> > -----Original Message-----
> > From: Graham Samuel <livf...@mac.com>
> > To: How to use LiveCode <use-livecode@lists.runrev.com>
> > Sent: Mon, Jan 5, 2015 7:55 am
> > Subject: Is there a way to replace a built-in function?
> >
> >
> > On the face of it, it’s impossible to replace a built-in function in LC.
> For
> > example, take the function ln(x) - that’s natural logarithm. I’d like to
> > redefine ln(x), but I can’t because the compiler won’t let me use a
> reserved
> > word in a function definition.
> >
> > I wonder if anyone can suggest a trick to allow a redefinition like
> this. If
> > not, then roll on Widgets.
> >
> > Graham
> >
> > PS In case you want to know why I want to redefine this function, it’s
> for the
> > following reason. Generally, mathematicians say that ln(0) is undefined,
> > whereas the limit as x approaches zero is minus infinity. This is a bit
> subtle,
> > and LiveCode takes no real notice of this, so that in LC, ln(0) yields
> “-inf”.
> > Despite a contrary definition in the LC dictionary, this text is then
> regarded
> > as a number, which can cause confusion, at least to me. So my new ln(x)
> would
> > yield undefined for ln(0) and would use a symbol for minus infinity
> which LC
> > would not then recognise as a number.
> > _______________________________________________
>
>
> _______________________________________________
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
