Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

Millennium + 1 ...

 [1/20] from: g::santilli::tiscalinet::it at: 4-Jan-2001 19:41


Hello Ladislav! On 03-Gen-01, you wrote: LM> In a different wording: if I LM> don't have zero, I can't get a negative number. This is a good point. We should let Carl know about this problem... i: 1 pick series i pick series i + 1 pick series i - 1 ; ??? Regards, Gabriele. -- Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/

 [2/20] from: lmecir:mbox:vol:cz at: 4-Jan-2001 21:06


To be more constructive, I can imagine a strategy: pick series 1 pick/back series 1

 [3/20] from: doug:vos:eds at: 4-Jan-2001 15:10


Does this have anything to do with the probe info? ftp://user:[pass--server--my--com]/file.txt 2001 problem I am having?

 [4/20] from: rebol:techscribe at: 4-Jan-2001 14:27


Hi Gabriele, however, the way it is implemented is more consistent for a different reason.
>> a: [1 2 3 4] ;- (1) >> pick a 0
== none
>> insert a [-4 -3 -2 -1] >> a: skip a 4 >> a
== [1 2 3 4]
>> pick a 0 ;- (2)
== none (1) and (2) should be equivalent and they currently are. If you were to introduce 0 as the position that precedes the current position of the block, then (1) and (2) would not be equivalent and that would be confusing. Using whole numbers instead of natural numbers for indexing a block would be less user-friendly, because for the second element to be located at index 1 (etc.) is counter-intuitive. Looks to me like the current solution is the best compromise. At the cost of getting a none value at location 0, you avoid zero-indexed blocks (not user friendly), and you avoid inconsistent behavior that depends on whether or not the current block's position happens to be the head of the block. Gabriele Santilli wrote:

 [5/20] from: carl:cybercraft at: 3-Jan-2001 19:01


