AltME groups: search

And if you look in HELP MODULO, it looks like a hack to fix some 
problem:


Wrapper for MOD that handles errors like REMAINDER. Negligible values 
(compared to A and B) are rounded to zero.

I just say Ladislav popping in. Ladislav, if you don't wanna read 
all, my question simple is, if we need all of REMAINDER, MOD and 
MODULO?

Although perhaps it should be. MOD and MODULO were written when ROUND 
was mezzanine. Now that ROUND is native, perhaps MOD and MODULO could 
be optimized by someone who understands the math (not me).

(And maybe you're not the one to answer this question.) :)

When implementing Round as mezzanine, I needed MOD to do it, and 
Gregg thought it might have been useful to make it available;

Remaninder (//) is handling operands as "exact", MOD uses some "rounding", 
MODULO is more "standard" and uses even more rounding

So the difference is only, when the division give a remainder close 
to zero. Example of same results:

>> mod 0.3 0.2
== 0.1
>> remainder 0.3 0.2
== 0.1
>> modulo 0.3 0.2
== 0.1


And then there are some differences, when dealing with negative numbers.

Should there be? And is more optimization possible?

If we get rid of MOD and just go with MODULO, should we rename MODULO 
to MOD ?

My suggestion is to get rid of moth MOD and MODULO, and then deside 
on a way, REMAINDER should work. People can always make some function 
in special cases. And remember rule no. 1!
K.I.S.S.

If functions like MOD and MODULO is needed, then the real problem 
might be with remainder?

I'm studying Lua these days, and they just have one function, that 
do:
a - floor (a / b) * b
Simple to understand.

What would be the consequences of such a change? I remember you going 
on about IEEE754 predictability, and this would seem to reduce precision 
- all that rounding...

I saw that implementation before I read about modulus on wikipedia 
and wolfram.

I would keep MODULO (maybe make it native) and let MOD be defined 
as an operator that redirects to it.

So, Geomol, what is the result of a - floor (a / b) * b, if a = 0.3 
and b = 0.1?

It might be a good idea to split the problem between integer and 
decimal behaviour. In the case of integer, there should be one way 
to do it. Today we have two different outcome:

>> -8 // 3
== -2
>> mod -8 3
== 1

(MODULO give same result as MOD.)

Ladislav, the result is 0.1, and we know why. The programmer should 
know too and find some way to figure out, that 0.1 almost divide 
up in 0.3. One way is to divide 0.3 by 0.1 and see if the result 
is close to an integer.

as I said, I was asked to make MOD available; and to even add the 
MODULO function, since Gregg felt, that they were useful on their 
own. YMMV

Ladislav, I think, you and I agree much about many of these things. 
It's too bad, things get more complicated than necessary, because 
such functions become part of the language.

Brian, what do you mean with proportional coordinates and the use 
of modulus?

Would all those problems be solved, if the decimal! datatype actually 
was the money! datatype, and if we then had a real! datatype, that 
did it a fast way and giving results as we see in C and other languages?

As a practical example, if you are doing device-independent rendering 
you work in proportions (floating point ratios) and then convert 
to exact values (integer coordinates) on final rendering to the real 
device. Video games do this all the time - that is why GPUs need 
floating point hardware. Same with sub-pixel rendering. If you are 
working in proportions, your modulus functions will need to handle 
them. And modulus could be used for bounding box calculations on 
textured surfaces too.


In both those cases, the programmer will probably know enough about 
accumulated error to want to control it themselves. The non-rounding 
behavior of // would be a benefit to them then, so rounding can be 
minimized.

In Python, they call them reals. In Lua, you just have numbers. Integers 
and floats are the same internally as far as I can see.

...but I bet, that I and Geomol would be OK with IEEE-754! or a similarly 
"ugly" name, which may really scare some people

A problem with "float" might be, that many will think 32-bit right 
away. And we have 64 bits to play with.

Geomol, it wouldn't be normal to convert to integers first if you 
are trying to manage rounding and the specific integer values are 
only an end-device approximation of real valued proportions and coordinates. 
In other cases, converting to integers would be appropriate. It varies.

A 64bit float is still a float. There are 128bit IEEE754 floats too 
(and perhaps 256bit, I don't know).

there is a "slight" difference between "real" and "float" - both 
can be used, but "real" is more understandable for a layman than 
"float" - where does it float?

Another thing, we have pi:

>> pi
== 3.14159265358979

Would it be an idea to have e equal to:

>> exp 1
== 2.71828182845905

I mean, we can create pi ourselves with

arccosine/radians -1

, so why is pi there? And if it is, why isn't e there?

When do you use e when not doing exponents? Not familiar with e's 
use - I took calculus in 1987 and haven't used most of it since.

yes, but in the above case both "real" and "float" are actually of 
the "same information value" for an expert - not knowing from the 
name neither how many bits they use, nor what is the base (2 or 10)

We could call integers for Integral, like Python have numbers.Integral
(just kiddin)
I like integer! and real!
(I may change my mind.)

Should the hyperbolic math functions be part of REBOL? Like the C 
functions cosh, sinh, tanh. Many languages have them (I've checked 
Lua, Python and Ruby).

However, if we could summarize 2009, it has been a nice year for 
REBOL. Many things have evolved and I have not seen the development 
blocked for more than a week. I don't know how many people are still 
at RT but I suppose the number is quite low and I think we must congrat 
with Carl.

If we think about the needing for money and time a company and a 
family needs (talking about Carl's Family and RT) I am really suprised 
to see how much work has been spent over REBOL. Sometime I even ask 
myself  how it could be possible ? Has Carl some hidden treasure 
? Has he found a way to split himself so we have 2 Carl and not one 
? :-)

I asked Carl to react on reboltutorial article and to add old R3 
architecture doc I remember from the past. It is on R3 rebol.com 
page now ....

ppl were constantly confusing and merging R3 product with R2 marketing, 
although the model was explained many times ....

Important - Finalizing read and write - http://www.rebol.net/r3blogs/0294.html

... and more importantly it doesn't handle refinements either.


What would you expect num-of-parameters to return for the following 
function:

a: func [b c /d e /f g /local x y z]

Remember that there is nothing special about the /local refinement 
or the words that follow it. All /local is is an option that you 
aren't using, and in that is no different than any other option you 
aren't using. In order to determine the number of args that a function 
takes, you need to specify which options you will be using in the 
call, perhaps by providing a path! instead of a function reference. 
Otherwise, just use WORDS-OF.

John's non-parse version looks to be the fastest on 10,000 iterations 
with :print, :now and :insert :

Jerry's original took 0:00:00.346343

John's version took   0:00:00.06549

Parse version took    0:00:00.129942

CLEAR and REMOVE of none just return none and don't complain. This 
allows chaining without needing conditional code.

To Brian I've read your description between FUNC and FUNCT in DevChat. 
Never seen such summarizing description anywhere, but I think it 
is very usefull not for beginners only but for everybody not so hawkeyed 
as gurus. This should be mentioned in docs, or even better short 
lectures shall be written about such "deep lake" details (to reproduce 
Carls definition)

I think that struct! and routine! are there left-overs from R2, and 
will be removed, as we are not going to get DLL interface, I wonder 
what those two datatypes would be good for. Maybe struct! might be 
usefull, if made more powerfull, dunno. Our interface is now Extensions.

Yes Pekr and when you want to write Extension as generalDLL loader 
can you use a block! paramerer instead of struct, or better how to 
transform a block given as parameter of extension to struct needed 
as parameter of underlaying DLL.

The R2-style struct! and routine! types are not working in R3 and 
are likely to be removed. The struct! type might be replaced with 
a new, improved, incompatible struct! type. The routine! type has 
already been replaced with a new, improved, incompatible command! 
type.

You are right that documentation is an ongoing problem. The design 
has been changing a lot during the alpha phase, but the behavior 
of FUNC and FUNCT are unlikely to change, so they could be documented.

Have you tested with prefix form math? The implementation of op! 
has changed, and the new implementation would probably be slower 
(at a guess) but is more flexible. Please test with prefix math so 
we can categorize the ticket properly.

If functions like ADD and SUBTRACT are slower, this is an issue. 
If it is just ops like + and - then it is a side effect of user-defined 
op!.

I tested under OS X with prefix math, and the same picture is seen. 
If it's because R3 isn't compiled for speed, then that might be the 
answer, so this isn't an issue.

Oh, duh, it's because integers are 64bit in R3, and Windows' 64bit 
integer math emulation is better than Mac's. Fixable :)

AFAIK, that will all be revealed within the host code shake down 
 :-)


devices are defined in the host and will be extensible, eventually. 
 they all use the same low-level/high-level api using fully async 
handlers.

If functions like ADD and SUBTRACT are slower

 - I'm not sure whether you mean are slower under Mac OS X  or slower 
 than + and -. ADD, SUBTRACT etc. are much slower than +.-.

Results on an old 1ghz ThinkPad:

 >> a: 1. b: 2. dt [loop 10000000 [divide multiply add a b a b]]
== 0:00:21.5

>> a: 1. b: 2. dt [loop 10000000 [a + b * a / b]]
== 0:00:17.25

>> a: 1. b: 2. dt [loop 10000000 [divide multiply add a b a b]]
== 0:00:20.625

>> a: 1. b: 2. dt [loop 10000000 [a + b * a / b]]
== 0:00:17

We mean slower on R3 than they are on R2. We need comparisons of 
both inline and prefix forms if we are going to optimize R3.

And we need platform-specific data too. It doesn't make sense to 
compare Windows and OSX, but it does make sense to compare R2 and 
R3 with each other on the same computer and OS. For that matter, 
there may be OSX version issues too.

From my perspective, DO is faster than before because of reduced 
complexity, and user-defined ops are possible now because they handle 
their own redirection instead  of DO special-casing it. An acceptable 
tradeoff.

It's a big picture balance thing. The optimizations were rebalanced 
in the change from R2 to R3 in order to increase overall power and 
speed of REBOL. REBOL has never been a math engine (not its focus), 
but now it can be because of extensions. Everything is a tradeoff.

notice I said "unfortunate" and not "unnacceptable"   ;-P

as you say, given the choice between how its in R3 and R2... "I would 
do it all again"  ;-)

Yes, but you said VERY, and that is what I was disputing. Only the 
ratio has changed. Overall performance has improved, which in many 
cases makes up for the increased overhead of Unicode and 64bit integers, 
among other things.

a nice parallel to R3 is python 3... just about every issue we have 
is also an issue in  P3 (unicode, R2 forward for example :-)... it 
took 3 years to build, and remember that python has NO graphics, 
only core release.   Also P3 has much less fundamental changes than 
R3 has, so in comparison, R3's implementation is at par with other 
interpreter updates.... except they are whole teams, where R3 is 
a very small team.


http://broadcast.oreilly.com/2009/01/the-evolution-of-python-3.html


P3 did require updating MANY modules, so most of the team probably 
worked on that instead of the language itself.

Yery little work was done on the language itself, mostly on libraries. 
Within its limits Python 2 was good enough for Python devs, at least 
syntactically. All they had to change was libraries and some internals. 
Still significant, but not on the scale of the R3 changes.

yep... and it took 3 years  ;-)

Most languages are going through the revamp nowadays, due to the 
Unicode and concurrency crisis, and the extent of the changes attempted 
varies from language to language.


Python 3 is on the more minimal end of the spectrum: Only Unicode 
changes, not paying attention to concurrency at all, focus on backwards 
compatibiity, no significant syntaxtic changes (the standards for 
syntax among Python devs is low), minor cleanups to its libraries. 
And it took them 3 years to do it :(


Perl 6 is on the more extreme end of the spectrum: Major changes 
in everything, including syntax, several complete system structure 
revamps going on at once, major semantics changes (not sure about 
the concurrency). Perl had an entire history of not being designed 
at all, so they had a lot of crap to get rid of. Which they replaced 
with much more new stuff (Perl doesn't know how to say No). 10+ years 
into the project, with no end in sight.


R3 started closer to the minimal end of the spectrum because we hadn't 
really been keeping track of how far behind we had gotten - not far 
behind the others, far behind our potential. As the scope of the 
changes needed became more apparent, the project rapidly went way 
towards the Perl 6 end of the spectrum. However, we had to do a couple 
restarts along the way. The current round has only been going for 
2 years, but gone way past the level of changes in Python 3, and 
has approached the level of change in Perl 6.

We had some advantages though:

- REBOL has been more designed than those others, over the years. 
That means that we are redesigining rather than designing.

- R3's primary designer is mainly into operating systems, so R3 is 
built like an OS, which makes more ambitious changes possible.

- We decided that R2 will be continue to be maintained as a separate 
project, so we don't need to stay backwards compatible.

- REBOL's design process knows how to say No, so we aren't falling 
into the Perl 6 trap.


All of these are why we have been able to accomplish so much in such 
a short time, with so little resources. It's taking a lot of time 
and effort to get the community to realize that R3 is a community 
project, so we've had to make the best use of the resources available, 
even when it meant taking some time off from developing to build 
the infrastruuctre for community development. This process work has 
paid off dramatically, so much so that comparing pace of development 
more than a year ago to that nowadays is completely irrelevant :)

and when Carl gives us the host he says now compiles again, comparing 
the next 12 month's R3 development will make the entire 10 years 
of REBOL development seem irrelevant.

Not everyone realizes that Carl has spent a long time building a 
very strong lever.... might not be pretty... but its damn straight 
;-)


now he's about to give us a chance at holding that lever as a group 
and leverage all the work.  He's been putting all the effort to putting 
the pivot of the lever (the fulcrum) as close to one end as possible... 
so R3 will be very strong and allow to do much more heavy lifting 
than R2 ever could.


now we just have to paint the lever and make it all shiny (gui) put 
a nice handle on it (the host) and even add a few more handles to 
it (threads).


most of that... we can do as as group with a few helping hands working 
together  :-)

Being able to say No was a really big deal. It is why we had to build 
our own VCS and developer communications infrastructure, with moderation 
and ranking built in. We didn't have the benefit of years or decades 
of established community development, like Perl or Python - we had 
to do this from scratch. The only way we have been able to make such 
ambitious changes so quickly and cleanly is through some group discipline 
and politeness, and that means we need to have a counter-pressure 
against flame wars and development fights. We would have never managed 
to get this far without DevBase (R3 chat) and CureCode :)

Back to ROUND for a moment. It seems so long ago...


I think the goal was to have things make sense to normal people, 
while still allowing Ladislav and John to have their way. :-) Most 
programmers just want results that make sense to them as humans.

I could of course use == instead of =, and then none of the above 
tests would be true. The reason I find the behaviour strange might 
be the way, PRINT output the numbers.

I probably read it and forgot. I'll read it again. :-)

nearness

 is not equality, it is just symmetric and reflexive (no transitivity)

I'm actually messing around with REBOL (actually R2) and been away 
from it so long I forgot a lot of stuff.  Anyway, was wondering how 
R3 is progressing.  I was just using parse and thought about rejoin. 
 For example, if we can parse something such as:

blk: parse "this, simple, csv, string" "," 


wouldn't it be cool to just come back along and rebuild it with something 
such as:

rejoin/csv blk ","

If you change it, then you'll have problem with < > and ==, because 
you can have situations, where all those 3 return false.

Then you can add strict-lesser? and strict-greater?, but I wouldn't 
recommend it. :-)

Is this is a bug? - url::%23 and url::# are not the same:

	>> url::%23
	== url::#

I've been looking over R3's url handling and decoding and it needs 
more work, some of which needs to be in the native syntax.

Chris, url::%23 and url::# should not be the same. The purpose of 
percent encoding is to allow you to specify character values without 
them being treated as syntax. If you specify a # directly in an http 
url, for instance, it should be taken as the start of the anchor 
portion of the url. If you percent encode it, it shouldn't be an 
anchor.

Chris: I have pointed out this flaw to Carl before R3 was started, 
and provided the correct code to handle URI according to the standards...

Gabriele, be sure to post the correct url parsing code here or in 
R3 chat. We will be sure to get it integrated into R3. Or you could 
integrate it yourself if you like. If there need to be specific changes 
to the url syntax as accepted by TRANSCODE, please note them here 
or in CureCode. Proper url handling is important, and now is the 
time to fix it.

I have been thinking that urls should stay percent-encoded until 
they are decoded by DECODE-URL, so that percent-encoded characters 
won't be mistaken for syntax characters. (I don't claim this is my 
idea - I think you said it earlier, and I remember that.)


Is this approach a good one? Have you thought of any gotchas or downsides 
to this? Will this require that urls have an associated decoded version 
that would be stored as well as the character version? Do you think 
we could get away with TRANSCODE enforcing the initial rules, then 
not checking again until it comes time for DECODE-URL to be called 
(on OPEN, for instance)?

The main gotcha so far to the keep-encoded approach is whether INSERT 
and APPEND should do some magic percent encoding or not. It seems 
that it may be a better approach to just assume that the programmer 
knows what they are doing and just insert what they say to insert 
as is, as long as the url character set restrictions are met. This 
would mean that the programmer would need to handle their own percent 
encoding where needed, and that INSERT or APPEND would not do any 
encoding or decoding. Or perhaps some non-syntax characters, such 
as space, could be encoded by MOLD instead of rejected and DECODE-URL 
just adjusted to not freak out when it seees them. What do you think?

it just makes everything totally confused and leads to very hard 
to fix bugs.

and breaks inter type linearity... if source is one type... something 
happens, when source is another type, something else happens... aaaarrrrggghhh 
 :-(

for urls, I'll let you guys assess it... I'm the kind of guy that 
will do all with the string and just convert it to url at the end, 
 its just much more useable that way... you have a better control 
over stuff like "/" in the path anyways.

I think I'd look for at least the following behaviour:

	>> url::%23#
	== url::%23#
	>> join url:: "%23#"
	== url::%23#

 >> join url:: " " ; space is not in the uri spec, so could arguably 
 be converted
	== url:: 
	>> read url::%23# ; dependent on the scheme, I guess
	== "GET %23"


The problem with magic percent encoding is with the special characters. 
 As it is now, it is impossible (so far as I can ascertain) to build 
an http url that encodes special characters eg "#=&%" - Twitter being 
a great case where an encoded # is integral to the service.  Given 
though that the list of special characters is short and well defined, 
perhaps they could be the exception to a magic encoding rule.

Brian... in how many places do I have to post it? Will a new place 
come out next here, and you'll tell me to make sure it's posted there?

We have to do percent decoding to read urls. The question is when.

 - The standard TELLS you when... my document too... but since everything 
 moves every few months, things get lost and forgotten. (besides, 
 it could have been fixed back then, so there would be no need to 
 worry about it now...)

There is CC for tickets, and there might be DocBase articles. One 
user "volunteered", reorganised it, and it got totally messy :-)

what moves?


If you think, you might be able to figure out, which moves Gabriele 
talk about. (And you don't have to answer or comment this. Less noise 
and more thinking would be good for a change.)

Geomol - my question was rhetorical. I think I do understand what 
Gabriele means, I just don't agree with the outcome. There are clear 
places where to post, easy as that. It is a bit difficult sometimes 
to get Carl's attention, but 80 tickets a month get such an attention. 
The development process of R3 might look chaotic, jumping from one 
area to the other, but if we want, and we care, we know how to get 
such an attention. 


I for one asked Carl privately about your concern towards R3 speed 
in certain situations. And you know what? I got some answer too. 
I asked Carl to comment to your ticket, he did so. In few hours. 
You could do just the same, no? It is very easy to become a naysayer, 
to express some worries, etc., but other thing is to actaully act, 
not just talk, and then your saying applies - "less noise and more 
thinking (and acting) would be good for a change" :-)


.... and please - I think I don't need any guides on what should 
I comment, or not. But the fact is, that I don't want to let anyone 
to dismiss the hard work which is being put into R3. I don't care 
about myself at all, but I see it at least as dishonest to those, 
who really try to bring R3 out, and we have few such friends here 
...

BrianH: 'call in R3 is more low level, right? I would like to do 
following thing - I want to have few powerpoint presentations running 
in a loop. In R2, I could use call/wait, and once the presentation 
is finished, the console returned. In R3, there are no refinemenst 
as /wait, /output.


Is there any equivalence? Was R2 using "start" command in windows? 
I tried with "start", but got following error:

>> call "start /WAIT powerpnt /S test.ppt"

** Access error: external process failed: "Systém nemùže nalézt uvedený 
soubor.^
M^/"
** Where: call
** Near: call "start /WAIT powerpnt /S test.ppt"

I plan to use R3. I defined what makes R3 beta a good release, and 
adressing 'call is one of those points. CGI/IO was already adressed.

Pekr, I did this interface some time ago. It is based on a previous 
implementation from J.F. Theis, and is implemented as a TCP-IP server. 
I will certainely make out of it an extension for R3, but it can 
be already be used either with R2 or R3 as soon as you are able to 
send TCP-IP commands. See http://colineau.societeg.com/rebol/r2win151.html
. Unfortunately, it seems that the host site is down right now. If 
the shutdown persists, I will put it  in some other place.

As for where things go, we built places for such things (as mentioned 
above) and they haven't moved in a year.

Today I have seen a Wii GUI in action. It has been designed to be 
used with a remote controller.
Also XBOX 360 and PS3 have been.

Interactive Boxes like Digital TV receiver, Mediacenters are designe 
to be used with a remote.

We are entering in an era where mouse and keyboard are no more the 
standard input methods.

To the designers of REBOL3 GUI please consider the new paradigms 
and provide different interaction methods:
- GUI to be used with REMOTE controllers and similar devices

- GUI to be used with the click of the mouse an keyboards and even 
pedals.

- GUI to be used with multi-gesture multipoint touches (either on 
big and small screens)

Animated transitions and some 3D are necessary for a modern GUI system.


GUIs are the basic instruments users interact s with our applications. 
If we give the feeling of a modern GUI 50% of our work has been done 
because they will feel the program to be modern and good, even if 
it isn't. really so.


Our customers are people: specialist and families like the one I 
have encountered this evening. They use Modern Touch based Cell Phones, 
MediaCenters, Remote Controllers and at the and Mouse and Keyboards.

Hope my observations helps.

I tested this:
dt [a: 1. b: 2. loop 10000000 [a + b * a / b]]
and this:
do http://www.fys.ku.dk/~niclasen/rebol/r3/mandelbrot.r

I get with R3 lower performance with Processor, Memory and Disk/File, 
just the value for Console is almost 500% increased