[SP-pm] [OFF-TOPIC] Masturbações Mentais sobre Undefined Behavior

[Blabos de Blebe]

> ordem de keys(%hash) é perfeitamente "expected", pois as chaves iguais
> produzem hashes iguais.

Não necessariamente, veja:

perl -MData::Dumper -E '%a = map {"\0"x$_ => $_} 0..15; say Dumper \%a'

Dê uma olhada no arquivo INSTALL do perl 5.12.2, seção "Algorithmic
Complexity Attacks on Hashes":

...

"In Perl 5.8.2 an improved scheme was introduced.  Hashes will return
elements in the same order as Perl 5.8.0 by default.  On a hash by hash
basis, if pathological data is detected during a hash key insertion,
then that hash will switch to an alternative random hash seed."

...

"B<Perl has never guaranteed any ordering of the hash keys>"

...

UNDEFINED != UNEXPECTED

:)


O hash é uma estrutura de dados na qual a ordem das chaves é
indefinida. Num hash ideal a distribuição é uniforme e o tempo de
acesso é limitado por uma constante. Mas um hash pode degenerar numa
lista linear.

Embora devesse, na minha opinião, não é necessário saber disso pra
*usar* um hash. Você confia no caso médio da abstração e segue em
frente. Nao é assim que a gente age em 99% dos casos?

Só que quando você se deparar com os 1% restantes, você tem que estar
preparado pra saber se o hash vai degenerar ou não e qual o custo.

Como eu disse ontem numa aula, ainda bem que não construímos prédios
como construímos software.

Se você constrói (ou permite que se construa) um barraco numa encosta
ele vai ficar de pé vários dias. Num fatídico vem a chuva e leva a
encosta, o barraco, vc e os vizinhos, tudo pro saco. Puxa vida, mas
ninguém esperava que chovesse tanto num dia, pobrezinho...

Assim é a nossa "Engenharia de Software"

Abraços

2011/2/15 Stanislaw Pusep <creaktive em gmail.com>:
> Good point!
> "Undefined" é muito forte; considerando os seus argumentos, "unexpected" é
> mais apropriado (até por que considera o fator humano). Por outro lado, a
> ordem de keys(%hash) é perfeitamente "expected", pois as chaves iguais
> produzem hashes iguais. Sendo assim, a única coisa totalmente "unexpected"
> que conheço é rand(), e olha lá :P
>
> ABS()
>
>
>
> 2011/2/14 Eden Cardim <edencardim em gmail.com>
>>
>> >>>>> "Stanislaw" == Stanislaw Pusep <creaktive em gmail.com> writes:
>>
>>    Stanislaw> Olha, não sei quanto aos outros participantes da lista,
>>    Stanislaw> mas eu simplesmente não consigo me ater a todos esses
>>    Stanislaw> detalhes :( Então nunca uso esse operador que me confunde
>>    Stanislaw> (PARA MIM, é um "Undefined Behavior"), preferindo fazer
>>    Stanislaw> "à moda antiga" (última coluna). Enfim, sou desses caras
>>    Stanislaw> que enchem qqer operação de ()'s, tipo: ((($x / $y) - $z)
>>    Stanislaw> > 0).  Enfim, o que quero dizer é que o Perl tem um
>>    Stanislaw> imenso potencial de produzir código cheio de
>>    Stanislaw> Pseudo-undefined Behavior;
>>
>> Acho que você está distorcendo o significado de "undefined", que
>> significa "não definido". O operador ~~ tem uma semântica bastante
>> complexa sim, mas o comportamento dele *é definido* para todo e qualquer
>> caso onde ele for utilizado, o que significa que se ele comporta-se
>> diferentemente da definição presente na documentação, existe um bug na
>> implementação. A noção de "pseudo-undefined behaviour" não faz o menor
>> sentido, na verdade o que você queria dizer era "behaviour
>> unknown/ignored by myself". Se o comportamento não fosse definido, nem
>> os parênteses te salvadoriam.
>>
>> Os dois casos de undefined behaviour em perl que eu consigo lembrar
>> nesse exato momento são:
>>
>> keys(%hash) - não define a ordem de retorno das chaves, devido a um
>> corolário da definição de hash maps.
>>
>> $i++ + ++$i - assim como em C, usar operadores de incremento/decremento
>> mais de uma vez na mesma variável, no mesmo statement, resulta em
>> undefined behaviour.
>>
>> Sim, perl te dá corda suficiente pra você se enforcar, mas qualquer
>> linguagem com uma determinada margem de flexibilidade também. C, por
>> exemplo, permite que você escreva em pontos arbitrários da memória (e
>> quem vai reclamar com você é o kernel em questão). Porém, isso é um
>> assunto ortogonal à definição de comportamento.
>>
>>    Stanislaw> por que ninguém tem obrigação de saber todas as faces de
>>    Stanislaw> todos os operadores; isso sem contar as L<perlvar>.
>>
>> Pra poder afirmar que existe um "undefined behaviour" dentro de uma
>> discussão formal sem mentir ou se equivocar, você precisa sim, no
>> mínimo, conhecer todas as definições existentes.
>>
>> --
>> Eden Cardim
>> Software Engineer
>> +55 73 9986-3963
>> edencardim.com
>> =begin disclaimer
>>   Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>>  SaoPaulo-pm mailing list: SaoPaulo-pm em pm.org
>>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
>> =end disclaimer
>
>
> =begin disclaimer
>   Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>  SaoPaulo-pm mailing list: SaoPaulo-pm em pm.org
>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
> =end disclaimer
>
>