World: r3wp

As for me, current situation means just one thing. As a customer/developer, 
looking at feature sheet for R3, searching for the SSL and HTTPS, 
all I can see is big NO.

the feature is so fundamental, like Unicode is. That is why it should 
be delivered by default, with no excuses. There is no web without 
https nowadays ...

That's funny, I see the same thing when I look for the "not an alpha" 
feature :(

If we did not get single networking protocol in 3 years, no single 
fix to http protocol (and we are talking mezzanine level here), WHEN 
do you expect, that feature like SSL/TLS, https could appear for 
R3? That is my only worry here. I am not agains the delivery by some 
"third party", I am just worried judging by recent experience ...

Not looking recently enough. However, your approach is counterproductive 
here. Asking for "RT" to provide this feature is not appropriate 
for a community project. What you should be asking for is contributions. 
RT's time is finite, and we have to triage features based on their 
feasibility, not just how "important" they are. The increasing proportion 
of R3 that is or will be open source is a testament to that. Every 
part of R3 that is open source is *our* responsibility, not just 
RT's.

People can say that a feature is important, but in a community project, 
in the community-created portion of that project, the way you express 
the importance of a feature is with time, effort, or the money to 
buy time and effort. As you have done with HTTP. If the community 
thinks that SSL in an important feature to have, then get to work. 
Complaining only has limited usefulness.

Is there a bounty on native SSL ?

not yet. We need bounties imo ...

I should note... HTTP stalled because I never got answers by Carl... 
about how to implement timeouts (has support for timeouts been added 
to ports in the meantime?), how to handle errors (i think i have 
a decent implementation, so maybe this is ok), what the semantic 
of QUERY should be, and so on. there are a ton of little details 
about port schemes that have not been DESIGNED yet...

(same thing that happened with R/S... priorities switched)

hmm, interesting ...

I thought that networking device is finished ...

More importantly are there people who can do the work if bounties 
are set?

Bounties may not be a bad idea, but you have to get the right people 
to do the work.

yes, I think that bounties of type - pick your bounty - would not 
work here.

If we don't try, we won't know

e.g. networking protocols - those could be done imo only by Gabriele, 
or BrianH ... (hope I don't offend others). Carl might be picky, 
what code gets in. It definitely can't be done by me for example 
:-)

I like http://bounties.morphzone.org/, because you can see, who 
contributed. The trouble might be - does any such system allows cancellation 
ob bounty, their merge, etc? What happens to money, if bounty's goal 
is not fulfilled?

that's an odd money distribution. the most important thing is site 
maintenance? :-)

I looked a bit more on MOD, MODULO, REMAINDER and //. Isn't there 
too many of those functions? I found, MOD is giving some strange 
results:

>> mod -8. -3.
== -5.0

It makes sense to me to either just use the C ways of doing modulus, 
if it's fast:

% for integer! and
fmod () for decimal!


or do it in a more correct way mathematically, maybe (pseudocode):

result of a // b = a - floor (a, b) * b

See: http://en.wikipedia.org/wiki/Modular_arithmetic#Functional_representation_of_the_remainder
and: http://functions.wolfram.com/IntegerFunctions/Mod/02/

I searched the scripts in the library at rebol.org, and only a handful 
(which is very few) use MOD. A script or two even make their own 
version of MOD to give correct output.

AFAIK MOD and // are not the same.

I think, you are right. It seems, REMAINDER should do the same as 
//. My question is, if we need 3 different modulus functions? Today 
we have REMAINDER, MOD and MODULO, and at least MOD is giving some 
strange results in some cases. I would guess, having one function 
and one operator should be enough.

Ask yourself, if you were going to use a modulus function, which 
one would you use? And why?

I suppose it depends on the situation. I guess there would be three 
different versions, because Carl saw a need for them all. I discovered 
the difference when I used MOD in a situation where // worked as 
it should.

I tried mod 3.3 1.1 - it reutrns a negtative number - I have reported 
this in CureCode

There are related bugs, it seems. This should return a value close 
to zero:

>> 3.3 - ((round/floor 3.3 / 1.1) * 1.1)
== 1.1


It's not good, that there still are bugs on such a basic level. (Often 
when I dig into these things, I say to myself, that I should shut 
up and wait for a release.)

Right now, all op! functions redirect to corresponding action! functions. 
// redirects to REMAINDER, which is why we need it.

When you run into major errors like PeterWood's above, report them. 
Since MOD and MODULO are mezzanine, they can be fixed right away 
by someone with the right math knowledge. Ladislav?

I'm not questioning, that we need a modulus function (REMAINDER). 
I'm questioning, if we really need 3 of them. If REMAINDER doesn't 
do, what it's supposed to, then I would fix that instead of adding 
2 new functions.

Brian, no they can't be fixed right away. See my example with round/floor 
above. That's the way to calculate a modulus, and it doesn't work. 
:)

From what I can tell from the code though, modulus and remainder 
aren't exactly the same concepts. But, I don't have that math knowledge. 
The mezzanines claim to do extra error checking, but I don't know 
what part of their code does that.

If there is an error, and the math within the functions makes sense, 
then there is an error in the underlying operators somewhere that 
needs to be tracked down. Ladislav? :)

From your code, it looks like this is the problem:
>> round/floor 3.3 / 1.1
== 2.0
>> 3.3 / 1.1
== 3.0


1.1 and 3.3 aren't exactly representable in IEEE754 encoding, so 
the 3.0 value you see is actually a little less than 3.0.

Brian, when I try round/floor 3.3 / 1.1 it returns 1.1 (2.100.94.3.1 
on XP)

If you want exact decimal math, you have to switch to a different 
underlying representation, such as that used by money!:
>> round/floor $3.3 / $1.1
== $3
>> $3.3 / $1.1
== $3.0000000000000000000000000

I think, I see, what happening now. If 3.3 / 1.1 is just below 3.0, 
then the round/floor will return 2.0, which is ok. So my example 
might not be a real problem after all, unless it give different results 
on different platforms.

Bolek, are you sure you put in /, instead of //? Cause that sounds 
extra weird, since I am also testing on XP.

Ah, my stupid fault  :)
>> round/floor 3.3 1.1
== 1.1
:)

Hm, the round/floor way probably shouldn't be used, when dealing 
with decimals. It should then just use the C function, fmod ().

Geomol, that inaccuracy is built into the standard, and floating 
point hardware tends to follow that standard. It's a side effect 
of the fact that IEEE754 floating point numbers are internally base 
2, and in base 2 the decimal value 0.1 is an infinite number just 
like 1/3 is in base 10.

And if you look at the source of MOD and MODULUS, neither of them 
uses round/floor :)

Sorry, MODULO, not MODULUS :)

Brian, I know about IEEE754! :)

I wrote much of the documentation about it.

I just tested, the C function, fmod (3.3, 1.1), also returns 1.1. 
:)

I figured so, since if I knew about it it must be pretty basic :)

I think that the difference between // and MOD is in how they handle 
negative numbers. Modulus (as a math concept, as I recall) isn't 
defined for negative numbers at all. Programming languages tend to 
punt when it comes to this, so // works the most common way, and 
MOD converts it to the next most common way.