[ruby-talk:00418] Re: New feature for Ruby?
From:
gotoken@... (GOTO Kentaro)
Date:
1999-07-01 18:07:59 UTC
List:
ruby-talk #418
Hi
Sorry for being not published of FromJapan. I'm busily occupied with
my work :(
But today I bring good news from one of my jobs; An academic project
started to use Ruby! It is decieded last week at Tokyo and it goes on
with much activity :-) They consider ruby is much useful to weather
data processings. Some numerical extensions will be discuss there.
In message "[ruby-talk:00416] Re: New feature for Ruby?"
on 99/07/01, Clemens Hintze <c.hintze@gmx.net> writes:
>(e) allow to give the "succ" method (and the corresponding "pred"
> one) a stepsize as optional argument.
Some elements have no natural predecessor; What is `"a".pred'?
And I think such iteration is too complex to generalize by Range.
But the option itself of succ is not bad because its meaning is quite
clear. It also fits to Peano's axiom :-)
>> (a) Range is range, not interval; I think you'd better define
>> Interval class to do the work.
>
>Ahem... <think>, <think>, <think>... Ok! I can understand your
>reasons. But if so, do you think, it would be useful, to have a
>build-in syntax for creating an Interval? I very like it to have
>(a..b).each{...}. But I don't know, whether it is necessary or not.
How about think `beg ::: to'? It may be not ambiguous. A constant
NINFINITY and INFINITY maybe useful as sentinels to represent an
one-side or bi-infinite interval. And also open/closed bound
distinction maybe helpful. I propose =:::=, =:::, :::= and ::: for
those. For example `beg =::: to' means an interval greater than or
equal to `beg' and less than `to'. But it is not appreciate to the
current syntax maybe.
# open/closed is not accurate expression because it's of topologies.
>But thinking more and more about it, I think it would be better to
>have an Interval class and let the Range class be untouched!
I think so. However Range and Interval should have distinct
roles. Now, Range manages iterations and memberships. I think Interval
should be devoted to managing membership.
>> (c) I'm not sure; I'd like to hear others' opinion.
>
>I think, if you mean we should have Interval instead of Range, I
>don't think, it would be necessary to have the "[]" method. :-)
Not bad, but when we need `[]'? I don't feel it is so general.
>> (d) It's good. The only reason for absence of String's magic
>> increment is my laziness. I'm happy to add magic decrement
>> feature to the String class, if somebody supplies me the code
>> (acutually you already did).
>
>But please consider, that "a".pred currently results in "". Whereas
>"".succ and "".pred cause errors. I don't know, if that implemented
>behavior is ok, or not. But, nevertheless, please feel free to use it
>:-)))
Again, we should mind that negative options are limited.
>>|Every class which wants to be used as Range, should implement a
>>|"succ", "pred" and a "compare method" to enable us to detect the end
>>|of iteration.
>>
>>is already there, except "pred" and reverse ordering.
>
>No! As I have already mentioned, the current implementation lacks of
>the optional stepsize argument. I think, that is important. Because
>only an instance itself nows, how to return the n'th successor.
>Furthermore it would be more fast than calling the "succ" method n
>times!
Cle, What target do you supporse? Your request sounds too wide.
I understand Range's part is
(1) external iterator
for i in range, range.each
(2) interval to test membership
range === arg
(3) simle way to construct a long series
Cle's range[n]
Your succ seems to be for (3) rather than (1). Of course (3) includes
(1) or (2) but opposite.
By the way, what is a "compare method" else <=>?
>Furthermore I really would not like to restrict it only to numeric
>arguments. Later I will implement a new class perhaps, which usage as
>interval could also make sense. So I would like to let the user
>decide, what class should be used by an Interval. The only
>requirement would be, that this class have to implement a "succ",
>"pred" and "cmp" method!
Well, arguments of Interval are requires only <=> if you adopt
that Interval is a simply connected subset of a totally ordered set.
Some ordered sets are not numeric, e.g., Time.
Generally speaking, Interval can be defined on a Lattice, which is
(L0) reflexive: a == a
(L1) antisymmetric: a == b if a =< b && b =< a
(L2) transitive: a =< c if a =< b && b =< c
(L3) exsitence of meat and join:
for every pair a,b there exsits c, d such that
a =< c && b <= c && d <= a && d <= b
It doesn't require <=>. (L3) implies that two ends uniqly specifies
an Interval.
-- gotoken
# sorry for being rambling and long