error extraño en funcion

hola de nuevo, aqui estoy otra vez colgando mis autohilos

he hecho este poutpourri con un poco de todas y 'he conseguido' alzarme
(con bastante poco merito, todo hay que decirlo) a la segunda posicion,
pero todavia a muchos milisegundos/luz de Vichenzo

Private Function Letra_Columna_5(ByVal nroCol As Long) As String 'Ivan
2
If nroCol < 27 Then _
Letra_Columna_5 = Chr$(64 + nroCol) _
Else Letra_Columna_5 = Left(Columns(nroCol) _
.Address(False, False), 2)
End Function

supongo (por buscar alguna explicacion) que la velocidad en la funcion
de Vinchenzo se debe a que es, por decirlo de alguna manera, puramente
' matematica', o sea que no utiliza una 'referencia' a celdas o
columnas, sino que hace calculos numericos 'puros' y se los asigna a
Chr().

bueno, aunque no acabo de tener claro el concepto de 'eficiencia', creo
que con este mensaje ya dejo de dar la tabarra sobre el tema.

un saludo y hasta pronto
Ivan

Hola Iván,

"Ivan" <@> escribió en el mensaje news:

...
lo que mas me llama la atencion es que los tres (Vinchenzo incluido)
pareciais pensar que seria el menos eficiente, lo que me hace pensar
que por 'eficiencia' no os referis solo a la velocidad, sino a algo mas
que no acabo de ver, y que, por el nivel de mis tres interlocutores (y
aunque me repita, no se trata de una alabanza, solo de una mera
descripcion) no dudo que debe existir.

Aquí te has confundido ;-). No se habló de eficiencia, sino de sencillez. Sencillez respecto a que no será lo mismo crear un algoritmo ("semigenérico", ya que con este sólo puedes obtener 702 columnas, 26+26^2) para obtener caracteres alfanuméricos a partir de un entero, que efectuar un simple "recorte" en una cadena devuelta por una propiedad de un objeto interno de Excel.

Precisamente, ese algoritmo es (forzosamente debe ser) el más eficiente, tanto en relación a tiempos de respuesta, como en lo que atañe al uso de recursos del sistema.

Referencias externas, el uso de los "puntos" de acceso a propiedades, métodos, colecciones, etc..., implica la carga en memoria de todo la jerarquía del objeto con sus colecciones cuya propiedad, método, etc., estés consultando, y varias llamadas internas para que finalmente el procedimiento de propiedad te devuelva el valor consultado.
Hoy en día, ¿qué importa 145 nanosegundos que 213?, pues poco, pero cuando la carga es alta, o cuando lo ejecutas en la máquina que usaba Matusalén, es cuando unos métodos se distancian de otros.

Viendo que no tienes pereza en realizar pruebas de rendimiento, te propongo que compruebes lo siguiente, calculando tiempos para las distintas sentencias que pongo a continuación, las cuales todas hacen referencia implícita o explícita a la primera celda de la primera hoja del primer libro de la actual instancia, exceptuando las dos últimas, que referenciarán la primera celda de la hoja activa del libro activo (por lo que te sugiero que establezcas la primera hoja como la activa, para que la prueba se haga efectiva sobre el mismo objeto en todos los casos)

'*******************
Application.Workbooks.Item(1).Worksheets.Item(1).Cells.Item(1, 1) = i
Application.Workbooks(1).Worksheets(1).Cells(1, 1) = i
Workbooks(1).Worksheets(1).Cells(1, 1) = i
Workbooks(1).Worksheets(1).Range("a1") = i
Worksheets(1).Cells(1, 1) = i
Worksheets(1).Range("a1") = i
Range("a1") = i
Cells(1, 1) = i
'*******************

Puedes probar con otras variaciones, pero creo que con estas serán suficientes para que puedas apreciar las diferencias de tiempos, sin perder de vista que -en el fondo- siempre estarás realizando la misma acción sobre el mismo objeto. Usa un bucle y adecúa el contador al procesador que uses, para forzar el que tarde un poco para cada una de las sentencias por separado ...a mayor paciencia, mejores resultados ;-)

Entonces, observarás que el acceso a objetos de las colecciones de Excel consumen ciertos recursos, que no lo hará el algoritmo que te propuse, ya que éste usa únicamente las funciones del núcleo, sin meter mano a ningún miembro del COM, y también verás que hay diferencias con el método de acceso que uses.

Esto responde también la pregunta de tu último mensaje, y como ves, no ibas tan desencaminado.

...
no acabo de entender el funcionamiento de esta parte de tu
funcion -> CInt(nroCol Mod 26 = 0) -> supongo que tendra algo que ver
con el 'valor booleano' aunque igualmente puedo estar diciendo una
burrada.

No, no es ninguna burrada, en cierto modo sí está relacionado con el valor boleano, aunque pueda ser indirectamente, ya que en verdad usamos el valor entero asociado al resultado boleano. Es una simplificación de esta parte de tu código original:
'== If nroCol Mod 26 = 0 Then
nroPri = Int(nroCol / 26) - 1
Else
nroPri = Int(nroCol / 26)
End If
'==
Como te percataste, cuando la división del argumento entre la cantidad de letras era entera, tenía un acarreo que sobraba, que también puede interpretarse como "cuando el resto de la división es cero, se le debe restar una unidad al cociente".
Entonces, 'True' y 'False' son dos palabras clave del lenguaje, cuyos valores son "-1" y "0" respectivamente. Simplemente nos aprovechamos de ello, puesto que la sentencia:

CInt(nroCol Mod 26 = 0)

pregunta si el resto de esa división es cero, y cuando lo es nos devuelve '-1', que es justamente lo que necesitamos sumar para corregir el desplazamiento de la letra, y cuando es falso, simplemente sumamos cero, con lo cual obtenemos el valor esperado.


Saludos
( ! ) Respuestas precedentes en Google:
http://groups.google.com/group/micr...c.es.excel
( i ) Temperancia en el foro:
http://support.microsoft.com/defaul...newsreglas

Hola Vinchenzo, muchas gracias de nuevo

muy clara y muy aclaratoria la explicacion

en cuanto pueda me lio a probar tu sugerencia, a ver si consigo
asimilar un poco mejor algunos conceptos/funcionamientos basicos

un saludo y hasta pronto
Ivan