[REBOL] tuple math Re:
n on. no wrap or carry? My gut tells me it is wrong to have to check my results after every addition. so here is what I am looking for: - an example of a use for the current behavior which warrants adding math checks to all other uses. I reported this as a bug in one of the early versions of Rebol. The response I got was that this is the intended way that tuples work, and mainly for use with RGB values, so that you don't got from full colour to no colour when dealing with RGB. In my opinion this is totally wrong and should be scrapped. If such a functon was needed then it should have it's own datatype, How about errr... RGB ! Tuples should obey the 'rules' of maths, not some screwball idea for rgb. The chances of getting this fixed are pretty slim, there are still fundemental ares not fixed from early versions, ftp and basic serial I/O to name but two. Andy
[REBOL] tuple math Re:(2)
[EMAIL PROTECTED] wrote: n on. no wrap or carry? My gut tells me it is wrong to have to check my results after every addition. Yes. because of this check no carry for RGB and version numbers ! rebol-tuples are good for this things, multiple values handled together with different meanings. if i define my version-numbers as release.change.platform.saves i'm pretty happy with 255, instead of an incremented platform. same to colors. For what application could a carry or wrap be usefull? there may be solutions using binary with some helper-functions? or integers with a bit shifting. so here is what I am looking for: - an example of a use for the current behavior which warrants adding math checks to all other uses. I reported this as a bug in one of the early versions of Rebol. The response I got was that this is the intended way that tuples work, and mainly for use with RGB values, so that you don't got from full colour to no colour when dealing with RGB. ... Andy Volker
[REBOL] tuple math Re:
Hi Bob, since make tuple! [1] generates 1.0.0, I think that a good way of handling it would be to change the highest order. make tuple! "1" == 1.0.0 make tuple! [1] == 1.0.0 Elan At 03:38 AM 5/8/00 +, you wrote: REBOL 2.2.0.4.2 ... a: 192.9.200.211 == 192.9.200.211 a + 1 == 193.10.201.212 what justification is there to changing -all- the integer fields? I expected at most to change either the highest order or the lowest order integer field by this operation - not all of them. a: 192.9.255.1 == 192.9.255.1 a + 1 == 193.10.255.2 a + 0.0.1.0 == 192.9.255.1 humm, neither of these does what I expected. What I was looking for was some form of carry propagation. Now there are 2 contexts that I consider using tuples for: IP addrs and version numbers. I would welcome the list to show some alternate uses for them. [big math like bigint seems out -- too bad] As internet addresses, I can reasonably stay away from adding + 1 and instead use 0.0.0.1 to get the next higher IP addr to try. The lack of carry is probably not going to be discovered by other programmers using them for IP because 255 becomes a broadcast address in most systems so logic is likely in place [I hope others remember to look...] before this value is taken on. no wrap or carry? My gut tells me it is wrong to have to check my results after every addition. so here is what I am looking for: - an example of a use for the current behavior which warrants adding math checks to all other uses. ;# mailto: [EMAIL PROTECTED] ;- Elan [: - )]