>> 2-Jan-0001 - 1
== 1-Jan-0001
>> 1-Jan-0001 - 1
== 31-Dec-0000 So, those who claim 2001 as the start of the new millinnium are wrong, as there was a year 0. At least according to REBOL... (: -- Carl Read [carl--cybercraft--co--nz]

 [6/20] from: rryost:home at: 3-Jan-2001 0:05


But here's a console session: REBOL/core (Experimental) 2.4.39.3.1 Copyright 1997-2000 REBOL Technologies REBOL is a Trademark of REBOL Technologies All rights reserved. Component: "Internet Protocols" (17-Nov-2000/0:30:07) Finger protocol loaded Whois protocol loaded Daytime protocol loaded SMTP protocol loaded POP protocol loaded HTTP protocol loaded FTP protocol loaded NNTP protocol loaded Script: "User Preferences" (1-Jun-2000/11:36:20-7:00)
>> now
== 3-Jan-2001/0:00:52-7:00
>> subtract now 1
== 2-Jan-2001/0:01:07-7:00
>> subtract now 3
== 31-Dec-2000/0:01:21-7:00
>> >> now - 3
== 31-Dec-2000/0:03:27-7:00
>>
I can't complain too much! Russell [rryost--home--com]

 [7/20] from: lmecir:mbox:vol:cz at: 3-Jan-2001 17:17


The Millenium and the Rebol Counting Error. There was a dispute when the Second Millenium of our Julian/Gregorian calendar shall be celebrated. The Millenium in this case shall mean the day, that is two thousand years after the starting day of the calendar. The calendar documentation is stating, that the starting day has been assigned the date 1/1/1 A.D. According to that, the Second Millenium day shall have the date 1/1/2001 A.D. The architect of the Julian calendar used the date 1/1/1 A.D. as the starting date of the calendar. What did the calendar architect do, when he wanted to refer back in time? He used another calendar called the B.C. calendar, that counted the years backwards. The first year of the B.C. calendar was the year immediately preceding the first year of the A.D. calendar. We, knowing zero and the negative numbers, can use A.D. calendar even for the B.C. calendar dates. A conversion table: YEAR CONVERTED TO A.D. ****************************************** 4 A.D. 4 3 A.D. 3 2 A.D. 2 1 A.D. 1 1 B.C. 0 2 B.C. -1 3 B.C. -2 4 B.C. -3
>From the fact, that in Rebol
(1/1/0001 - 1) ; == 31/12/0000 we can observe, that Rebol doesn't use the B.C. calendar, but it rather uses the A.D. calendar even for the days before the start of our calendar. This is simpler and more practical, than the ancient "calendar switching". Now about the Rebol Counting Error. Example: series1: skip [-2 -1 0 1 2] 3; == [1 2] Now we can ask what does the first place of our series contain. The answer is, that the first place of our SERIES1 contains the number 1: pick series1 1 What does the second place of our SERIES1 contain? It contains the number 2: pick series1 2 What does the place 1 B.S. i.e. the first place before the start of the SERIES1 contain? It contains the number 0. This place should be the place number 0 S. (i.e. the place number zero in the SERIES1), as everybody able to count backwards from 1 can find out. The problem is, that the Rebol designer is currently trying to convince us, that it is the place -1 S., as can be seen from: help pick pick series1 0 ; == none pick series1 -1 ; == 0 What do other Rebols think?
> >> 2-Jan-0001 - 1
== 1-Jan-0001
>> 1-Jan-0001 - 1
== 31-Dec-0000 So,
> those who claim 2001 as the start of the new millinnium are wrong,
as
> there was a year 0. At least according to REBOL... (:
-- Carl Read
> [carl--cybercraft--co--nz]
-- To unsubscribe from this list, please send
> an email to
[rebol-request--rebol--com] with "unsubscribe" in the subject,

 [8/20] from: g:santilli:tiscalinet:it at: 3-Jan-2001 20:03


Hello [lmecir--mbox--vol--cz]! On 03-Gen-01, you wrote: l> pick series1 0 ; == none l> pick series1 -1 ; == 0 l> What do other Rebols think? It is not that easy to give an answer IMHO. It is reasonable to associate "first to the right" with 1 and "first to the left" with -1, as mush as it is to place the numbers on an axis and refer to the position 1, 0 or -1. It is a matter of conventions after all... I think Carl made this decision (as opposed to any other language, I think) because humans tend to think of positions as "the first", the second , "the first going back", etc. rather than "pos. 1", pos 2 , "pos 0" etc. Regards, Gabriele. -- Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/

 [9/20] from: lmecir:mbox:vol:cz at: 3-Jan-2001 21:11


I do agree, that the majority of people (even me e.g.) like to say "first to the left" or "first to the right". Schematically spoken, 1 A.D. 1 B.C. My problem with the counting is, that: 1 A.D. - 1 B.C. = 1, not 2, as the scheme 1 - -1 is trying to convince me. In a different wording: if I don't have zero, I can't get a negative number.

 [10/20] from: lmecir:mbox:vol:cz at: 5-Jan-2001 20:06


My point of view written in Rebol: pick-prop: function [ {Returns the value at the specified place in a series.} [catch throw] series [series!] index [integer!] /back {pick backwards} /or handler [block!] {exception handler} ] [to-skip skipped] [ to-skip: either back [- index] [index - 1] either any [ tail? skipped: skip :series to-skip all [ head? :skipped head? skip :series to-skip + 1 ] ] [ either or [do handler] [ throw make error! {Cannot pick} ] ] [first :skipped] ] A user can choose, if she wants to use the zero-less method of picking like: series: skip [-2 -1 1 2] 2 ; == [1 2] pick-prop :series 1 ; == 1 pick-prop/back :series 1 ; == -1 or use zero and negative numbers. In this case the expressions: pick :series n pick/back :series n are equivalent to pick/back :series 1 - n pick :series 1 - n Regards Ladislav

 [11/20] from: g:santilli:tiscalinet:it at: 5-Jan-2001 19:19


Hello Elan! On 05-Gen-01, you wrote: E> however, the way it is implemented is more consistent for a E> different reason. I'm not sure about this. The current implementation is probably closer to the human way of thinking, but it can introduce subtle problems. I'm not saying this is an important problem, and the way it is worked for me since REBOL was released. E>>> a: [1 2 3 4] ;- (1) E>>> pick a 0 E> == none E>>> insert a [-4 -3 -2 -1] E>>> a: skip a 4 E>>> a E> == [1 2 3 4] E>>> pick a 0 ;- (2) E> == none The two give different results anyway if you use an index lesser than zero:
>> a: [1 2 3 4]
== [1 2 3 4]
>> pick a -1
== none
>> a: insert a [-4 -3 -2 -1]
== [1 2 3 4]
>> pick a -1
== -1 E> (1) and (2) should be equivalent and they currently are. I'd prefer:
>> a: [1 2 3 4]
== [1 2 3 4]
>> pick a 0
== none
>> a: insert a [-3 -2 -1 0]
== [1 2 3 4]
>> pick a 0
== 0 E> you were to introduce 0 as the position that precedes the E> current position of the block, then (1) and (2) would not be E> equivalent and that would be confusing. I don't agree here. You get NONE if the position 0 does not exist. With the current implementation it just never exists... E> Using whole numbers instead of natural numbers for indexing a E> block would be less user-friendly, because for the second E> element to be located at index 1 (etc.) is counter-intuitive. I wouldn't want that to happen. I like the way it is now, but not taking 0 into account COULD introduce problems. It never did for me, tough, and I agree that -1 is a more natural way to get the position before the current one. Regards, Gabriele. -- Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/

 [12/20] from: g:santilli:tiscalinet:it at: 5-Jan-2001 19:04


Hello Ladislav! On 04-Gen-01, you wrote: LM> To be more constructive, I can imagine a strategy: Yet, I think there would be a problem; imagine this scenario: f: func [ "Does something" series [series!] i [integer!] ; ... /local element ] [ ; We do something here element: pick series i - 1 ; we do something with ELEMENT ] After debugging your function seems to work. You are confident in it, but then, one day, something like this happens: f skip [1 2 3 4 5] 2 1 and you get unexpected results. (Well, all this is probably quite unlikely, but it might be the source of one of those subtle bugs which make programmers go crazy.) Regards, Gabriele. -- Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/

 [13/20] from: g:santilli:tiscalinet:it at: 5-Jan-2001 19:07


Hello Doug! On 04-Gen-01, you wrote: VD> Does this have anything to do with the VD> probe info? ftp://user:[pass--server--my--com]/file.txt VD> 2001 problem I am having? That is more likely a bug in the code that parses the directory listing from the ftp server. Regards, Gabriele. -- Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/

 [14/20] from: g:santilli:tiscalinet:it at: 6-Jan-2001 20:15


Hello Elan! On 06-Gen-01, you wrote: E> Hope this makes it a little clearer, Maybe Ladislav's PICK is a good compromise? What bothers me is this:
>> blk: skip [-2 -1 0 1 2 3] 3
== [1 2 3]
>> for i -3 3 1 [print pick blk i]
-2 -1 0 none 1 2 3 Anyway, this is just a little price to pay... Regards, Gabriele. -- Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/

 [15/20] from: al:bri:xtra at: 7-Jan-2001 9:33


Instead of using blocks for this discussion, like:
> >> blk: skip [-2 -1 0 1 2 3] 3 > == [1 2 3]
I think we should now substitute strings, like:
>> str: skip "yz$abc" 3
== "abc" Now, does what we are writing about still make sense? Andrew Martin ICQ: 26227169 http://members.nbci.com/AndrewMartin/

 [16/20] from: lmecir:mbox:vol:cz at: 7-Jan-2001 6:46


Hi, Rebols. On the symmetry notion. My point of view is, that the series: -1 0 1 2 3 4 5 is symmetric. The symmetry I see is, that for any number in the series the distance of all of its neighbours to it is equal to one. If I compare the series with another one: -2 -1 1 2 3 4 5 I see, that the above mentioned symmetry is broken. Regards Ladislav

 [17/20] from: meekerdb:rain at: 6-Jan-2001 22:14


My $0.02 is with Ladislav. Brent Meeker On 06-Jan-01, Ladislav Mecir wrote:

 [18/20] from: rebol:techscribe at: 5-Jan-2001 14:55


Hi Gabriele, 0 is the privileged neutral position of the counter, where left and right meet. Everything in a block is either to the left or to the right of the counter. Because there can be no element located at the privileged counter position, therefore pick block 0 always returns none. If you change that you create a mess. You create the exact same mess, whether you introduce 0 as the first index to the right or to the left. Case 1) The current situation: + == to the right - == to the left 1 == first 2 == second 3 == third 4 == fourth +1 first index to the right -1 first index to the left +2 second index to the right -2 second index to the left +3 third index to the right -3 third index to the left +4 fourth index to the right -4 fourth index to the left and so on Case 2) Introduce 0 in either direction, and you lose the simplicity of the scheme, it becomes counter-intuitive: Case 2a) 0 as first index of block 0 == first 1 == second 2 == third 0 first index to the right -1 first index to the left +1 second index to the right -2 second index to the left +2 third index to the right -3 third index to the left +3 fourth index to the right -4 fourth index to the left You see it becomes confusing in two respects: second maps to 1, third maps to two, and what is two steps away to my right is +1, whereas what is also two steps but to my left -2 not -1, i.e. chaos. Case 2b) 0 as first index preceding the first element of the block (the first negative index, i.e. to the left) +1 first index to the right 0 first index to the left +2 second index to the right -1 second index to the left +3 third index to the right -2 third index to the left +4 fourth index to the right -3 fourth index to the left What did you win versus case 2a)? It's the same mess in reverse. This time the counter-intuitive stuff is happening on the left, in the negative area. But you are still mapping second to 1, and third to 2, and you what on the right is +2 on the left is now -1. You lose the symmetry. Hope this makes it a little clearer, Elan

 [19/20] from: lmecir:mbox:vol:cz at: 6-Jan-2001 3:01


Hi, Gabriele wrote:
> Yet, I think there would be a problem; imagine this scenario: > f: func [
<<quoted lines omitted: 18>>
> Gabriele. > --
I am not sure, I understood you... Could you please compare with the SKIP-PROP implementaion I sent in? Regards Ladislav

 [20/20] from: g:santilli:tiscalinet:it at: 6-Jan-2001 20:14


Hello Ladislav! On 06-Gen-01, you wrote: LM> I am not sure, I understood you... Could you please compare LM> with the SKIP-PROP implementaion I sent in? I think your implementation is a good compromise. Regards, Gabriele. -- Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted