javascript - Control deslizante logarítmico




slider logarithm (5)

Puedes usar una función como esta:

function logslider(position) {
  // position will be between 0 and 100
  var minp = 0;
  var maxp = 100;

  // The result should be between 100 an 10000000
  var minv = Math.log(100);
  var maxv = Math.log(10000000);

  // calculate adjustment factor
  var scale = (maxv-minv) / (maxp-minp);

  return Math.exp(minv + scale*(position-minp));
}

Los valores resultantes coinciden con una escala logarítmica:

js> logslider(0);
100.00000000000004
js> logslider(10);
316.22776601683825
js> logslider(20);
1000.0000000000007
js> logslider(40);
10000.00000000001
js> logslider(60);
100000.0000000002
js> logslider(100);
10000000.000000006

La función inversa sería, con las mismas definiciones para minp , maxp , minv , maxv y scale , calcular una posición del control deslizante a partir de un valor como este:

function logposition(value) {
   // set minv, ... like above
   // ...
   return (Math.log(value)-minv) / scale + minp;
}


En conjunto, envuelto en una clase y como un fragmento de código funcional, se vería así:

// Generic class:

function LogSlider(options) {
   options = options || {};
   this.minpos = options.minpos || 0;
   this.maxpos = options.maxpos || 100;
   this.minlval = Math.log(options.minval || 1);
   this.maxlval = Math.log(options.maxval || 100000);

   this.scale = (this.maxlval - this.minlval) / (this.maxpos - this.minpos);
}

LogSlider.prototype = {
   // Calculate value from a slider position
   value: function(position) {
      return Math.exp((position - this.minpos) * this.scale + this.minlval);
   },
   // Calculate slider position from a value
   position: function(value) {
      return this.minpos + (Math.log(value) - this.minlval) / this.scale;
   }
};


// Usage:

var logsl = new LogSlider({maxpos: 20, minval: 100, maxval: 10000000});

$('#slider').on('change', function() {
   var val = logsl.value(+$(this).val());
   $('#value').val(val.toFixed(0));
});

$('#value').on('keyup', function() {
   var pos = logsl.position(+$(this).val());
   $('#slider').val(pos);
});

$('#value').val("1000").trigger("keyup");
<script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js"></script>

Input value or use slider:
<input id="value" />
<input id="slider" type="range" min="0" max="20" />

Tengo un control deslizante con valores que van de 0 a 100.

Quiero asignarlos a un rango de 100 a 10,000,000.

He visto algunas funciones dispersas por la red, pero todas están en C ++. Lo necesito en Javascript

¿Algunas ideas?


Estaba buscando control deslizante Logarítmico para angular pero no puedo encontrar ninguno y luego me encontré con esta respuesta,

Y lo he creado para Angular 2+ (Demo está en Angular 6): DEMO DE TRABAJO

Gracias a @sth , por snippet:

function LogSlider(options) {
   options = options || {};
   this.minpos = options.minpos || 0;
   this.maxpos = options.maxpos || 100;
   this.minlval = Math.log(options.minval || 1);
   this.maxlval = Math.log(options.maxval || 100000);

   this.scale = (this.maxlval - this.minlval) / (this.maxpos - this.minpos);
}

LogSlider.prototype = {
   // Calculate value from a slider position
   value: function(position) {
      return Math.exp((position - this.minpos) * this.scale + this.minlval);
   },
   // Calculate slider position from a value
   position: function(value) {
      return this.minpos + (Math.log(value) - this.minlval) / this.scale;
   }
};

No del todo respondiendo la pregunta, pero para las personas interesadas, el reverso de la última línea es

return (Math.log(value)-minv)/scale + min;

solo para documentar.

TENGA EN CUENTA que el valor debe ser> 0.


Para obtener la distribución que desea, creo que puede usar esta fórmula:

var value = Math.floor(-900 + 1000*Math.exp(i/10.857255959));

Aquí hay una página independiente que imprimirá los valores que obtendrá para su control deslizante 0-100, después de pasarlos a través de esa fórmula:

<html><body><script>
for (var i = 0; i <= 100; i++) {
    var value = Math.floor(-900 + 1000*Math.exp(i/10.857255959));
    document.write(value + "<br>");
}
</script></body></html>

Los números van de 100 a 10,000,000 en lo que a mi ojo matemáticamente oxidado parece ser la distribución que deseas. 8-)


Donning asbestos longjohns ...

Ayer mi título con Publicaciones Packt, Programación Reactiva con JavaScript . No es realmente un título centrado en Node.js; los primeros capítulos tienen la intención de cubrir la teoría, y luego los capítulos de código pesado cubren la práctica. Debido a que realmente no pensé que sería apropiado no darle a los lectores un servidor web, Node.js parecía la opción más obvia. El caso se cerró antes de que incluso se abrió.

Podría haber dado una visión muy optimista de mi experiencia con Node.js. En cambio, fui honesto acerca de los puntos buenos y los puntos malos que encontré.

Permítanme incluir algunas citas que son relevantes aquí:

Advertencia: Node.js y su ecosistema son lo suficientemente calientes como para quemarte gravemente.

Cuando era asistente de maestro en matemáticas, una de las sugerencias no obvias que me dijeron fue que no le dijera a un estudiante que algo era "fácil". La razón era algo obvia en retrospectiva: si le dice a la gente que algo es fácil, alguien que no ve una solución puede terminar sintiéndose (incluso más) estúpido, porque no solo no saben cómo resolver el problema, sino que el problema que son demasiado estúpidos para entender es muy fácil.

Hay errores que no solo molestan a las personas que vienen de Python / Django, que inmediatamente recargan la fuente si cambias algo. Con Node.js, el comportamiento predeterminado es que si realiza un cambio, la versión anterior seguirá activa hasta el final de los tiempos o hasta que detenga y reinicie el servidor manualmente. Este comportamiento inapropiado no solo molesta a los pitonistas; también irrita a los usuarios nativos de Node.js que proporcionan varias soluciones. La pregunta de "Recarga automática de archivos en Node.js" tiene, al momento de escribir este artículo, más de 200 upvotes y 19 respuestas; una edición dirige al usuario a un script de niñera, node-supervisor, con página de inicio en http://tinyurl.com/reactjs-node-supervisor . Este problema ofrece a los nuevos usuarios una gran oportunidad de sentirse estúpidos porque pensaron que habían solucionado el problema, pero el comportamiento antiguo y defectuoso no cambia por completo. Y es fácil olvidarse de rebotar el servidor; Lo he hecho varias veces. Y el mensaje que me gustaría transmitir es: “No, no eres estúpido porque este comportamiento de Node.js te mordió la espalda; es solo que los diseñadores de Node.js no vieron ninguna razón para proporcionar un comportamiento apropiado aquí. Trate de lidiar con eso, quizás necesite un poco de ayuda de un supervisor de nodo u otra solución, pero por favor, no se vaya sintiendo que es estúpido. Tú no eres el que tiene el problema; El problema está en el comportamiento predeterminado de Node.js ".

Esta sección, después de un poco de debate, se dejó, precisamente porque no quiero dar una impresión de "Es fácil". Me corté las manos repetidamente mientras conseguía que las cosas funcionaran, y no quiero suavizar las dificultades y configúrense para creer que lograr que Node.js y su ecosistema funcionen bien es un asunto directo y, si no es sencillo para usted también, no sabe lo que está haciendo. Si no te encuentras con dificultades detestables al usar Node.js, eso es maravilloso. Si lo haces, espero que no te alejes sintiendo: "Soy estúpido, debe haber algo malo conmigo". No eres estúpido si experimentas sorpresas desagradables relacionadas con Node.js. ¡No eres tu! ¡Es Node.js y su ecosistema!

El Apéndice, que realmente no quería después del creciente aumento en los últimos capítulos y la conclusión, habla de lo que pude encontrar en el ecosistema y proporcionó una solución para el literalismo morónico:

Otra base de datos que parecía un ajuste perfecto, y que aún se puede canjear, es una implementación del lado del servidor del almacén de valor-clave HTML5. Este enfoque tiene la ventaja fundamental de una API que la mayoría de los buenos desarrolladores de front-end entienden lo suficientemente bien. En este sentido, también es una API que la mayoría de los desarrolladores front-end no tan buenos entienden lo suficientemente bien. Pero con el paquete node-localstorage, mientras que no se ofrece el acceso de sintaxis del diccionario (quiere usar localStorage.setItem (clave, valor) o localStorage.getItem (key), no localStorage [key]), se implementa la semántica completa de localStorage , incluyendo una cuota predeterminada de 5MB— ¿POR QUÉ? ¿Los desarrolladores de JavaScript del lado del servidor necesitan estar protegidos de sí mismos?

