derick Sun Dec 16 05:59:20 2001 EDT
Modified files:
/php4/ext/standard math.c
Log:
- Fix for bug #14544, bogus warning in pow()
Excuse me for disturbing, but it's actually wrong now. You cannot take the
logarithm of zero. As a consequence, in exponential ways of doing pow()
(i.e.
that.
--Jeroen
Jeroen van Wolffelaar
[EMAIL PROTECTED]
http://jeroen.A-Eskwadraat.nl
Index: bz2.c
===
RCS file: /repository/php4/ext/bz2/bz2.c,v
retrieving revision 1.29
diff -u -r1.29 bz2.c
--- bz2.c 1 Nov 2001 09:45:25
Rasmus Lerdorf [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
The pow() regression test is failing due to this strange characteristic:
(...)
}
ie. pow(2147483647,1) returns a float where one would expect it to return
an int. Off by one error somewhere?
I'm
FYI,
I use
ltmain.sh (GNU libtool) 1.4 (1.920 2001/04/24 23:26:18)
on one machine, and
ltmain.sh (GNU libtool) 1.4.2 (1.922.2.53 2001/09/11 03:18:52)
on the other.
Downgrading to 1.3.3 did not solve the problem:
ltmain.sh (GNU libtool) 1.3.3 (1.385.2.181 1999/07/02 15:49:11)
I'm trying
Hm, it seems I'm not the only one having troubles compiling.
I catched this one on php.install
These are exact the same errors as I'm getting.
--Jeroen
Grigori Goronzy [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
I checked out the PHP_4_0_7 branch and tried running
Yasuo wrote:
PHP does not report any errors for too many parameters for user
defined functions, both normal function and class method :(
Is PHP designed not to report error for this?
Too many parameters for a function is obvious error and any
language MUST report error for this, unless
Pleaes use the web interface for updating bugs!
I missed this mail until now.
--Jeroen
- Original Message -
From: Doug Plant [EMAIL PROTECTED]
Newsgroups: php.dev
To: [EMAIL PROTECTED]
Sent: Sunday, October 28, 2001 4:38 AM
Subject: Re: Bug #13842 Updated: Member variables in parent and
Hi,
Suggestion: set the From: of bug-mails to [EMAIL PROTECTED], and put a
autoresponer over there asking the user again to use the web interface in
stead of replying, and possibly don't give the php-dev mail at all, or as
'only for ...'.
--Jeroen
--
PHP Development Mailing List
Please leave alone these. I was going to close them myself as
I want to add some information to them too..
I'm sorry, you committed the fix yesterday early, and I thought you might
have forgotten them. (but should've know better)
I should've mailed you instead, I got a 'then this bug is fixed
On Sun, 28 Oct 2001, Zakaria wrote:
For example:
Perl: $list = (1, 2 ,3, 'four', 'five', (6.1, 6.2, 6.3));
Python: list = [1, 2, 3, 'four', 'five', [6.1, 6.2, 6.3]]
Ruby: list = [1, 2, 3, 'four', 'five', [6.1, 6.2, 6.3]]
Tcl: set list {1 2 3 four five {6.1 6.2 6.3}}
PHP:
, it will be 1 if
non-empty, zero if empty.
IMHO, it is more logical to simply return the number of elements. It is
BC, since boolean checks for array will still yield false iff array is
empty.
(I'm - of course - open for discussion on these things)
--Jeroen
- Stig
Jeroen van Wolffelaar wrote
ID: 13748
Updated by: mfischer
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Bogus
Bug Type: Program Execution
Operating System: Windows 2000 SP2 w/IIS5.0
PHP Version: 4.0.6
New Comment:
Submitted twice - bogus.
- Markus
Whats up today guys? Did you all forgot that
Resent. The discussion isn't closed yet, and this is important, since it
will be already in 4.1.0
--Jeroen
- Original Message -
From: Jeroen van Wolffelaar [EMAIL PROTECTED]
To: Andi Gutmans [EMAIL PROTECTED]
Cc: PHP cvs [EMAIL PROTECTED]
Sent: Wednesday, October 10, 2001 8:46 PM
Subject
Resent due to lack of feedback.
- Original Message -
From: [EMAIL PROTECTED]
Newsgroups: php.dev
Sent: Wednesday, October 10, 2001 5:28 PM
Subject: heredoc: change of behavoiur?
Currently, heredoc as a bit of strange behaviour in syntax of terminating
it.
I think it's a good idea to
Resent due to lack of feedback.
Objections against me changing it to the behaviour I described below?
--Jeroen
- Original Message -
From: Jeroen van Wolffelaar [EMAIL PROTECTED]
To: PHP Developers Mailing List [EMAIL PROTECTED]
Sent: Monday, October 15, 2001 9:45 PM
Subject: Re: Bug
?
Additionally, a notice is a good idea here, just like what happens on
division by zero: the most natural result is returned, and a notice is
issued.
--Jeroen
- Original Message -
From: Jeroen van Wolffelaar [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, October 02, 2001 2:39 AM
Subject
by
bugfixes that have been applied now.
Note that it's now __not a redesign__, but new - better IMO -
interface to random functions. No BC-problems.
--Jeroen
Jeroen van Wolffelaar
[EMAIL PROTECTED]
http://www.A-Eskwadraat.nl/~jeroen
--
PHP Development Mailing List http://www.php.net
I really don't know, forwarding to php-dev...
That bug hasn't yet been looked after, it contains a reproducing script
(dba-related).
--Jeroen
- Original Message -
From: Pierre-Alain Joye [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, October 19, 2001 12:40 AM
Subject: Re:
too, it just comes down to proper
documentation now.
Sorry
--Jeroen
(Just for the record: version_compare is the only function now,
version_lt friends are gone.)
That I didn't miss...
- Stig
Jeroen van Wolffelaar wrote:
Resent. The discussion isn't closed yet, and this is important
are
supported, resulting in very strange things.
Especially the E_NOTICE when this happens will help a lot of people IMO.
In the case of casting larger integers into smallers, it's differnt
because you're talking about _intgers_ then, and not floats.
--Jeroen
- Stig
Jeroen van Wolffelaar
Does anyone object to me modifying the anoncvs.php webpage to include
the following note? Does anyone have anything to add - Jeroen? :)
There's a typo in it, but that's not what you meant :-)
I wouldn't name that SuSE thing, it's way to specific for indicating that
something DOESN'T work. I'd
of my Autotools - will try again when that is done.
--zak
On September 25, 2001 11:53 am, Jeroen van Wolffelaar wrote:
On Tue, 25 Sep 2001, Jeroen van Wolffelaar wrote:
snip
Note: after I solved that warning about automake libtool not
being in the same dir, the error remainded
Fixed
- Original Message -
From: Holger Schopohl [EMAIL PROTECTED]
Newsgroups: php.dev
To: [EMAIL PROTECTED]
Sent: Wednesday, September 26, 2001 10:51 AM
Subject: zip ext compile problem
Hi,
in the current cvs tree the zip extension
have problems to compile with zziplib 0.10.27
./ltconfig: ./ltconfig: No such file or directory
configure: error: libtool configure failed
(indeed, 'ltconfig' doesn't exist)
Also note that I didn't ever succesfully build PHP directly from CVS - I
didn't have libtool 1.4 till yesterday
--Jeroen
Jeroen van Wolffelaar
[EMAIL PROTECTED]
http://www.A
- Original Message -
From: [EMAIL PROTECTED]
To: Jeroen van Wolffelaar [EMAIL PROTECTED]
Cc: PHP Development List [EMAIL PROTECTED]
Sent: Tuesday, September 25, 2001 7:46 PM
Subject: Re: [PHP-DEV] Bug in autoconf report
On Tue, 25 Sep 2001, Jeroen van Wolffelaar wrote:
[jeroen
On Tue, 25 Sep 2001, Jeroen van Wolffelaar wrote:
snip
Note: after I solved that warning about automake libtool not being in
the same dir, the error remainded the same. (I copied the automake
executable to the same dir as the libtool executable)
Ok, but it's still a problem
indeed. The question was
wether all compilers on 32bit platforms DO have long long support at
all, in other words: is it true that all compilers for which PHP needs
to compile have a C-type which is 64bit (native or not)?
--Jeroen
Jeroen van Wolffelaar
[EMAIL PROTECTED]
http://www.A-Eskwadraat.nl
for the macro's... Unsubscribe from php-cvs while you still
can ;-)
(just kidding... I hope)
Jeroen
- Markus
On Mon, Sep 24, 2001 at 09:13:35AM +0200, Jeroen van Wolffelaar wrote :
On Sun, 23 Sep 2001 [EMAIL PROTECTED] wrote:
Hey, it's open source, go for it dude. Let us know.
:-)
I
that IF it is going to be implemented, it should be a compiler
option to choose what the type of integer needs to be: long, long long,
or something else... With proper use of macro's that would mean 1 single
#define.
--Jeroen
Jeroen van Wolffelaar
[EMAIL PROTECTED]
http://www.A-Eskwadraat.nl/~jeroen
--
PHP
Is it currently possible to undefine user functions or classes at
runtime? Although not a newbie ;) I'm unsure if its possible
right now.
No, you can't do that in PHP-userland (in the C code it can be done, see
implementation of create_function).
And IMHO that should remain so.
If not,
Hi,
For a scripting language, integers should IMHO be bounded by a number that
will reasonally not be bound by numbers that will be used in normal scripts.
That is currently not the case, 4 bytes are insufficient IMHO. Why not make
sure PHP uses 8 bytes at least? Or are there platforms not
Hi,
For a scripting language, integers should IMHO be bounded by a number that
will reasonally not be bound by numbers that will be used in normal
scripts.
That is currently not the case, 4 bytes are insufficient IMHO. Why not
make
sure PHP uses 8 bytes at least? Or are there platforms not
how much slower it is.
Anyway, it would be nice if someone with expericence with changing to 8
byte integers could share his experiences...
--Jeroen
Andi
At 09:13 PM 9/23/2001 +0200, Jeroen van Wolffelaar wrote:
Hi,
For a scripting language, integers should IMHO be bounded by a number
I would be very worried about making numbers 8 bytes by default, unless
the CPU supports them natively. There are a lot of consequenses involved
with something like that.
Assuming a 32 bit register system (x86) integers will no longer fit in
registers. This changes EVERYTHING, from passing
This subject is being crossposted to [EMAIL PROTECTED] and
[EMAIL PROTECTED]
This mail was only on engine2 (let's keep everyting at least on phpdev):
-- Forwarded message --
Date: Sun, 23 Sep 2001 22:41:45 +0200 (CEST)
From: Jeroen van Wolffelaar [EMAIL PROTECTED]
To: Stig
FYI,
I mailed the authors of that virus program, and they replied the following:
- Original Message -
From: H+BEDV Datentechnik GmbH [EMAIL PROTECTED]
To: Jeroen van Wolffelaar [EMAIL PROTECTED]
Sent: Friday, September 21, 2001 11:42 AM
Subject: Re: False positive in PHP-distribution
How can you determine it is bogus within 2 minutes, please provide your
rational.
(...)
This is probably not a bug ? Are you kidding me ? I hope you are not
closing any real nasty bugs because of this reasoning :)
From http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
Give the
I posted a bug-update 5 minutes ago, and from the mail headers:
Date: 22 Sep 2001 10:34:57 -
It is now GMT/UTC 21 sep 2001 22:30 or something.
That means that bugs.php.net is off-time by 12 hours, which is very
annoying. (chronology of posts is completely wrong).
Can someone please fix
Jeroen,
then i have one more question. The real problem im trying to solve is
Would some one please answer this question, because this is getting
somewhere (mutexs) I don't know much of. And not much is nearly nothing
in this case ;-)
--Jeroen
--
PHP Development Mailing List
On Tue, 18 Sep 2001, lo-tek @pb1.pair.com cshmoove wrote:
suppose i have a function which returns a pointer to a variable in
thread
local storage
foo_t *get_global_foo()
{
TSRMLS_FETCH();
return (foo_t *)BAR_G(foo);
}
void fubar()
{
foo_t *foo =
How can I add the function array_sum() to older php core installations?
Grep though the current source with 'array_sum', and add the three things
that come up to your 4.0.3-source: a proto in a .h-file, a PHP_FE entry, and
the PHP_FUNCTION itself.
It should work... but why not simply upgrade?
Hi all,
There has been a bit of discussion about rand(). I really appreciate that,
though I would have preferred if it was held BEFORE the changes I (tried to)
make.
Okay, back to business.
By special request, as short as possible:
(I assume you've read the latest proposal, if not, go to
then why does this work in version 4.0.4 ?
It was an implementation side-effect. It was not intentionally.
The same issue as that, for example, you can specify a variable violating
the naming rules by using:
$GLOBALS[0a\n] = Some value;
because it would be bad for performance to check for
Note added by joey,
text:
My vote: +0
Suggestions/remarks:
I'll take the proposal one piece at a time:
Good idea :-)
float random() / int random(min, max):
If I understand correctly, the only way you'll know what kind of
return the user is expecting is by counting args. That means if
No number is truly random. That is the nature of computers. You
can only generate a sequence of numbers, based on a seed.
True (of course, I knew that already long ago...), but
1) You can obscure that by using time-varying seeds in order to get
seemingly random numbers
2) You can
Is there anyone out there who uses on negative numbers?
There is the discussion on the engine2 list about whether to
make an unsigned right shift, or to introduce a new operator
.
In my opinion, and should consider integers as a row of bits, thus do
not treat the msb differently... I
FWIW:
Signed shift seems to make little sense to me personally, since we are
just dealing with a row of bits, and if you really want to do a quick
multiplication/division, you might just as well use a * or / operator -
it is not going to hurt that much:).
I completely agree
*However*,
People interested in rand can still visit
http://www.A-Eskwadraat.nl/~jeroen/rand ,
but if you have something interesting to say you can of course also mail to
php-dev!
World Wide Web Cie [EMAIL PROTECTED] wrote:
Note added by jmoore:
My vote: ±1 :)
Suggestions/remarks:
I think that PHP
Stig wrote:
Wow. :)
[[EMAIL PROTECTED]]
(...) I'll keep it short.
You were referring to this? Yes, I realized it after I sended it... I
(obviously) wrote that before I finished the mail...
Jeroen
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL
At 01:24 09-09-01, Jeroen van Wolffelaar wrote:
Exactly the same goes for ?= unless you happen to stumble across the
one-line footnote on the php.net/echo page.
So that's a documentation bug. It clearly belongs in the
documentation
about PHP's various special tags, just next
sterling Wed Sep 5 16:52:45 2001 EDT
Modified files:
/php4/ext/standard rand.c
Log:
a bit of api cleanup... move range stuff into a macro (properly :)
Yeah yeah... I know by now...
+#define RAND_RANGE(__n, __min, __max) \
+ (__min) + (int)((double)(__max) - (__min) + 1.0) *
I'm very sorry for whatever I wrote yesterday, I happend to got a quite
drunk because of the closing of the introduction. I shouldn't have gone
online in that state. I now redraw whatever I said, because I'm afraid it
wasn't all that neat.
For today I'm not going to write anything either, since
I *NEVER* have anything to say until I have seen the code. Otherwise,
it's just a bunch of castles in the air.
Okay, that's a point. That is not the custom where I learnwork, actually,
there is a saying that design planning is 67% of the job, implementing
just 33%. That is if you want a good
:[EMAIL PROTECTED]...
On Wed, 05 Sep 2001, Jeroen van Wolffelaar wrote:
Just look at the algorithm and you'll see at once it is bogus. Only in
the
special case that one single key is requested it is correct.
Proving it's bogus is trivial, so I'll leave that as an exercise to
the
reader
Resent
- Original Message -
From: [EMAIL PROTECTED]
Newsgroups: php.dev
Sent: Wednesday, September 05, 2001 11:21 PM
Subject: Re: The rand() can of worms
Bad points:
1) Leaks
2) Inconsistent style
3) Really bizzare macros, etc.
Let's put one thing straigt: I merged it
PS: Egon, go read my reply when you asked that the first time.
Wasn't I
clear? It was in plain English though...
I have only asked you, why have you deleted the comments.
It was in my mail:
- I DID NOT REMOVE THEM
Ich habe den nicht weggeholt!!!
I just MOVED them. That was
description: ++, -- operators does not conert the type of variable.
The attached patch should cure it. jeroen, are you on it or should I
commit this patch?
Jeroen van Wolffelaar
[EMAIL PROTECTED]
http://www.A-Eskwadraat.nl/~jeroen
--
PHP Development Mailing List http://www.php.net
I think the problem is the fact that we read all of the file into Memory
That seems like a bad idea to me... it doesn't get in PHP directly, only
after specific request. So you mean that PHP read's the whole file, than
writes it to /tmp (or c:\temp), and then clears the memory again?
If that's
Hi,
I'm sure there's some simple (stupid?) error, which an experienced
C-programmer can see immediately... But I don't.
You're missing a variable name (you only put a type), and the line is not
in the beginning of a code block (there's a statement before it).
php_randgen_entry is (supposed
Also, I ask again: Why didn't you just add new function random()
instead of changing all this and breaking BC.
I DID NOT BREAK BC.
Sorry, but this has been discussed dozens of times...
--jeroen
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
I was waiting for you to tell that now the branch works and I could
test it and say 'good, this works you can merge'. I'm sure everybody
else waited for same.
You do NOT need the implementation to know how it is going to be. I
explained that multiple times, and everybody (though silently)
(and *yes* I'm angry, and *yes* I'm talking to someone in particular).
And I'm now going to sleep before it gets worse.
Good night,
Jeroen
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To
See attachment. I tested it, and I'm sure it works.
--jeroen
fix_for_12245.diff
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[Changed subject, I missed this thread until now because of it...]
I assume this difference between 12 and 3 is _strictly_ performance, and
_nothing_ else?
And a note for others: You don't need TSRML* in every function, but you do
need it if you use:
- Global variables, like BG(...) co.
- Use
Better question is, do we really want to do this?
This doesn't fix anything. It only breaks things.
Second, this will make writing portable scripts harder.
Yet another ini setting to be checked for..
No! PLEASE read my propasal, this is a WRONG assumption. Even better: IF wou
want a portable
+; Default random number generator. Specify here which random number
generator
+; you want to use for the PHP-rand() function. Usually MT (Mersenne
Twister,
+; see http://www.php.net/manual/en/function.mt-rand.php) is the best
choice.
+; It is thread-safe, fast, and, quite important, mod
What's wrong with php_ prefix?
Nothing. It is just the same prefix as for PHPAPI functions, and the purpose
was to diffentiate in the name between helper functions and API-functions.
But starting it with an underscore is also a good way of achieving that, on
second thought.
-Andrei
Jeroen
I'm against that. Usually underscore-prefixed symbols are used by system
libraries and OS and we don't need to go in that direction. I'm also
against using pif_, because it's not an internal function that you are
naming, but rather, a helper one.
I don't really have an opinion on this
At 23:09 22-08-01, Andrei Zmievski wrote:
On Wed, 22 Aug 2001, Zeev Suraski wrote:
How about phf_, for PHP Helper Function?
I see a point in differentiating language level API functions (e.g.
like
output buffering) and module-specific helper functions (e.g., like
At 23:37 22-08-01, [EMAIL PROTECTED] wrote:
Hi,
I've got an experimental beginning of the new rand functions ready. I
think
it's good if others can comment on it before it is finished, because the
course can be changed now quite easily, but when it's all done, I don't
feel
much about
If it's such a far reaching change, I suggest you simply send the diff the
php-dev. It should be enough to be a basis for a discussion on the
proposed changes. If we decide to go through with it, it should be
At this time, it's merely a big move-around with code, no single thing of
What I would do in your case is:
(a) Tag the relevant files as they are today (i.e., PRE_RAND_REDESIGN or
whatever)
(b) Commit your move-around changes
(c) Commit the real changes (can be done immediately after (b), as long as
it's separate)
The real changes are not ready... and I didn't
(a) Tag the relevant files as they are today (i.e., PRE_RAND_REDESIGN or
whatever)
(b) Commit your move-around changes
I really think a lot of people will set ext/standard to PRE_RAND_REDESIGN
then, because they want to work on other parts, and don't want a broken
build. That's the other
Execute - in ext/standard:
cvs update -rRAND_REDESIGN Makefile.in php_rand.h php_math.h rand.c
rand_mt.c crypt.c
And check it out... (I didn't branch whole ext/standard, so it's needed to
name the necessary files... sorry)
Jeroen
--
PHP Development Mailing List http://www.php.net/
To
Execute - in ext/standard:
cvs update -rRAND_REDESIGN Makefile.in php_rand.h php_math.h rand.c
rand_mt.c crypt.c
Update: changed my mind, and branched whole ext/standard. It seems that it
doesn't cause any overhead or whatever.
So
% cvs update -rRAND_REDESIGN ext/standard
will do.
Zeev Suraski [EMAIL PROTECTED] wrote in message
5.1.0.14.2.20010822013439.02e0c498@localhost">news:5.1.0.14.2.20010822013439.02e0c498@localhost...
At 23:14 21-08-01, [EMAIL PROTECTED] wrote:
What about using the pif_ prefix for php's internal functions,
analogously
to zif? This makes them more
As I read it in CVS, chroot() will work even in safe-mode. Isn't this a
bad
idea(tm), or am I wrong?
If users can chroot in safe-mode, Apache won't serve any more pages
after
all children have been chrooted to an empty dir?
uhm, where have you read that? [ curious ]
I just reasoned
Hi,
[Impact and relevance: all functions that use randomness (including
array_shuffleco)]
After the previous discussion, I've been thinking, and I think I've got a
way which has only a neglectible BC problem (unlike my first proposal),
while still keeping the following in mind:
Probably 99% or
Hi,
About a month ago there was a discussion on the Engine 2 mailing list, about
a possible RFC-proces for the more imporant PHP-issues. In the end, there
was some consensus that it would be good if such a system exists.
I'm simply writing to get some comments, to hear what the general opinion
Just poit them to php-dev and keep bringing it up until there is some
decent
comment on it, at the moment there is no democratic process in PHP, people
just do what they want and someone normally knows some part of PHP better
than anyother, IE if you have a sessions thing speak to sascha (via
On the other hand, the latter one could be named 'RFC process', since it
hasn't yet been defined what the heck it is precisely...
RFC.. Request For Comments, its as simple as that someone posts a document
outlining what they want changed/want to do, calls it an RFC and is
litterally
The work on Zend Engine 2 has now started, _without_ a proper definition
of
it. IMHO, that's not the ideal situation, since this could lead to
strange
inconsequences, because the precise behaviour is decided during
implementation.
Umm what about the white paper that was prepaired
With what end in mind is an RFC to be created for? In the IETF, RFC's are
typically long, complex, and authoritative. They are often referenced for
years
after their inception.
Do you honestly think we could (or want to) achieve this
with PHP feature RFC's? Or will they be used only before
Now you assume that you need to pass arguments to these functions.
Which is not the case. Here's the proto:
/* {{{ proto int rand([int min, int max])
Returns a random number */
So revert that patch. mt_rand() / rand() accecpt either 2 parameters or
none at all. It was at least LESS
What about $_TAINTED ?
for non-english ppl REQUEST is a more familiar word that TAINTED. I only
encountered it when studying JS security.
+1, tainted? I needed a dictionary for that...
-- teodor
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL
Patch attached
- Original Message -
From: [EMAIL PROTECTED]
Newsgroups: php.dev
To: [EMAIL PROTECTED]
Sent: Thursday, August 09, 2001 1:12 AM
Subject: Bug #12245 Updated: gettype(true true) returns integer!
ID: 12245
Updated by: jeroen
Reported By: [EMAIL PROTECTED]
Old Status:
but why not put it into PEAR?
PEAR can be useful, but the power of PHP is, that is has so many helpful
build-in functions. And with pear, it will always be longer.
I think that new functions should be added on basis of
usefulness, not the coolness factor. IMNSHO this function
isn't very
Both function families are the same in syntax returning, only the
algorithm is different. I.e.: the semantics is the same. The algorithm -
if
correct - shouldn't bother, and shouldn't be the concern of the
programmer,
but rather the system maintainer (specific cases excluded, but than
and it is extremely easy to implement in
userland:
That is not true,
So how about this?
function str_rand($len=8)
{
$retval = strtr(md5(microtime()), chr(0x30), chr(0x4F));
return substr($retval,0,$len);
}
for($i=0; $i10; $i++){
echo str_rand(), \n;
}
I find
Hi Jeroen,
I think we're not on the same page. :) I consider both versions
of str_rand() I posted trivial...
Agree. But they are not what rand_str could do. The result has
16 different chars, just because md5 happens to have that much.
Implementing something that has NOT that limitation, is
- Original Message -
From: Andy [EMAIL PROTECTED]
To: Jeroen van Wolffelaar [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Sunday, August 05, 2001 9:47 PM
Subject: Re: PHP Notes
confirmation would be even worse, then I'd (we'd)
STILL have to go through all of the notes
(and this time
Can't post to php-cvs :-(
jeroen Sun Aug 5 16:27:04 2001 EDT
Modified files:
/php4/ext/standard math.c
Log:
Bugfix in abs(), abs(LONG_MIN) was bogus
---AND---
- Replaced the pow(LONG_MIN,1) fix for a better one
- Removed bogus left-over comment in pow()
--
Implementing something that has NOT that limitation, is far less trivial.
function str_rand($len = 8, $class = 'a-zA-Z1-9')
{
static $init = 1;
if(1 == $init){
mt_srand((double) microtime() * 100);
$init = 0;
}
$chars = array();
for($i = 0; $i
At 01:53 AM 8/4/2001 +0200, Jeroen van Wolffelaar wrote:
log(a) / log(n) is not that much harder, and its the right way, imho.
Yes, you're right that it is the right way. But for example,
for tan(x), the right way is sin(x)/cos(x).
(Not such a good example, but anyway)
As you said
See some messages I had on php-dev back around the first week of January,
2001 on this topic. FWIW, I would like to change it.
On http://marc.theaimsgroup.com/?w=4r=1s=trachtenbergq=a ,
I could only find messages about break/continue in switch statements...
Am I overlooking something? Of did
Please don't. Ini settings that change semantics are a bother, and
people should be able to choose their random function.
Both function families are the same in syntax returning, only the
algorithm is different. I.e.: the semantics is the same. The algorithm - if
correct - shouldn't bother,
log(a) / log(n) is not that much harder, and its the right way, imho.
Yes, you're right that it is the right way. But for example,
for tan(x), the right way is sin(x)/cos(x).
(Not such a good example, but anyway)
log($bla,2) is cleaner, IMO, than log($bla)/log(2), not mentioning the
possible
There is a possibility that GSL will be implemented in PHP, but that's in
GSL: GNU Scientific Library, http://sources.redhat.com/gsl/
Jeroen
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To
I am sending this patch to the php-dev list for your
consideration. Attached are the listing produced with
cvs diff -u, and listed below is a test file to
check the changes.
Basically I just added some more math funcs from the C
library (hyperbolics and exponentials).
Hyporbolic
It might be that. Just implemented the functions
taking advantage of their presence in the standard set
of math functions of the C library, so the C people
might be more familiar that the rest I guess.
Agreed, but I'm not certain this is worth the extra
bloath of relatively unneeded
1 - 100 of 116 matches
Mail list logo
