At 9:22 AM -0700 7/14/06, Dave Whipp wrote:
Darren Duncan wrote:
Assuming that all elements of $a and $b are
themselves immutable to all levels of
recursion, === then does a full deep copy like
eqv. If at any level we get a mutable object,
then at that point it turns into =:= (a trivial
"Mark A. Biggar" schreef:
> Darren Duncan:
>> Now, I didn't see them yet anywhere in Synopsis 3, but I strongly
>> recommend having negated versions of all these various types of
>> equality tests. Eg, !== for ===, nev for eqv, etc. They would be
>> u
Darren Duncan wrote:
Assuming that all elements of $a and $b are themselves immutable to all
levels of recursion, === then does a full deep copy like eqv. If at any
level we get a mutable object, then at that point it turns into =:= (a
trivial case) and stops.
( 1, "2.0", 3 ) =
Darren Duncan wrote:
Now, I didn't see them yet anywhere in Synopsis 3, but I strongly
recommend having negated versions of all these various types of equality
tests. Eg, !== for ===, nev for eqv, etc. They would be used very
frequently, I believe (and I have even tried to do so), a
Yuval Kogman writes:
> On Fri, Jul 14, 2006 at 11:42:24 +0100, Smylers wrote:
>
> > Or rather, while I can manage to read an explanation of what one of
> > these operators does and see how it applies to the variables in the
> > examples next to it, I am struggling to ret
On Fri, Jul 14, 2006 at 11:42:24 +0100, Smylers wrote:
> I'm afraid I still don't get it.
>
> Or rather, while I can manage to read an explanation of what one of
> these operators does and see how it applies to the variables in the
> examples next to it, I am struggli
Yuval Kogman writes:
> So, Larry assisted by Audrey explained the purpose of === vs eqv vs
> =:=.
I'm afraid I still don't get it.
Or rather, while I can manage to read an explanation of what one of
these operators does and see how it applies to the variables in the
examples
x27;t
implicitly coerce its arguments to a particular type?
Yes, absolutely. The === takes 2 arguments exactly as they are,
without changing anything, and says if they are two appearances of
the same value. It would always return false if the 2 arguments are
of different declared types. And if they a
At 10:36 PM -0700 7/13/06, Jonathan Lang wrote:
So the purpose of === is to provide a means of comparison that doesn't
implicitly coerce its arguments to a particular type?
Yes, absolutely. The === takes 2 arguments exactly as they are,
without changing anything, and says if they ar
Yuval Kogman wrote:
Jonathan Lang wrote:
> Apparently, there are _four_ basic kinds of comparison: the ones
> mentioned above, and == (I believe that eq works enough like == that
> whatever can be said about one in relation to ===, =:=, or eqv can be
> said about the other).
On Thu, Jul 13, 2006 at 21:55:15 -0700, Jonathan Lang wrote:
> Apparently, there are _four_ basic kinds of comparison: the ones
> mentioned above, and == (I believe that eq works enough like == that
> whatever can be said about one in relation to ===, =:=, or eqv can be
> said abo
On Thu, Jul 13, 2006 at 12:50:19 -0700, Larry Wall wrote:
> On Thu, Jul 13, 2006 at 09:32:08PM +0300, Yuval Kogman wrote:
> : [1] My preferred ergonomics:
> :
> : 1. eqv goes away
> : 2. what was eqv is renamed to ===
> : 3. === becomes =:=, which has a "constant" feel to it
> : 4.
David Green wrote:
I think I understand it... (my only quibble with the syntax is that
=== and eqv look like spin-offs of == and eq, but I don't know what
to suggest instead (we're running short of combinations of = and : !))
Agreed.
So there are three basic kinds of comparison: w
On 7/13/06, Yuval Kogman wrote:
So, Larry assisted by Audrey explained the purpose of === vs eqv vs =:=.
It makes sense now, but I still feel that as far as ergonomics go
this is not perfect.
I think I understand it... (my only quibble with the syntax is that
=== and eqv look like spin-offs
At 5:36 PM +0300 7/13/06, Yuval Kogman wrote:
> User defined types can choose on their own whether to override
=== and/or .id or not, and they would use their own knowledge of
their internal structures to do an appropriate
deep comparison. There is no need to try to generate some kind
On Thu, Jul 13, 2006 at 12:50:19PM -0700, Larry Wall wrote:
: Then $a eqv $b and $a leg $b both just default to a signature that selects
: everything.
Though arguably P5's string-forcing semantics should be C and the
polymorphic semantics should probably be C.
Larry
y interested in eqv-ness rather than cmp-ness.
In fact, cmp (or something like it) also wants to take a third parameter:
leg($a,$b, :($x is num,$y is rev));
and then sort is just done with the same signature:
sort :($x is num,$y is rev), @foo;
or some such, however you want to canonical
So, Larry assisted by Audrey explained the purpose of === vs eqv vs
=:=.
It makes sense now, but I still feel that as far as ergonomics go
this is not perfect. Then again, I trust that Larry's opinion is
probably better and at the very least more likely to be accepted
than mine ;-) [1]
So,
Audrey has asked me to split S29 AKA Perl6/Spec/Functions.pod up due to
its rapidly expanding size. The strategy that she suggested is basically
what I'm leaning toward, but I wanted to get feedback (esp. from Larry
and other Synopsians).
I want to be clear, I'm not asking for help comi
t;USD" );
$hash{$x} = 1;
say $hash{$y}; # 1
will DWIM. But this really depends on both the item being used,
*and* the way it is being used.
So I can see the value of making the second type of keying possible
and easy with an .id method (which at the very lowest level can
probabl
At 7:25 PM +0300 7/12/06, Yuval Kogman wrote:
Over at #perl6 we had a short discussion on =:=, ===, and ~~, mostly raised by
ajs's discussion on Str items and ===.
Coincidentally, I raised almost the same questions there a week
earlier, and had a brief discussion with audreyt abo
Yuval Kogman wrote:
On Wed, Jul 12, 2006 at 17:58:03 -0400, Aaron Sherman wrote:
Then ~~ is wrong in that respect, and I think we should be talking about
that, not about making === into "~~, but without invoking code when it
shouldn't."
But it should! It's the sma
Deep implies arbitrary work, which isn't
> really what you want in such a low-level operator. However, using these
> operator, one could easily build whatever you like.
The number of times i *sigh*ed at having to reinvent deep operators
in a clunky way in Perl 5 is really not in line
On Wed, Jul 12, 2006 at 17:58:03 -0400, Aaron Sherman wrote:
> Then ~~ is wrong in that respect, and I think we should be talking about
> that, not about making === into "~~, but without invoking code when it
> shouldn't."
But it should! It's the smart match! If the
out performance
That's orthogonal. .id is used for hash keys. If you're keying y
hubble images then they must be unique for some keyspace, and that's
where .id makes a mapping.
> =:= looks in the "symbol table" (caveat dragons) to see if LHS
> refers
*will* return true for @foo = ( [ 1, 2 ], 3 ); @bar = ( [ 1, 2 ], 3 );
> > > op(@foo, @bar)?
> > > Is it going to be easy to make the newbies use that when they mean "it's
> > > the
> > > same", like they currently expect == and eq to work on &q
p(@foo, @bar)?
> > Is it going to be easy to make the newbies use that when they mean "it's the
> > same", like they currently expect == and eq to work on "simple" values?
>
> Isn't that ~~?
>
> Per S03:
>
> Array Array arr
On Wed, 2006-07-12 at 19:25 +0300, Yuval Kogman wrote:
> Over at #perl6 we had a short discussion on =:=, ===, and ~~, mostly raised by
> ajs's discussion on Str items and ===.
*wave*
> 1. what is .id on references? Is it related to the memory slot, like refaddr()
> in Perl 5?
Jedai and I went through some of pugs current implementations. Here's a list of
what we expect the operators to return and what they currently do.
This does not exactly agree with S03 right now, but is our opinion.
Force into a type before comparing values:
42 == 42 - true, same nu
If we do have deep value equality checks, then "default" == and eq
are probably:
sub &infix:<==> ( $x, $y ) {
+$x === +$y;
}
sub &infix: ( $x, $y ) {
~$x === ~$y;
}
So that the compare-as-sometype behavior
Over at #perl6 we had a short discussion on =:=, ===, and ~~, mostly raised by
ajs's discussion on Str items and ===.
After a brief discussion we managed to formulate several questions that we feel
are slightly to totally unresolved.
1. what is .id on references? Is it related to the memory
On Tue, Jul 11, 2006 at 16:46:40 -0400, Aaron Sherman wrote:
> There's a bit at the end of the current S29:
>
> =item A/S??: OS Interaction
>
> I've taken on a few of these, and in doing so found that I was making
> some assumptions. I'd like to share
There's a bit at the end of the current S29:
=item A/S??: OS Interaction
I've taken on a few of these, and in doing so found that I was making
some assumptions. I'd like to share those and see if they make sense:
* POSIX will be a low-level module that slavishly
t wrecked my MacBook Pro with the coffee I was
sipping :)
I think I found the reason why Pugs knows the exact value of
infinity. That's GHC that tells pugs the exact value thereof.
This is Infinity according to Pugs.
./src/Pugs/AST/Internals.hs
doCast (VStr "Inf") = return $
On Tue, Jul 04, 2006 at 05:27:33PM +0100, Nicholas Clark wrote:
: I'm not convinced that sprintf needs an operator. It's not commonly used in
: any code I've looked at, which to me suggests that it's not good huffman
: coding to use up a terse symbol for it, denying that symbol to something
: else.
On Tue, Jul 04, 2006 at 05:06:54PM +1000, Brad Bowman wrote:
> Hello,
>
> It seems that sprintf is will still be around in Perl 6 [1],
> and that sprintf formats will be available using the .as() method.
> While looking at some Python docs [2] I noticed two things that might
>
On Tue, Jul 04, 2006 at 05:06:54PM +1000, Brad Bowman wrote:
: Hello,
:
: It seems that sprintf is will still be around in Perl 6 [1],
: and that sprintf formats will be available using the .as() method.
: While looking at some Python docs [2] I noticed two things that might
: be worth stealing
Hello,
It seems that sprintf is will still be around in Perl 6 [1],
and that sprintf formats will be available using the .as() method.
While looking at some Python docs [2] I noticed two things that might
be worth stealing; a sprintf operator (%) and named parameters in
the format string:
a
What is supposed to happen if one says:
class Dog {
has $:tail handles 'wag';
meth wag { # something else than $:tail.wag
}
}
Is it a compilation error? Or one of the definitions prevail (with a
warning or something)?
Adriano Ferreira.
> Mapping Pairs with no duplicate keys
>
> I would like to know if Mapping.does(Set) and whether I could use the
> full range of Set operators on them, as I would like to do?
>
> My impression is that it be reasonable to define a generic Mapping as
> being a Set whose elem
Lately I've been wanting to cross-apply features of the Set type to
the Mapping type, as well as of the Hash type to both of those, as I
see all of these as being very similar to each other conceptually and
in some cases interchangeable.
1. Looking at the language in Synopsis 6 for data
On Sat, Jun 24, 2006 at 04:52:26PM -0700, Audrey Tang wrote:
> $x = 1 if my $x;
>
> The compiler is "allowed" to complain, but does that means it's also
> okay to not die fatally, and recover by pretending as if the user has
> said this?
>
> # Cu
在 2006/6/24 上午 8:41 時，Patrick R. Michaud 寫到：
because later in the scope $x may be declared, so it's safer to just
put OUTER right there.
I don't think $x can be declared later in the scope. According to
S04,
If you've referred to $x prior to the first declarati
Jonathan Scott Duff wrote:
>> sub cond(Bool $c, $a, $b) is rw {
>> if $c return $a else return $b;
>> }
>>
>> Will this fail because $a and $b are not rw? If so, will it fail at run-
>> or compile-time? What about this:
>>
> That looks l
I don't have any real answers, but I'll weigh in with my opinion
anyway :-)
On Tue, Jun 20, 2006 at 10:59:01AM +0100, Daniel Hulme wrote:
> I've just thought of an interesting interaction with lvalue functions
> and call by foo. What if I want to write, say, an lvalue
I've just thought of an interesting interaction with lvalue functions
and call by foo. What if I want to write, say, an lvalue ?? !! function
thus
sub cond(Bool $c, $a, $b) is rw {
if $c return $a else return $b;
}
Will this fail because $a and $b are not rw? If so, will it fail at ru
在 2006/6/3 下午 3:03 時，Shu-Chun Weng 寫到：
I'll then rewrite most of my rules into tokens. And about the
definition of , the "engine" I mentioned is Pugs::Complier::Rule,
so that if what PGE does is considered the "correct" way, I will
change the behavior of P::C::Rule.
Hi,
Thanks for the comments :)
I'll then rewrite most of my rules into tokens. And about the
definition of , the "engine" I mentioned is Pugs::Complier::Rule,
so that if what PGE does is considered the "correct" way, I will
change the behavior of P::C::Rule. By the w
Patrick R. Michaud wrote:
Jerry is correct that S05 is the place to look for information
on this. But to summarize an answer to your question:
Thank you very much for the swift and thorough answer. It answered all
my questions. Your reply was very pedagogical and deserves to go into
the
On Fri, Jun 02, 2006 at 01:56:55PM -0700, jerry gay wrote:
> On 6/2/06, Rene Hangstrup Møller <[EMAIL PROTECTED]> wrote:
> >I am toying around with Parrot and the compiler tools. The documenation
> >of Perl 6 grammars that I have been able to find only describe rule. But
>
On 6/2/06, Rene Hangstrup Møller <[EMAIL PROTECTED]> wrote:
Hi
I am toying around with Parrot and the compiler tools. The documenation
of Perl 6 grammars that I have been able to find only describe rule. But
the grammars in Parrot 0.4.4 for punie and APL use rule, token and regex
elements
effects will have
been successful as well, or a failure/exception is still thrown.
What happens in Perl itself and what happens as external side effects
are tied together from the invoker's point of view as one unit that
should entirely succeed or entirely fail. Even if the side-effects
On Fri, Jun 02, 2006 at 02:17:25PM +0800, Shu-chun Weng wrote:
> 1. Spaces at beginning and end of rule blocks should be ignored
> since space before and after current rule are most likely be
> defined in rules using current one.
> 1a. I'm not sure if it's "cl
another perl 6 grammar to describe it. It works well several
days before when the parsing engine written in perl 5 did not
implemented :ratchet and :sigspace flags.
The grammar file can be found here:
http//svn.openfoundry.org/pugs/misc/pX/Common/Pugs-Grammar-MiniPerl6/lib/Pugs/Grammar/MiniPer
"Jonathan Scott Duff" <[EMAIL PROTECTED]> wrote:
On Thu, Jun 01, 2006 at 02:22:12PM -0700, Jonathan Lang wrote:
Forgive this ignorant soul; but what is "STM"?
Software Transaction Memory
Well, Software Transactional Memory if I'm being picky. :-) Some info
On Thu, Jun 01, 2006 at 02:22:12PM -0700, Jonathan Lang wrote:
> Larry Wall wrote:
> >The way I see it, the fundamental difference is that with ordinary
> >locking, you're locking in real time, whereas with STM you potentially
> >have the ability to virtualize time to see if there's a way to order
Larry Wall wrote:
The way I see it, the fundamental difference is that with ordinary
locking, you're locking in real time, whereas with STM you potentially
have the ability to virtualize time to see if there's a way to order
the locks in virtual time such that they still make sense. Then you
jus
On Thu, Jun 01, 2006 at 11:52:59AM +1200, Sam Vilain wrote:
: The lock on entry approach will only be for non-threaded interpreters
: that don't know how to do real STM.
The way I see it, the fundamental difference is that with ordinary
locking, you're locking in real time, whereas with STM you po
ommits if that context is exited normally, and
> it rollsback implicitly if the context exits with a 'fail' and/or due
> to a thrown exception. (And yes, I see it as being easier to use if
> rollback and fail are generally joined at the hip.)
There are also 'lazy atomic' ac
tion) or more like a continuation that when resumed can
see the atomic changes, and when exiting finally applies them (or rolls
back). Perhaps someone else will have more of a clue.
Sam.
Rather than thinking about "save points", it would be better to think
of the problem in terms of "ch
Daniel Hulme wrote:
>>How does an atomic block differ from one in which all variables are
>>implicitly hypotheticalized?
>>
>>
>I assume that the atomicness being controlled by some kind of lock on
>entry, it also applies to I/O and other side-effecty things tha
forcing bad things
to happen.
With Haskell this is sorted out by making the default "pure", and
everything else must be in a Monad. However we're not into bondage here
so "is pure" is not default. Instead we just die and rollback just
before I/O is attempted. In principle,
> How does an atomic block differ from one in which all variables are
> implicitly hypotheticalized?
I assume that the atomicness being controlled by some kind of lock on
entry, it also applies to I/O and other side-effecty things that you
can't undo.
--
Hats are no worse for be
How does an atomic block differ from one in which all variables are
implicitly hypotheticalized? I'm thinking that a "retry" exit
statement may be redundant; instead, why not just go with the existing
mechanisms for successful vs. failed block termination, with the minor
modification that when an
I would expect qX() to call a function. Knowing the macro,
I'd expect it to do q :x :y :z() and then treat the ; as the delimiter, which
probably means the macro should have been written:
qX ::= "q:x:y:z ";
and then the qX() form either does "q:x:y:z ()" or calls the qX
> qX ::= "q:x:y:z";
>
> as a simple, argumentless "word" macro.
But would that DWIM when I come to write
qX(stuff, specifically not an adverb argument);
?
--
"The rules of programming are transitory; only Tao is eternal.
Therefore you must contemplate Tao before you receive en
arator allows you to combine any of the existing adverbial
: forms above without an intervening colon:
:
:quote qw; # declare a P5-esque qw//
:
:
: there's trouble if both q (:single) and qq (:double) are allowed
: together. how would qqq resolve? i say it makes sense that we get
thout an intervening colon:
quote qw; # declare a P5-esque qw//
there's trouble if both q (:single) and qq (:double) are allowed
together. how would qqq resolve? i say it makes sense that we get
longest-token matching first, which means it translates to :double
followed by :single.
~jerry
In Perl5, the meaning of the undef value is overloaded. It can mean
either the value an uninitialized variable or it may indeed mean a
genuine undefined value. Perl5 is biased toward the first meaning: in
string context, the value behaves as an empty string; In integer
and float context, it
;t want the subarrays, then
use C instead:
(0..2; 'a'..'c') ==> my @;tmp;
for @;tmp.map { say }
and then you just get 0,'a',1,'b',2,'c'. This is good for
for @;tmp.map -> $i, $a { say "$i: $a" }
*
The reference to C and the use of .map don't match.
-'f
ted, a
sequence matching:
/\s+ \. [|]/
is always a unary dot method call.
The reason we chose that is because we think that things like this:
method describe {
say .name;
say .rank;
say .serial_num;
}
and this:
given %data {
. = join
.selectcolumn($j).
.say;
is the worst of both worlds? And it strikes me that the ability to put
big, block comments between operator and operand is not a particularly
useful one.
--
"Of all things, good sense is the most fairly distributed: everyone
thinks he is so well supplied with
On Wednesday 12 April 2006 00:06, TSa wrote:
> Doesn't that discontinuity devalue the long dot? Its purpose is
> alignment in the first palce. For a one char diff in length one
> now needs
>
> foo. .bar;
> self. .bar;
>
> instead of
>
> foo .bar;
> self.bar;
Or even:
fo
HaloO,
Larry Wall wrote:
On Tue, Apr 11, 2006 at 12:41:30PM +0200, TSa wrote:
: I'm unsure what the outcome of the recent long dot discussions is
: as far as the range operator is concerned.
.. is always the range operator. The "dot wedge" just has a discontinuity
in it there. I can't think o
On Tue, Apr 11, 2006 at 12:41:30PM +0200, TSa wrote:
: I'm unsure what the outcome of the recent long dot discussions is
: as far as the range operator is concerned.
.. is always the range operator. The "dot wedge" just has a discontinuity
in it there. I can't think of any wedgey applications th
HaloO,
I'm unsure what the outcome of the recent long dot discussions is
as far as the range operator is concerned. Since the whole point
of the long dot is to support alignment styles the following cases
shouldn't mean different things:
foobar #0 single call to foobar (OK, that is diffe
Dan Kogai wrote:
~slurp $file;
Very clever. But still not good enough when it comes to autoboxing.
{ ~slurp }($*PROGRAM_NAME).print
and even
(~slurp $*PROGRAM_NAME).print
works as expected but since "~slurp $file" is really ~(slurp $file),
$*PROGRAM_NAME.~slurp.print
On Apr 08, 2006, at 19:34 , Dan Kogai wrote:
does not. The problem of ~stringify, ?boolify, and +numify is that
they are infix operators so it goes the opposite direction.
s/infix/prefix/
Sorry.
Dan the Perl6 Golfer on the Bunker
oxing.
{ ~slurp }($*PROGRAM_NAME).print
and even
(~slurp $*PROGRAM_NAME).print
works as expected but since "~slurp $file" is really ~(slurp $file),
$*PROGRAM_NAME.~slurp.print
does not. The problem of ~stringify, ?boolify, and +numify is that
they are infix operators so it go
Dan Kogai wrote:
With that understood, I would welcome if we have a version of slurp()
which unconditionally returns a scalar.
That'd be:
~slurp $file;
:-)
Damian
Folks,
This is a poetic quine (or quine-maker) in perl5.
open myself, $0 and print ;
The same thing in perl6 would be:
my $self = open $*PROGRAM_NAME; for =$self { say }
or
my $self = open $*PROGRAM_NAME; say for =$self;
or
my $self = slurp $*PROGRAM_NAME; print $self;
or even
On Mon, Apr 03, 2006 at 08:24:51PM -0700, Larry Wall wrote:
: There's some discussion about whether it should simply be:
:
: method as (Str) {...}
: method as (Int) {...}
:
: maybe with an "is deep" thrown in for good measure, but we haven't
: quite got there yet.
Er, to have multiple of
On Mon, Apr 03, 2006 at 07:23:28PM -0700, Joshua Choi wrote:
: Kudos to all on the Perl 6 mailing list,
:
: What's the conceptual difference (or relationship) between context and type
: coercion? Is
: $moose.prefix:<~>
: the same as
: $moose.coerce:(Str)
: for instance?
No
Kudos to all on the Perl 6 mailing list,
What's the conceptual difference (or relationship) between context and type
coercion? Is
$moose.prefix:<~>
the same as
$moose.coerce:(Str)
for instance?
And forgive my brain, but how would you nicely define coercion in a class?
Like
ethod (well role really) to the class ^Object.
> There is no such thing as ^$object IIRC.
Upon a closer reading of S12, it appears that both are valid:
"prefix:<^>" is syntactic sugar for method meta, and it returns the
object's metaclass; thus, ^$object is equivalent to
> > 5 OO.
>
> Sounds reasonable. I'm curious: can anyone think of any _public_ uses
> for subs that are declared within classes?
Same uses they would have in Perl 5 I would guess, but I don't usually
do that in Perl 5 so I am hard pressed to come up with a specific
d within classes?
> Having methods outside of classes is less useful, and most of it's
> uses are pretty esoteric, however I see no good reason not to allow it
> (especially anon methods, as they are critical to being able to do
> some of the cooler meta-model stuff).
OK; so dec
nctions
easier. You could also use private methods for this, but if I dont
need to pass the object instance, why make me? I will say that I think
this distinction will be difficult at first for people steeped in Perl
5 OO.
Having methods outside of classes is less useful, and most of it's
uses a
erl 6 is specced such that it's always separate compilation, so
this should probably always be 0, unless you're tying the value to
disk.
The way it's handled:
$m is reallocated every time a module is used, and thrown away after
it finished compiling.
Then the resulting code will be
One way to think of your macro example (instead of the ->import one,
which is harder to define, i think):
Every time you use a module it's used by the compiler, and by the
emitted code.
The compiler loads the macros, the emitted code loads the non-macro
stuff.
Since the clsoure is cr
The problem seems to be that we have statefulness that we expect to
survive compilation boundaries.
So, should each compilation unit get a fresh environment? Or should
this simply work like I think it currently does, and just hopefully
not bite people too often? Should doing what this is
Larry Wall wrote:
> A multi sub presents only an MMD interface, while a multi method presents
> both MMD and SMD interfaces. In this case, there's not much point in the
> SMD inteface since .. used as infix is always going to call the MMD interface.
So:
multi method : MMD and S
On Wed, Mar 01, 2006 at 09:09:30PM -0700, Joshua Choi wrote:
: Kudos to all the Perl 6 mailing list.
Not to mention all the people on the list... :-)
: What's the difference between
: multi sub infix:<..> ( Int $min, Int $max ) { ... }
: and
: multi method infix:<..> ( I
Kudos to all the Perl 6 mailing list.
What's the difference between
multi sub infix:<..> ( Int $min, Int $max ) { ... }
and
multi method infix:<..> ( Int $min, Int $max ) { ... }
?
And in the case there isn't one, what's the point of declaring if it's a
"
like that. Computer science has quite
> different ideas about mathematics than those of chalkboard algebra.
...which is why I specified "mathematical function"; I was
intentionally referring to the chalkboard algebra meaning. But I can
see where the confusion came from.
> x^(1/2) is a multi
as quite
different ideas about mathematics than those of chalkboard algebra.
x^(1/2) is a multivalued function and x^2 is a single valued function but they
are both pow(x ,y). The likes of yacc have other ideas causing -2^2 to become
+4 (thankfully not in perl) and sqrt(x) to become single valued pos
e indexing.
> It is worth much more effort to just return a
> consistent principle value and getting the branch cuts and the handling
> of signed zero correct then to worry about trying to return multiple
> values in these cases.
Agreed. That's why my mention of list conte
ement list of the positive and negative
roots, in that order. This option would apply to sqrt, exp, log, and
the trig functions.)
I was thinking functions like sqrt would return a disjunction... I
suppose it's probably still most useful to return a single scalar by
default, so there wou
itive and negative
roots, in that order. This option would apply to sqrt, exp, log, and
the trig functions.)
I was thinking functions like sqrt would return a disjunction... I
suppose it's probably still most useful to return a single scalar by
default, so there would be some pragma via
ng a base to a Complex exponent raises the base's
absolute value by the real component of the exponent, and rotates its
angle (as measured in radians) by the imaginary component.
All of the trig functions can be aliased to expressions using exp
and log. This may be useful for the purpose of
1301 - 1400 of 5022 matches
Mail list logo
