Hacer un IN en C#

08/02/2007 - 08:47 por Pelusa | Informe spam
Hola a tod@s,

¿alguien sabe si en C# se puede hacer algo parecido a un IN?

es decir, algo semejante a esto:

int i = 3;

if (i IN (1,3,5,7))
{
hacer_algo();
}

Preguntas similare

Leer las respuestas

#6 Harvey Triana
08/02/2007 - 17:02 | Informe spam
Hola

Discúlpame, no lo percibí. Quise hacerlo por mi lado.

Gracias,
<HT />


"Roberto M. Oliva" escribió en el mensaje
news:
Hola Harvey!

Lo he puesto en mi anterior mensaje. Aplicado al tuyo seria:

bool In(int i, params int[] a)
{
return (Array.Find(a, delegate(int p){ return p == i; }) == i);
}

// ejemplo:
if (In(i,1,3,5,7))
MessageBox.Show("hacer_algo");
else
MessageBox.Show("no en lista");

Saludos
Roberto M. Oliva


On 8 feb, 15:07, "Harvey Triana" wrote:
int In(int i, params int[] a)
{
return Array.Find(a, delegate(int p){ return p == i; });}

// ejemplo:
if (In(i,1,3,5,7) == i)
MessageBox.Show("hacer_algo");
else
MessageBox.Show("no en lista");

Aunque hay algo que no me gusta, la comparación In(i,1,3,5,7) == i.
¿Alguien
sabe como evitarla, y que se retorne un bool?

<HT />http://vexpert.mvps.org

"Pelusa" escribió en el
mensajenews:

> Hola a ,

> ¿alguien sabe si en C# se puede hacer algo parecido a un IN?

> es decir, algo semejante a esto:

> int i = 3;

> if (i IN (1,3,5,7))
> {
> hacer_algo();
> }
Respuesta Responder a este mensaje
#7 Octavio Hernandez
09/02/2007 - 00:47 | Informe spam
Harvey,

El que corra el triple podría ser discutible, ya que es busqueda
secuencial. Por supuesto se podría mejorar el algoritmo de búsqueda.



El algoritmo de recorrido lo tienes "encerrado" dentro de Array.Find(), y es
secuencial:

http://msdn2.microsoft.com/en-us/library/d9hy2xwa(vs.80).aspx

Slds - Octavio
Respuesta Responder a este mensaje
#8 Harvey Triana
09/02/2007 - 15:35 | Informe spam
Por cierto, la función In() con Array.Find falla si i = 0, y en el array no
se encuentra '0'. Por lo que habría que agregar código adicional para
solucionarlo. En conclución el ciclo for (leer post de Alberto) es más
eficiente.

<HT />
http://vexpert.mvps.org


"Harvey Triana" escribió en el mensaje
news:
De acuerdoAlberto la primera intensión es hacerlo así. Aunque me pico la
curiosidad de aplicar los genericos... De paso se aprende algo de lo
nuevo.

El que corra el triple podría ser discutible, ya que es busqueda
secuencial. Por supuesto se podría mejorar el algoritmo de búsqueda. Pero
para la funcion In() es perfecta la busqueda secuencial.

Saludes,
<HT />

"Alberto Poblacion"
escribió en el mensaje news:
"Harvey Triana" wrote in message
news:
int In(int i, params int[] a)
{
return Array.Find(a, delegate(int p){ return p == i; });
}

Aunque hay algo que no me gusta, la comparación In(i,1,3,5,7) == i.
¿Alguien sabe como evitarla, y que se retorne un bool?



Aunque sea menos "elegante", con el enfoque "tradicional" se genera un
código compilado que corre casi el triple que el código anterior:

bool In(int i, params int[] a)
{
for (int j=0; j<a.Length; j++)
if (a[j]==i) return true;
return false;
}






Respuesta Responder a este mensaje
#9 Roberto M. Oliva
09/02/2007 - 17:04 | Informe spam
Hola!

Pues yo sigo sin entender porque decis que:

bool In(int i, params int[] a)
{
for (int j=0; j<a.Length; j++)
if (a[j]==i) return true;
return false;
}

es mas rapido que:

bool In(int i, params int[] a)
{
return (Array.Find(a, delegate(int p){ return p == i; }) == i);

}

Supongo que Find hace lo mismo: Por cada elemento del array llama al
predicate. Luego tenemos la busqueda en el primer ejemplo con codigo
manejado:

for (int j=0; j<a.Length; j++)
// Llamada al predicate
return false;

Sin embargo Find, dentro, ya no es manejado.
Por lo poco que conozco yo de NET, las funciones de la libreria son
mas rapidas que cualquier codigo manejado que haga lo mismo o no??
Apostaria a que es mas rapido el metodo Find.

Un saludo
Roberto M. Oliva


On 9 feb, 00:47, "Octavio Hernandez"
wrote:
Harvey,

> El que corra el triple podría ser discutible, ya que es busqueda
> secuencial. Por supuesto se podría mejorar el algoritmo de búsqueda.

El algoritmo de recorrido lo tienes "encerrado" dentro de Array.Find(), y es
secuencial:

http://msdn2.microsoft.com/en-us/library/d9hy2xwa(vs.80).aspx

Slds - Octavio
Respuesta Responder a este mensaje
#10 Juan Diego Bueno
09/02/2007 - 17:12 | Informe spam
Pues yo tampoco es que sea un guru en el tema... pero hace no mucho, en una
revista, proponían 47 formas de mejorar el rendimiento en las aplicaciones
.net, y recuerdo dos principalmente:

1. Evitar usar foreach mientras se pueda usar for para recorrer una
colección
2. Declarar las mayores variables miembro de una clase como public, siempre
que su asignación no esté sujeta a ninguna validación que obligue a
encapsularla

No es exactamente lo mismo, pero uno se plantea... ¿entonces, para qué las
mejoras en el lenguaje?

"Roberto M. Oliva" escribió en el mensaje
news:
Hola!

Pues yo sigo sin entender porque decis que:

bool In(int i, params int[] a)
{
for (int j=0; j<a.Length; j++)
if (a[j]==i) return true;
return false;
}

es mas rapido que:

bool In(int i, params int[] a)
{
return (Array.Find(a, delegate(int p){ return p == i; }) == i);

}

Supongo que Find hace lo mismo: Por cada elemento del array llama al
predicate. Luego tenemos la busqueda en el primer ejemplo con codigo
manejado:

for (int j=0; j<a.Length; j++)
// Llamada al predicate
return false;

Sin embargo Find, dentro, ya no es manejado.
Por lo poco que conozco yo de NET, las funciones de la libreria son
mas rapidas que cualquier codigo manejado que haga lo mismo o no??
Apostaria a que es mas rapido el metodo Find.

Un saludo
Roberto M. Oliva


On 9 feb, 00:47, "Octavio Hernandez"
wrote:
Harvey,

> El que corra el triple podría ser discutible, ya que es busqueda
> secuencial. Por supuesto se podría mejorar el algoritmo de búsqueda.

El algoritmo de recorrido lo tienes "encerrado" dentro de Array.Find(), y
es
secuencial:

http://msdn2.microsoft.com/en-us/library/d9hy2xwa(vs.80).aspx

Slds - Octavio





Estoy utilizando la versión gratuita de SPAMfighter para usuarios privados.
Ha eliminado 5435 correos spam hasta la fecha.
Los abonados no tienen este mensaje en sus correos.
¡Pruebe SPAMfighter gratis ya!
Respuesta Responder a este mensaje
Ads by Google
Help Hacer una preguntaSiguiente AnteriorRespuesta Tengo una respuesta
Search Busqueda sugerida