Brent Dax [EMAIL PROTECTED] wrote:
Okay, reality check. How often are we going to use acosh? Is it really
worth the space in the vtable for that few calls? And why can't we just
use find_method?
Dan was talking about one vtable slot, holding another vtable for trig
and log functions. The
On Mon, Sep 22, 2003 at 04:08:24PM -0600, Luke Palmer wrote:
And let's not forget our handy trig identities. We definitely don't
need all those vtable. Technically, all we need are sine and arccosine.
I believe that atan2() is more useful than arccosine, as it returns
information about which
On Mon, 22 Sep 2003, Gregor N. Purdy wrote:
On a related note, I wonder how all this fits in with
methods and multimethods?
One-arg vtable methods don't have to do multimethod stuff, since you're
calling the vtable method on the argument, so it can do the right thing
without checking.
Two
Leopold Toetsch:
# Dan was talking about one vtable slot, holding another vtable for trig
# and log functions. The newly added vtable-data seems to be that. This
# trig_log (or data) pointer is shared by all scalar classes. So that
# takes one additional pointer per vtable and one additional
On Tue, 23 Sep 2003, Brent Dax wrote:
Leopold Toetsch:
# That's what happening anyway. All unimplemented stuff has a default
hook
# throwing an exception.
The indirection would allow for a default set. It's the difference
between eight default pointers per vtable (to default sections)
Brent Dax [EMAIL PROTECTED] wrote:
# The result would mean that something like:
# pmc-vtable-add
#
# Might become:
# pmc-vtable-math-add
#
# Seems too expensive to me for the normal math stuff.
Perhaps, although one dereference doesn't seem to painful to me.
Is there any reason we
Okay, since it seems reasonable to hang the trig functions off of PMCs,
we'd best get a list of the functions we want. I can think of:
pow
logarithm
square root (yes, I know, it's for speed)
Normal and hyperbolic versions of:
sine
cosine
tangent
cotangent
arcsine
arccosine
(Forgot to send this to the list. Again. *sighs*)
Dan Sugalski:
# Okay, since it seems reasonable to hang the trig functions off of
PMCs,
# we'd best get a list of the functions we want. I can think of:
#
# pow
# logarithm
# square root (yes, I know, it's for speed)
#
# Normal and
Brent Dax writes:
Dan Sugalski:
# Okay, since it seems reasonable to hang the trig functions off of
PMCs,
# we'd best get a list of the functions we want. I can think of:
#
# pow
# logarithm
# square root (yes, I know, it's for speed)
#
# Normal and hyperbolic versions of:
#
On a related note, I wonder how all this fits in with
methods and multimethods?
If we consider the current trig.ops as being equivalent
to, e.g. (expressed with approximate Perl 6 isms):
multi sub sin(Num $arg) : returns Num;
multi sub cos(Num $arg) : returns Num;
ASIDE
And, at some level
10 matches
Mail list logo
