Syntax across languages

[bearophileHUGS]

This post comes from a boring morning, if you are busy ignore this.
This post is only for relaxed people.

I've found this page, "Syntax Across Languages", it contains many
errors and omissions, but it's interesting.
http://merd.sourceforge.net/pixel/la...languages.html

Compared to the other languages Python comes out rather well, in quick
scan only few things look better in other languages (usually all/most
things are possible in all languages, so it's often just a matter of
brevity, elegance, etc):

- Nestable Pascal-like comments (useful): (* ... *)

- Information about the current line and file as Ruby:
__LINE__ __FILE__
Instead of the python version:
inspect.stack()[0][2] inspect.stack()[0][1]

- ~== for approximate FP equality

- comparison returns 4 values (i.e. inferior, equal, superior or not
comparable), as in Pliant:
"compare"

- identity function: "identity" as in Common Lisp (probably of little
use in Python).

- Exception retrying: after catching an exception, tell the snippet to
be re-run
"retry" as in Ruby

- object cloning: obj.copy() obj.deepcopy()

- accessing parent method:
super as in Ruby, instead as in Python:
super(Class, self).meth(args)

- recursive "flatten" as in Ruby (useful)

Probably there are some errors of mine too, there are many things I
don't know aboyt Python yet.

Bye,
bearophile

[Fredrik Lundh]

be************@lycos.com wrote:

- Information about the current line and file as Ruby:
__LINE__ __FILE__
Instead of the python version:
inspect.stack()[0][2] inspect.stack()[0][1]
(that's (mostly) CPython-dependent, and should be avoided)
- ~== for approximate FP equality
str(a) == str(b)
- comparison returns 4 values (i.e. inferior, equal, superior or not
comparable), as in Pliant: "compare"

cmp("a", "b") -1 cmp("a", "a") 0 cmp("b", "a") 1 cmp("ä", u"ä") Traceback (most recent call last):
File "<stdin>", line 1, in ?
UnicodeDecodeError: 'ascii' codec can't decode byte /.../

sure looks like four possible outcomes.
- identity function: "identity" as in Common Lisp (probably of little
use in Python).
id(a)
- Exception retrying: after catching an exception, tell the snippet to
be re-run "retry" as in Ruby x = 0
while 1: .... try:
.... x += 1
.... if x <= 5:
.... raise ValueError
.... except ValueError:
.... print "retry"
.... continue
.... else:
.... break
....
retry
retry
retry
retry
retry

- object cloning: obj.copy() obj.deepcopy()
import copy

(cloning is usually a sign of a design problem in python. if you think
you need it, you probably don't. if you really think you need it, import
copy.)
- recursive "flatten" as in Ruby (useful)

if you can define the semantics, it's a few lines of code. if you're not
sure about the semantics, a built-in won't help you...

etc.

</F>

[bearophileHUGS]

Thank you for the comments, Fredrik Lundh.

(that's (mostly) CPython-dependent, and should be avoided)<
Then a non CPython-dependent way of doing it can be even more useful.

sure looks like four possible outcomes.<
Right (but to me four explicit answers seem better than three answers
and an exception still).

id(a)<
I think in Python it can be something more like (but it's of little
use):
def identity(x): return x
Or:
identity = lambda x: x

(cloning is usually a sign of a design problem in python. if you think you need it, you probably don't. if you really think you need it,
import
copy.)<

I agree (importing a module is worse than using a standard copy method,
but I think this can be seen as a way to discourage the use of copy in
Python).

if you can define the semantics, it's a few lines of code. if you're not

sure about the semantics, a built-in won't help you...<

I think the language needs a fast built-in version of it. If something
is both inside Mathematica and Ruby, then probably it can be useful in
Python too :-)

Bye and thank you,
bearophile

[Fredrik Lundh]

be************@lycos.com wrote:

if you can define the semantics, it's a few lines of code. if you're not

sure about the semantics, a built-in won't help you...<

I think the language needs a fast built-in version of it. If something
is both inside Mathematica and Ruby, then probably it can be useful in
Python too :-)

numpy already has one:

http://numeric.scipy.org/numpydoc/nu...ml#pgfId-36512

(it's probably there in scipy too, but the scipy docs don't appear to be
freely available. hmm...)

PIL also has one:

http://www.effbot.org/imagingbook/im...getdata-method

there's also one in Tkinter:

import Tkinter
Tkinter._flatten(["abc", 1, 2, (3, 4, 5), None, [6, 7, 8, (9,)]])

('abc', 1, 2, 3, 4, 5, 6, 7, 8, 9)

to create a generic version, you have to decide which sequences to
treat like sequences, and which sequences you don't want to treat
like sequences...

</F>

[Fredrik Lundh]

be************@lycos.com wrote:

sure looks like four possible outcomes.<

Right (but to me four explicit answers seem better than three answers
and an exception still).

def cmp4(a, b):
try:
return cmp(a, b)
except:
return None

</F>

[bearophileHUGS]

Thank you Fredrik Lundh for showing everybody that indeed lot of people
feel the need of such function in Python too.

to create a generic version, you have to decide which sequences to treat like sequences<

In my version I give the function some parameter(s) to define what I
want to flatten. I'll probably put it in the cookbook...

Bye,
Bearophile

[Fredrik Lundh]

be************@lycos.com wrote:

Thank you Fredrik Lundh for showing everybody that indeed lot of people
feel the need of such function in Python too.

you seem to be missing the point: all those versions are highly optimized,
and tuned for the specific use-cases. a generic flatten would be useless
in all three cases.

</F>

[beza1e1]

>>> id("blub")
-1210548288

This is not identity in a mathematical view.

def identity(x): return x

It has is uses. I had some kind of parser and had a dict like this:
{case: function, ...} It had to be a dict, because i wanted to
dynamically add and remove cases. In some cases nothing had to be done.
To represent this in the dict a identity function is needed. There
surely are other ways, but identity was the most expressive in my eyes.

Nice read, by the way. Thanks for sharing ;)

[bonono]

just curious, how can this identity function be used ? In haskell,
because all functions are curried, I can sort of visualize/understand
how id is used. Not quite understand how it can be used in python.

beza1e1 wrote:

id("blub")

-1210548288

This is not identity in a mathematical view.

def identity(x): return x

It has is uses. I had some kind of parser and had a dict like this:
{case: function, ...} It had to be a dict, because i wanted to
dynamically add and remove cases. In some cases nothing had to be done.
To represent this in the dict a identity function is needed. There
surely are other ways, but identity was the most expressive in my eyes.

Nice read, by the way. Thanks for sharing ;)

[Fredrik Lundh]

"beza1e1" wrote:

It has is uses. I had some kind of parser and had a dict like this:
{case: function, ...} It had to be a dict, because i wanted to
dynamically add and remove cases. In some cases nothing had to be done.
To represent this in the dict a identity function is needed.

in Python, that's spelled "lambda x: x" (or "None", in some contexts)

</F>

[garabik-news-2005-05]

Fredrik Lundh <fr*****@pythonware.com> wrote:

- comparison returns 4 values (i.e. inferior, equal, superior or not
comparable), as in Pliant: "compare"

cmp("a", "b") -1 cmp("a", "a") 0 cmp("b", "a") 1 cmp("ä", u"ä") Traceback (most recent call last):
File "<stdin>", line 1, in ?
UnicodeDecodeError: 'ascii' codec can't decode byte /.../

that is not because of the comparison, but because of the coercion:

'ä'+u'ä' Traceback (most recent call last):
File "<stdin>", line 1, in ?
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 0: ordinal not in range(128)
sure looks like four possible outcomes.

cmp(1, 1+2j)

Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: cannot compare complex numbers using <, <=, >, >=
a fifth one :-)
--
-----------------------------------------------------------
| Radovan GarabÃ*k http://kassiopeia.juls.savba.sk/~garabik/ |
| __..--^^^--..__ garabik @ kassiopeia.juls.savba.sk |
-----------------------------------------------------------
Antivirus alert: file .signature infected by signature virus.
Hi! I'm a signature virus! Copy me into your signature file to help me spread!

[Alex Martelli]

<be************@lycos.com> wrote:
...

