Syntax across languages

[Mike Meyer]

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

 

[Fredrik Lundh]

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]

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/language-study/syntax-across-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"

 

[Duncan Booth]

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]

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.

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