Para las capacidades de la base de datos del lado del cliente, una cuota de 5 MB por sitio web es realmente una cantidad generosa y útil de espacio para que los desarrolladores puedan trabajar con él. Podría establecer una cuota mucho más baja y seguir ofreciendo a los desarrolladores una mejora incalculable con respecto a la limitación junto con la administración de cookies. Un límite de 5MB no se presta muy rápidamente para el procesamiento del lado del cliente de Big Data, pero hay un margen muy generoso que los desarrolladores de recursos pueden usar para hacer mucho. Pero, por otro lado, 5MB no es una parte particularmente grande de la mayoría de los discos comprados recientemente, lo que significa que si usted y un sitio web no están de acuerdo con el uso razonable del espacio en disco, o si algún sitio es simplemente tonto, realmente no cuesta nada. mucho y no está en peligro de tener un disco duro inundado a menos que su disco duro ya estuviera demasiado lleno. Tal vez estaríamos mejor si el saldo fuera un poco más o menos, pero en general es una solución decente para abordar la tensión intrínseca para un contexto del lado del cliente.

Sin embargo, puede señalarse suavemente que cuando usted es el único código de escritura para su servidor, no necesita ninguna protección adicional para que su base de datos tenga más de un tamaño tolerable de 5 MB. La mayoría de los desarrolladores no necesitarán ni querrán herramientas que actúen como una niñera y que las protejan de almacenar más de 5 MB de datos del lado del servidor. Y la cuota de 5MB que es un acto de equilibrio dorado en el lado del cliente es un poco tonta en un servidor Node.js. (Y, para una base de datos para múltiples usuarios, como se describe en este Apéndice, puede señalarse, de manera poco dolorosa, que eso no es 5MB por cuenta de usuario a menos que cree una base de datos separada en el disco para cada cuenta de usuario; eso es 5MB compartido entre todas las cuentas de usuario juntas. ¡Eso podría ser doloroso si se vuelve viral!) La documentación indica que la cuota es personalizable, pero un correo electrónico hace una semana al desarrollador que pregunta cómo cambiar la cuota no tiene respuesta, al igual que la pregunta que hace lo mismo. . La única respuesta que he podido encontrar está en la fuente de Github CoffeeScript, donde aparece como un segundo argumento entero opcional para un constructor. Así que eso es bastante fácil, y podría especificar una cuota igual a un disco o tamaño de partición. Pero además de portar una función que no tiene sentido, el autor de la herramienta no siguió completamente una convención muy estándar de interpretar 0 que significa "ilimitado" para una variable o función donde un número entero debe especificar un límite máximo para el uso de algunos recursos. Lo mejor que puedes hacer con esta característica mala es probablemente especificar que la cuota es Infinito:

if (typeof localStorage === 'undefined' || localStorage === null)
  {      
  var LocalStorage = require('node-localstorage').LocalStorage;
  localStorage = new LocalStorage(__dirname + '/localStorage',
    Infinity);
  }

Intercambiando dos comentarios en orden:

Las personas se dispararon innecesariamente a sí mismas constantemente utilizando JavaScript en su totalidad, y parte de JavaScript se convirtió en un lenguaje respetable, fue un dicho de Douglas Crockford, en esencia, “JavaScript como lenguaje tiene algunas partes realmente buenas y otras realmente malas. Aquí están las partes buenas. Solo olvida que todo lo demás está allí ". Tal vez el ecosistema de Node.js crezca en su propio " Douglas Crockford ", quien dirá:" El ecosistema de Node.js es un Salvaje Oeste de codificación, pero se encuentran algunas gemas reales. . Aquí hay una hoja de ruta. Aquí están las áreas para evitar a casi cualquier costo. Aquí están las áreas con algunas de las prendas de vestir más ricas que se pueden encontrar en CUALQUIER idioma o entorno ”.

Quizás alguien más pueda tomar esas palabras como un desafío, seguir el ejemplo de Crockford y escribir "las partes buenas" y / o "las partes mejores" para Node.js y su ecosistema. ¡Me compraría una copia!

Y dado el grado de entusiasmo y las horas de trabajo en todos los proyectos, puede justificarse en un año, o dos, o tres, para atenuar de manera aguda cualquier comentario sobre un ecosistema inmaduro realizado en el momento de escribir este artículo. Realmente podría tener sentido en cinco años decir: “El ecosistema de Node.js 2015 tenía varios campos minados. El ecosistema Node.js 2020 tiene múltiples paraísos ”.





javascript slider logarithm