- Information about the current line and file as Ruby:
__LINE__ __FILE__
Instead of the python version:
inspect.stack()[0][2] inspect.stack()[0][1]
__file__ is around in Python, too, but there's no __line__ (directly).
- identity function: "identity" as in Common Lisp (probably of little
use in Python).
I've seen enough occurrences of "lambda x: x" in Python code with a
generally functional style that I'd love to have operator.identity (and
a few more trivial functions like that) for readability;-)
- object cloning: obj.copy() obj.deepcopy()
Like (say) container.length() versus len(container), I'm perfectly
comfortable relying on functions rather than methods. It even makes it
easier to allow several alternative ways for an object to provide such
functionality (e.g. by implementing __getstate__ and maybe __setstate__
as opposed to __copy__ and maybe __deepcopy__) -- which would be
feasible even with a method, of course (Template Method DP), but IS
easier when relying on functions (and operators).
- accessing parent method:
super as in Ruby, instead as in Python:
super(Class, self).meth(args)
Ruby's syntax may be better for a single-inheritance language, but
Python's, while less elegant, may be more appropriate in the presence of
multiple inheritance.
- recursive "flatten" as in Ruby (useful)

Usage too rare to deserve a built-in method, IMHO, considering the ease
of coding the equivalent:

def flatten(x):
if not isinstance(x, list): yield x
for y in x: yield flatten(y)

What I _do_ envy Ruby's syntax, a little, is the convention of ending
methodnames with exclamation mark to indicate "modifies in-place" (and,
secondarily, question mark to indicate predicates). The distinction
between, e.g.,
y = x.sort()
and
x.sort!()
in Ruby is much clearer, IMHO, than that between, say,
y = sorted(x)
and
x.sort()
in Python...
Alex

[Alex Martelli]

bo****@gmail.com <bo****@gmail.com> wrote:

just curious, how can this identity function be used ? In haskell,
because all functions are curried, I can sort of visualize/understand
how id is used. Not quite understand how it can be used in python.

There was a very recent example posted to this group (by Robin Becker, I
believe, looking for ways to "override property"), something like:
def __init__(self, validate=None):
if not validate: validate = lambda x: x
self.validate = validate
and later on, self.validate is always unconditionally called to extract
a valid value from an input argument to another method -- a nicer style,
arguably, than assigning self.validate unconditionally and then having
to test each and every time in the other method. Such subcases of the
well-known "Null Object" design pattern, where you don't want to store
None to mean "no such object" but, to avoid repeated testing, rather
want to store an object which "reliably does nothing", are reasonably
common. In an abstract way, they're somewhat akin to having the 'pass'
statement in the language itself;-).
Alex

[skip]

Alex> I've seen enough occurrences of "lambda x: x" in Python code with
Alex> a generally functional style that I'd love to have
Alex> operator.identity (and a few more trivial functions like that) for
Alex> readability;-)

But, but, but [Skip gets momentarily apoplectic, then recovers...]
"operator.identity" is way more to type than "lambda x: x". Plus you have
to remember to import the operator module. <0.5 wink>

Not to mention which (from "pydoc operator"):

[The operator module] exports a set of functions implemented in C
corresponding to the intrinsic operators of Python.

Last time I checked, Python didn't have an intrinsic "identity" operator.

For which reason, I'd be -1 on the idea of an identity function, certainly
in the operator module.

Skip

[Alex Martelli]

<sk**@pobox.com> wrote:

Alex> I've seen enough occurrences of "lambda x: x" in Python code with
Alex> a generally functional style that I'd love to have
Alex> operator.identity (and a few more trivial functions like that) for
Alex> readability;-)

But, but, but [Skip gets momentarily apoplectic, then recovers...]
"operator.identity" is way more to type than "lambda x: x". Plus you have
to remember to import the operator module. <0.5 wink>
But, it's way more readable, IMHO.

Not to mention which (from "pydoc operator"):

[The operator module] exports a set of functions implemented in C
corresponding to the intrinsic operators of Python.

Last time I checked, Python didn't have an intrinsic "identity" operator.
attrgetter and itemgetter don't exactly correspond to "intrinsic
operators", either (getitem, and the built-in getattr, are more like
that)... yet module operator exports them today, offering more readable
(and faster) alternatives to "lambda x: x[y]" and "lambda x: getattr(x,
y)".

For which reason, I'd be -1 on the idea of an identity function, certainly
in the operator module.

I'm not at all wedded to having 'identity' in the operator module (which
may arguably be the wrong placement for 'attrgetter' and 'itemgetter'
too). But identity is a useful primitive for a functional style of
Python programming, so having it SOMEwhere would be nice, IMHO.
Alex

[Tom Anderson]

On Sun, 23 Oct 2005, Fredrik Lundh wrote:

be************@lycos.com wrote:

- ~== for approximate FP equality

str(a) == str(b)

This is taken from the AIEEEEEEEE 754 standard, i take it? :)

Seriously, that's horrible. Fredrik, you are a bad man, and run a bad
railway.

However, looking at the page the OP cites, the only mention of that
operator i can find is in Dylan, and in Dylan, it's nothing to do with
approximate FP equality - it means 'not identical', which we can spell "is
not".

What would approximate FP equality even mean? How approximate?

- Exception retrying: after catching an exception, tell the snippet to
be re-run "retry" as in Ruby

x = 0
while 1: ... try:
... x += 1
... if x <= 5:
... raise ValueError
... except ValueError:
... print "retry"
... continue
... else:
... break
...
retry
retry
retry
retry
retry

That works well for trivial cases, and not at all for anything complex. If
you have this sort of structure:

def reverse_the_polarity_of_the_neutron_flow():
five_hundred_lines_of_code()
and_dozens_of_layers_of_nesting_and_indirection()
interrossitor.activate() # can raise InterrossitorError
do_what_we_came_here_to_do()

try:
reverse_the_polarity_of_the_neutron_flow()
except InterrossitorError:
degausser.degauss(interrossitor)
interrossitor.activate()
RETRY # how do you implement this?

You're in trouble. I realise that this snippet is not a hugely compelling
example, but the point is that there could be some corrective action that
you can take in an exception handler which, for some reason, you can't
write close enough to the source of the exception that control can carry
on flowing in the right direction.

What you can do - and this is fairly high-grade evil of a different sort -
is package the exception-handling specifics in a function, and pass that
in, to be applied at the appropriate point:

def reverse_the_polarity_of_the_neutron_flow(ie_hdlr):
five_hundred_lines_of_code()
and_dozens_of_layers_of_nesting_and_indirection()
try:
interrossitor.activate() # can raise InterrossitorError
except InterrossitorError, e:
ie_hdlr(e)
do_what_we_came_here_to_do()

def handle_interrossitor_error(e):
degausser.degauss(interrossitor)
interrossitor.activate()
reverse_the_polarity_of_the_neutron_flow(handle_in terrossitor_error)

You can even do extra bonus higher-order-functioning:

def reverse_the_polarity_of_the_neutron_flow(ie_hdlr):
five_hundred_lines_of_code()
and_dozens_of_layers_of_nesting_and_indirection()
ie_hdlr(interrossitor.activate)
do_what_we_came_here_to_do()

def handle_interrossitor_error(fn):
try:
fn()
except InterrossitorError, e:
degausser.degauss(interrossitor)
interrossitor.activate()
reverse_the_polarity_of_the_neutron_flow(handle_in terrossitor_error)

Although i can't see any reason why you'd want to.
- recursive "flatten" as in Ruby (useful)

if you can define the semantics, it's a few lines of code. if you're
not sure about the semantics, a built-in won't help you...

While we're on the subject, we had a big recursive flatten bake-off round
here a few months back: look for a thread called "flatten(), [was Re:
map/filter/reduce/lambda opinions andbackground unscientific
mini-survey]", and filter out the posts with code from the posts with
rants. There are all sorts of solutions, coming at the problem from
different angles, but the end of it is more or less here:

http://groups.google.co.uk/group/com...32db53bd2700db

Looking at the code now, i can see a couple of points where i could tweak
my flatten even more, but i think the few microseconds it might save
aren't really worth it!

tom

--
It is a laborious madness, and an impoverishing one, the madness of
composing vast books. -- Jorge Luis Borges

[Alex Martelli]

Tom Anderson <tw**@urchin.earth.li> wrote:
...

What would approximate FP equality even mean? How approximate?

In APL, it meant "to within [a certain quad-global whose name I don't
recall] in terms of relative distance", i.e., if I recall correctly,
"a=b" meant something like "abs(a-b)/(abs(a)+abs(b)) < quadEpsilon" or
thereabouts. Not too different from Numeric.allclose, except the latter
is "richer" (it takes both absolute and relative "epsilons", and also
implies an "and-reduce" if the objects being compared are arrays).
Alex

[Mike Meyer]

Tom Anderson <tw**@urchin.earth.li> writes:

On Sun, 23 Oct 2005, Fredrik Lundh wrote:

be************@lycos.com wrote:

- ~== for approximate FP equality

str(a) == str(b)

This is taken from the AIEEEEEEEE 754 standard, i take it? :)

Seriously, that's horrible. Fredrik, you are a bad man, and run a bad
railway.

However, looking at the page the OP cites, the only mention of that
operator i can find is in Dylan, and in Dylan, it's nothing to do with
approximate FP equality - it means 'not identical', which we can spell
"is not".

What would approximate FP equality even mean? How approximate?

Hopefully user defined. Rexx has a global control that lets you set
the number of digits to be considered significant in doing an FP
equality test.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Dennis Lee Bieber]

On Sun, 23 Oct 2005 20:59:46 -0400, Mike Meyer <mw*@mired.org> declaimed
the following in comp.lang.python:

Hopefully user defined. Rexx has a global control that lets you set
the number of digits to be considered significant in doing an FP
equality test.
That's the good part about the REXX model...

The bad part? It's based on the number of significant digits...
Rather than a true epsilon.
-- ================================================== ============ <
wl*****@ix.netcom.com | Wulfraed Dennis Lee Bieber KD6MOG <
wu******@dm.net | Bestiaria Support Staff <
================================================== ============ <
Home Page: <http://www.dm.net/~wulfraed/> <
Overflow Page: <http://wlfraed.home.netcom.com/> <

[bearophileHUGS]

Thank you for all the answers, some people have already answered for me
about most details I don't agree :-)

Mike Meyer>Rexx has a global control that lets you set the number of
digits to be considered significant in doing an FP equality test.<

Mathematica too, I think.
Tom Anderson>There are all sorts of solutions, coming at the problem
from different angles, but the end of it is more or less here:<

Interesting, but I think in Python the recursive solutions cannot be
used, because they are too much fragile (they break with not much
nested levels), an iterative solution (using a stack) can manage enough
levels before finishing the memory ("not much" and "enough" are
relative things, I know... but there is probably a difference of 10**4
times still). Note that statistically most real-life structures to
flatten are probably quite flat (the most common are probably of depth
2), so probably the non recursive solution is the better again :-)
Another problem with such solutions is that they don't allow to define
what to iterate over and what to not consider a sequence. This is
probably easy to define with an input parameter. (A compromise solution
is probably enough, without a fully general solution for this problem).
Another interesting possibility (suggested from Mathematica Flatten[]
syntax) is to add another parameter to specify how much levels to
flatten (all levels, only the first k levels, or all levels but the
last n levels), but maybe this last parameter can be a bit less easy to
remember, and Python functions are designed to be very easy to
remember.

Bye,
bearophile

[Mike Meyer]

Dennis Lee Bieber <wl*****@ix.netcom.com> writes:

On Sun, 23 Oct 2005 20:59:46 -0400, Mike Meyer <mw*@mired.org> declaimed
the following in comp.lang.python:

Hopefully user defined. Rexx has a global control that lets you set
the number of digits to be considered significant in doing an FP
equality test.

That's the good part about the REXX model...

The bad part? It's based on the number of significant digits...
Rather than a true epsilon.

Depends on what you mean by "a true epsilon". If you mean "I want the
two values to differ by at most 10^-5", then number of significant
digits is a better option. If you mean "I want the two values to
differ by at most 1 part in 10^5", then number of significant digits
is a slightly less flexible option.

You really, *really* don't want to specify the acceptable difference
as a fixed value. You want it to be relative to the size of objects
being compared. The latter is what number of significant digits gives
you. The downside is that you're restricted to values that are a power
of 10, and can't specify things like "I want the two values to differ
by at most one part in 34,000" or some such oddity. On the up side,
number of significant digits is (maybe was - been a long time since I
did any serious number crunching) a common form for expressing the
accuracy of a calculation.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Fredrik Lundh]

Tom Anderson wrote:

This is taken from the AIEEEEEEEE 754 standard, i take it? :)

Seriously, that's horrible. Fredrik, you are a bad man, and run a bad
railway.

However, looking at the page the OP cites, the only mention of that
operator i can find is in Dylan, and in Dylan, it's nothing to do with
approximate FP equality - it means 'not identical', which we can spell "is
not".

What would approximate FP equality even mean? How approximate?

so you don't really know what it is, but you're sure that "looks the same
when printed using a well-defined algorithm" can never be the answer ?

</F>

[Tim Roberts]

be************@lycos.com wrote:

This post comes from a boring morning, if you are busy ignore this.
This post is only for relaxed people.

I've found this page, "Syntax Across Languages", it contains many
errors and omissions, but it's interesting.
http://merd.sourceforge.net/pixel/la...languages.html

Compared to the other languages Python comes out rather well, in quick
scan only few things look better in other languages (usually all/most
things are possible in all languages, so it's often just a matter of
brevity, elegance, etc):

- Nestable Pascal-like comments (useful): (* ... *)

That's only meaningful in languages with begin-comment AND end-comment
delimiters. Python has only begin-comment. Effectively, you CAN nest
comments in Python:
cool = 17

# The following section of code has been commented out.
#
# call_function( cool )
#
# # This would be neater if I had a real-life example.
# # As it is, it looks silly.
#
# print "New result", cool

print "All done"
--
- Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc.

[Duncan Booth]

Tim Roberts wrote:

- Nestable Pascal-like comments (useful): (* ... *)

That's only meaningful in languages with begin-comment AND end-comment
delimiters. Python has only begin-comment. Effectively, you CAN nest
comments in Python:

I believe that the OP is mistaken. In standard Pascal comments do not nest,
and you can mix delimiters so, for example:

(* this is a comment }

Most Pascal implementations require the delimeters to match and allow you
to nest comments which use different delimiters, but I'm not aware of any
Pascal implementations which would allow you to nest comments with the same
delimiter:

(* This is not a valid (* comment within a comment. *) *)

To this extent Python (if you consider docstrings as a type of comment)
does exactly the same thing:

""" this is # a docstring! """

# and this is """ a comment """

[Bengt Richter]

On 25 Oct 2005 07:46:07 GMT, Duncan Booth <du**********@invalid.invalid> wrote:

Tim Roberts wrote:

- Nestable Pascal-like comments (useful): (* ... *)

That's only meaningful in languages with begin-comment AND end-comment
delimiters. Python has only begin-comment. Effectively, you CAN nest
comments in Python:

I believe that the OP is mistaken. In standard Pascal comments do not nest,
and you can mix delimiters so, for example:

(* this is a comment }

Most Pascal implementations require the delimeters to match and allow you
to nest comments which use different delimiters, but I'm not aware of any
Pascal implementations which would allow you to nest comments with the same
delimiter:

(* This is not a valid (* comment within a comment. *) *)

To this extent Python (if you consider docstrings as a type of comment)
does exactly the same thing:

""" this is # a docstring! """

# and this is """ a comment """

Dusting off old ((c) '74, corrected '78 printing, bought in '79)
Jensen/Wirth Pascal User manual & Report, 2nd edition:
(had to search, since 'comment' was not in the index!)
"""
The construct
{ <any sequence of symbols not containing "}"> }
maybe inserted between any two identifiers, numbers (cf. 4), or
special symbols. It is called a _comment_ and may be removed from
the program text without altering its meaning. The symbols { and
} do not occur otherwise in the language, and when appearing in
syntactic description they are meta-symbols like | and ::= .
The symbols pairs (* and *) are used as synonyms for { and }.
"""

I suspect whether you can match a (* with a } depends on a particular
implementation. I think I have run across at least one where they
were independent, so you could use one to comment out blocks of
mixed program and comment source commented with the other.

.... aha, it must have been Borland Delphi Object Pascal:
"""
The following constructs are comments and are ignored by the compiler:
{ Any text not containing right brace }
(* Any text not containing star/right parenthesis *)
A comment that contains a dollar sign ($) immediately after the opening { or (* is a
/compiler directive/. A mnemonic of the compiler command follows the $ character.
"""

Regards,
Bengt Richter

[gene tani]

APL, i haven't thought about that in 15 years. I think it was (quad)CT
for comparison tolerance, at least in IBM APL.

Alex Martelli wrote:

Tom Anderson <tw**@urchin.earth.li> wrote:
...

What would approximate FP equality even mean? How approximate?

In APL, it meant "to within [a certain quad-global whose name I don't
recall] in terms of relative distance", i.e., if I recall correctly,
"a=b" meant something like "abs(a-b)/(abs(a)+abs(b)) < quadEpsilon" or
thereabouts. Not too different from Numeric.allclose, except the latter
is "richer" (it takes both absolute and relative "epsilons", and also
implies an "and-reduce" if the objects being compared are arrays).
Alex