Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #34484 > unrolled thread

Java Source of Meiyan Hash Scrambler?

Back to article view | Back to comp.lang.java.programmer

Contents

  Java Source of Meiyan Hash Scrambler? bursejan@gmail.com - 2016-06-05 17:22 -0700
    Re: Java Source of Meiyan Hash Scrambler? Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-06 07:48 -0400
      Re: Java Source of Meiyan Hash Scrambler? Jan Burse <janburse@fastmail.fm> - 2016-06-06 14:13 +0200
        TreeBins Problem and Float/Double (Was: Java Source of Meiyan Hash Scrambler?) Jan Burse <janburse@fastmail.fm> - 2016-06-06 14:45 +0200
        Re: Java Source of Meiyan Hash Scrambler? Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-06 08:47 -0400
        Floating-point hash keys (Was: Java Source of Meiyan Hash Scrambler?) Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-06 12:02 -0400
          Re: Floating-point hash keys (Was: Java Source of Meiyan Hash Scrambler?) Roedy Green <inquiry@mindprod.com> - 2016-06-09 05:33 -0700
            Re: Floating-point hash keys (Was: Java Source of Meiyan Hash Scrambler?) Jan Burse <janburse@fastmail.fm> - 2016-06-09 16:27 +0200
    Re: Java Source of Meiyan Hash Scrambler? Roedy Green <inquiry@mindprod.com> - 2016-06-07 03:24 -0700
      Re: Java Source of Meiyan Hash Scrambler? Jan Burse <janburse@fastmail.fm> - 2016-06-07 15:38 +0200
      Re: Java Source of Meiyan Hash Scrambler? Jan Burse <janburse@fastmail.fm> - 2016-06-07 15:39 +0200
        Sideremark II ( Re: Java Source of Meiyan Hash Scrambler?) Jan Burse <janburse@fastmail.fm> - 2016-06-07 15:42 +0200
          Re: Sideremark II ( Re: Java Source of Meiyan Hash Scrambler?) Roedy Green <inquiry@mindprod.com> - 2016-06-09 05:29 -0700
            Re: Sideremark II ( Re: Java Source of Meiyan Hash Scrambler?) Mike Amling <mamling@chaff.us> - 2016-06-09 08:00 -0500
              Re: Sideremark II ( Re: Java Source of Meiyan Hash Scrambler?) Eric Douglas <e.d.programmer@gmail.com> - 2016-06-09 06:07 -0700
                Re: Sideremark II ( Re: Java Source of Meiyan Hash Scrambler?) Jerry Stuckle <jstucklex@attglobal.net> - 2016-06-09 11:41 -0400
                Re: Sideremark II ( Re: Java Source of Meiyan Hash Scrambler?) Roedy Green <inquiry@mindprod.com> - 2016-06-11 01:17 -0700
                  Re: Sideremark II ( Re: Java Source of Meiyan Hash Scrambler?) Daniel Pitts <usenet@coloraura.com> - 2016-06-11 12:31 -0700
                  Re: Sideremark II ( Re: Java Source of Meiyan Hash Scrambler?) Mike Amling <mamling@chaff.us> - 2016-06-12 15:42 -0500
                    Re: Sideremark II ( Re: Java Source of Meiyan Hash Scrambler?) Daniel Pitts <usenet@coloraura.com> - 2016-06-12 21:03 -0700
                      Re: Sideremark II ( Re: Java Source of Meiyan Hash Scrambler?) Roedy Green <inquiry@mindprod.com> - 2016-06-13 14:13 -0700
          Re: Sideremark II ( Re: Java Source of Meiyan Hash Scrambler?) Roedy Green <inquiry@mindprod.com> - 2016-06-10 14:11 -0700
        Re: Java Source of Meiyan Hash Scrambler? Roedy Green <inquiry@mindprod.com> - 2016-06-07 20:38 -0700
          Re: Java Source of Meiyan Hash Scrambler? Roedy Green <inquiry@mindprod.com> - 2016-06-09 05:15 -0700
            Re: Java Source of Meiyan Hash Scrambler? Jan Burse <janburse@fastmail.fm> - 2016-06-09 16:26 +0200
              Re: Java Source of Meiyan Hash Scrambler? Roedy Green <inquiry@mindprod.com> - 2016-06-12 02:28 -0700
                Re: Java Source of Meiyan Hash Scrambler? j4n bur53 <janburse@fastmail.fm> - 2016-06-12 12:03 +0200
                  Re: Java Source of Meiyan Hash Scrambler? Andreas Leitgeb <avl@logic.at> - 2016-06-13 14:07 +0000
                    Re: Java Source of Meiyan Hash Scrambler? Andreas Leitgeb <avl@logic.at> - 2016-06-13 14:17 +0000
                      Re: Java Source of Meiyan Hash Scrambler? Andreas Leitgeb <avl@logic.at> - 2016-06-13 14:20 +0000
                      Re: Java Source of Meiyan Hash Scrambler? j4n bur53 <janburse@fastmail.fm> - 2016-06-13 16:23 +0200

Page 1 of 2  [1] 2  Next page →

#34484 — Java Source of Meiyan Hash Scrambler?

Dear All,

Does somebody have Java code for the Meiyan hash scrambler.
I would like to test it against float32 and float64. These IEEE
formats have as a hashCode() in Java usually their bit 
representation.

In this bit representation the mantissa is shifted to the upper
end, just after the sign and the exponent. With the result that
the hash has no sensitivity on the magnitude definining bits of
a float number.

Here is some test code:

    public static void main(String[] args) {
        float[] tabf = {1.0f, 2.0f, 3.0f, 4.0f, 5.0f, 6.0f, 7.0f, 8.0f};
        for (int i = 0; i < tabf.length; i++) {
            float f = tabf[i];
            int h = Float.hashCode(f);
            System.out.println("f=" + f + ", hash(f)=" + h + 
                               ", hash(f)%4=" + (h & 3));
        }
        double[] tabd = {1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 8.0};
        for (int i = 0; i < tabd.length; i++) {
            double d = tabd[i];
            int h = Double.hashCode(d);
            System.out.println("d=" + d + ", hash(d)=" + h + 
                               ", hash(d)%4=" + (h & 3));
        }
        String[] tabs = {".", "[]"};
        for (int i = 0; i < tabs.length; i++) {
            String s = tabs[i];
            int h = s.hashCode();
            System.out.println("s=" + s + ", hash(s)=" + h + 
                               ", hash(s)%4=" + (h & 3));
        }
    }

The problem is then seen here, the different floats and
doubles cannot be distinguished:

f=1.0, hash(f)=1065353216, hash(f)%4=0
f=2.0, hash(f)=1073741824, hash(f)%4=0
f=3.0, hash(f)=1077936128, hash(f)%4=0
f=4.0, hash(f)=1082130432, hash(f)%4=0
f=5.0, hash(f)=1084227584, hash(f)%4=0
f=6.0, hash(f)=1086324736, hash(f)%4=0
f=7.0, hash(f)=1088421888, hash(f)%4=0
f=8.0, hash(f)=1090519040, hash(f)%4=0
d=1.0, hash(d)=1072693248, hash(d)%4=0
d=2.0, hash(d)=1073741824, hash(d)%4=0
d=3.0, hash(d)=1074266112, hash(d)%4=0
d=4.0, hash(d)=1074790400, hash(d)%4=0
d=5.0, hash(d)=1075052544, hash(d)%4=0
d=6.0, hash(d)=1075314688, hash(d)%4=0
d=7.0, hash(d)=1075576832, hash(d)%4=0
d=8.0, hash(d)=1075838976, hash(d)%4=0
s=., hash(s)=46, hash(s)%4=2
s=[], hash(s)=2914, hash(s)%4=2

So I tryed the last phase of murmur, and look see it 
works wonderful:

    static int murmur(int x) {
        x ^= x >> 13;
        x *= 0x5bd1e995;
        return x ^ (x >> 15);
    }

The result is now:

f=1.0, hash(f)=17018375, murmur(hash(f))%4=3
f=2.0, hash(f)=321529428, murmur(hash(f))%4=0
f=3.0, hash(f)=473764474, murmur(hash(f))%4=2
f=4.0, hash(f)=626007712, murmur(hash(f))%4=0
f=5.0, hash(f)=702134963, murmur(hash(f))%4=3
f=6.0, hash(f)=778248902, murmur(hash(f))%4=2
f=7.0, hash(f)=854423258, murmur(hash(f))%4=2
f=8.0, hash(f)=930531053, murmur(hash(f))%4=1
d=1.0, hash(d)=1863980106, murmur(hash(d))%4=2
d=2.0, hash(d)=321529428, murmur(hash(d))%4=0
d=3.0, hash(d)=1414319576, murmur(hash(d))%4=0
d=4.0, hash(d)=1787945053, murmur(hash(d))%4=1
d=5.0, hash(d)=1241552607, murmur(hash(d))%4=3
d=6.0, hash(d)=695108322, murmur(hash(d))%4=2
d=7.0, hash(d)=148737060, murmur(hash(d))%4=0
d=8.0, hash(d)=397654631, murmur(hash(d))%4=3
s=., hash(s)=2142701481, murmur(hash(s))%4=1
s=[], hash(s)=728007875, murmur(hash(s))%4=3

But according to some stats on the web Meiyan is better.
But I couldn't figure out some code. It seems to be 
variant of FNV1a.

Any ideas?

Bye

[toc] | [next] | [standalone]

#34490

On 6/5/2016 8:22 PM, bursejan@gmail.com wrote:
> Dear All,
>
> Does somebody have Java code for the Meiyan hash scrambler.
> I would like to test it against float32 and float64. These IEEE
> formats have as a hashCode() in Java usually their bit
> representation.

     s/usually/always/ (according to the JavaDoc).

> In this bit representation the mantissa is shifted to the upper
> end, just after the sign and the exponent. With the result that
> the hash has no sensitivity on the magnitude definining bits of
> a float number.

     Hmmm?  Float.hashCode() uses all thirty-two bits of the float,
and Double.hashCode() uses all sixty-four bits of the double.  All
the bits -- including the exponent bits -- contribute to the hashes.

> Here is some test code:
>
>     public static void main(String[] args) {
>         float[] tabf = {1.0f, 2.0f, 3.0f, 4.0f, 5.0f, 6.0f, 7.0f, 8.0f};
>         for (int i = 0; i < tabf.length; i++) {
>             float f = tabf[i];
>             int h = Float.hashCode(f);
>             System.out.println("f=" + f + ", hash(f)=" + h +
>                                ", hash(f)%4=" + (h & 3));
>         }
>         double[] tabd = {1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 8.0};
>         for (int i = 0; i < tabd.length; i++) {
>             double d = tabd[i];
>             int h = Double.hashCode(d);
>             System.out.println("d=" + d + ", hash(d)=" + h +
>                                ", hash(d)%4=" + (h & 3));
>         }
>         String[] tabs = {".", "[]"};
>         for (int i = 0; i < tabs.length; i++) {
>             String s = tabs[i];
>             int h = s.hashCode();
>             System.out.println("s=" + s + ", hash(s)=" + h +
>                                ", hash(s)%4=" + (h & 3));
>         }
>     }
>
> The problem is then seen here, the different floats and
> doubles cannot be distinguished:
>
> f=1.0, hash(f)=1065353216, hash(f)%4=0
> f=2.0, hash(f)=1073741824, hash(f)%4=0
> f=3.0, hash(f)=1077936128, hash(f)%4=0
> f=4.0, hash(f)=1082130432, hash(f)%4=0
> f=5.0, hash(f)=1084227584, hash(f)%4=0
> f=6.0, hash(f)=1086324736, hash(f)%4=0
> f=7.0, hash(f)=1088421888, hash(f)%4=0
> f=8.0, hash(f)=1090519040, hash(f)%4=0

     Eight different float values, eight different hashCode() values.

> d=1.0, hash(d)=1072693248, hash(d)%4=0
> d=2.0, hash(d)=1073741824, hash(d)%4=0
> d=3.0, hash(d)=1074266112, hash(d)%4=0
> d=4.0, hash(d)=1074790400, hash(d)%4=0
> d=5.0, hash(d)=1075052544, hash(d)%4=0
> d=6.0, hash(d)=1075314688, hash(d)%4=0
> d=7.0, hash(d)=1075576832, hash(d)%4=0
> d=8.0, hash(d)=1075838976, hash(d)%4=0

     Eight different double values, eight different hashCode() values.
Also, seven of the eight are different from their corresponding
Float.hashCode((float) d) values.  I do not understand why you think
they "cannot be distinguished."

>[...]
> Any ideas?

     About what?  What do you think is wrong with Float.hashCode() and
Double.hashCode() as they stand?

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#34491

Eric Sosman schrieb:
>      Hmmm?  Float.hashCode() uses all thirty-two bits of the float,
> and Double.hashCode() uses all sixty-four bits of the double.  All
> the bits -- including the exponent bits -- contribute to the hashes.

They contribute to the hash code, i.e. the result of hashCode(). But
they don't contribute to the hash table index.

The hash table index is usually calculated:

    int index = key.hashCode() & (table.length - 1);

Oracle/Java has itself recognized that with the lower bit masking to
compute the index, there is a problem for float32 and float64.

So what they do is actually:

    int index = (h = key.hashCode()) ^ (h >>> 16) & (table.length - 1);
    /* See for example source of HashMap implementation,
       static method hash(Object) */

Oracle/Java explicitly mention floats as a reason to do this:

     /**
      * Computes key.hashCode() and spreads (XORs) higher bits of hash
      * to lower.  Because the table uses power-of-two masking, sets of
      * hashes that vary only in bits above the current mask will
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
      * always collide. (Among known examples are sets of Float keys
      * holding consecutive whole numbers in small tables.)  So we
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      * apply a transform that spreads the impact of higher bits
      * downward. There is a tradeoff between speed, utility, and
      * quality of bit-spreading. Because many common sets of hashes
      * are already reasonably distributed (so don't benefit from
      * spreading), and because we use trees to handle large sets of
      * collisions in bins, we just XOR some shifted bits in the
      * cheapest possible way to reduce systematic lossage, as well as
      * to incorporate impact of the highest bits that would otherwise
      * never be used in index calculations because of table bounds.
      */

So basically their scramble function is:

    int scramble(int h) {
       return h ^ (h >>> 16);
    }

But this scramble function is still weak for float32 and float64,
for my test table I still get, where the hash table length is 4:

f=1.0, hash(f)=1065369472, scramble(hash(f))%4=0
f=2.0, hash(f)=1073758208, scramble(hash(f))%4=0
f=3.0, hash(f)=1077952576, scramble(hash(f))%4=0
f=4.0, hash(f)=1082146944, scramble(hash(f))%4=0
f=5.0, hash(f)=1084244128, scramble(hash(f))%4=0
f=6.0, hash(f)=1086341312, scramble(hash(f))%4=0
f=7.0, hash(f)=1088438496, scramble(hash(f))%4=0
f=8.0, hash(f)=1090535680, scramble(hash(f))%4=0
d=1.0, hash(d)=1072709616, scramble(hash(d))%4=0
d=2.0, hash(d)=1073758208, scramble(hash(d))%4=0
d=3.0, hash(d)=1074282504, scramble(hash(d))%4=0
d=4.0, hash(d)=1074806800, scramble(hash(d))%4=0
d=5.0, hash(d)=1075068948, scramble(hash(d))%4=0
d=6.0, hash(d)=1075331096, scramble(hash(d))%4=0
d=7.0, hash(d)=1075593244, scramble(hash(d))%4=0
d=8.0, hash(d)=1075855392, scramble(hash(d))%4=0
s=., hash(s)=46, scramble(hash(s))%4=2
s=[], hash(s)=2914, scramble(hash(s))%4=2

So contrary to Oracle/Java claim this scramble function is
not good for float32 and float64 as they describe.

The reason is simple the mantissa for float32 and float64
is at bit 23 respectively 20. So the >>> 16 is for no
avaiable, it still doesn't shift the mantissa to the lowest
bits.

On the other hand, as I showed in my original post,
murmur() is much better.

But how about Meiyan, has anybody some Java code for
Meiyan scrambler. Maybe this is even better than murmur.

Bye

[toc] | [prev] | [next] | [standalone]

#34494 — TreeBins Problem and Float/Double (Was: Java Source of Meiyan Hash Scrambler?)

Jan Burse schrieb:
>
> On the other hand, as I showed in my original post,
> murmur() is much better.
>
> But how about Meiyan, has anybody some Java code for
> Meiyan scrambler. Maybe this is even better than murmur.

I wouldn't be surprised, that in practical scenarios,
with better scrambling the switching from list bins to tree
bins would less often happen.

tree bins have recently been introduced in the implementation
of HashMap, making them a little bit more heavy weight.
Oracle/Java writes here:

     /**
      * Because TreeNodes are about twice the size of regular nodes, we
      * use them only when bins contain enough nodes to warrant use
      * (see TREEIFY_THRESHOLD). And when they become too small (due to
      * removal or resizing) they are converted back to plain bins.  In
      * usages with well-distributed user hashCodes, tree bins are
      * rarely used.  Ideally, under random hashCodes, the frequency of
      * nodes in bins follows a Poisson distribution
      * (http://en.wikipedia.org/wiki/Poisson_distribution) with a
      * parameter of about 0.5 on average for the default resizing
      * threshold of 0.75, although with a large variance because of
      * resizing granularity. Ignoring variance, the expected
      * occurrences of list size k are (exp(-0.5) * pow(0.5, k) /
      * factorial(k)). The first values are:
      */

But the distribution assumption is probably broken for
float32 and float64, since they have a particular bit pattern,
see the IEEE 754 spec.

float32 example:
https://de.wikipedia.org/wiki/IEEE_754#/media/File:IEEE-754-single.svg

The mantissa is always shifted away from the lowest bits, and
the exponent counts this shift. The binary point between mantissa
integral part and fractional part without the exponent is directly
represented in the bits after the exponent.

The mantissa is assumed to be 1 =< m < 2.

[toc] | [prev] | [next] | [standalone]

#34495

On 6/6/2016 8:13 AM, Jan Burse wrote:
> Eric Sosman schrieb:
>>      Hmmm?  Float.hashCode() uses all thirty-two bits of the float,
>> and Double.hashCode() uses all sixty-four bits of the double.  All
>> the bits -- including the exponent bits -- contribute to the hashes.
>
> They contribute to the hash code, i.e. the result of hashCode(). But
> they don't contribute to the hash table index.

     Aha!  Sorry; I thought your problem was with the hashCode() values
themselves.

> But this scramble function is still weak for float32 and float64,
> for my test table I still get, where the hash table length is 4:

     That seems a peculiar size for the hash table.  The default
initial capacity for a HashMap is sixteen, and with the default
load factor of 0.75 the map will grow to sixteen slots by the
time you've inserted eight keys.  The only way I can imagine an
eight-key HashMap with only four buckets is if you specified an
initial capacity of four and a load factor greater than two.

     However, your point stands: Even with a sixteen-bucket table,
the low-order four bits of your small key set will not scramble
very well ...

> So contrary to Oracle/Java claim this scramble function is
> not good for float32 and float64 as they describe.

     Much depends on the values of the keys (as is the case for
all hashing schemes).

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#34497 — Floating-point hash keys (Was: Java Source of Meiyan Hash Scrambler?)

On 6/6/2016 8:13 AM, Jan Burse wrote:
> [... poor scattering of Float.hashCode() and Double.hashCode() ...]

     It's a bit tangential, but I've been wondering: Why do you want to
use floating-point numbers as hash keys?

     There's nothing wrong with a Float or Double key once you have it
(aside from the weaknesses you've noticed for zero-rich mantissas),
but my question is: How do you calculate such a key accurately?  We
all know that computations can be "identical" in a mathematical sense
but quite different computationally.  If you store something with a
key X and later run a "similar" calculation to get X' (different by
a ULP or so), the hash table won't find the original entry.

     So: Are these Floats and Doubles "really" floating-point numbers,
or are they "proxies" for something else?  If so, it might be wiser
to use the "something else" as the key instead.

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#34584 — Re: Floating-point hash keys (Was: Java Source of Meiyan Hash Scrambler?)

On Mon, 6 Jun 2016 12:02:42 -0400, Eric Sosman
<esosman@comcast-dot-net.invalid> wrote:
I found nothing at all on the Meiyan scrambler. Does it have another
name or spelling?

[toc] | [prev] | [next] | [standalone]

#34588 — Re: Floating-point hash keys (Was: Java Source of Meiyan Hash Scrambler?)

Roedy Green schrieb:
> On Mon, 6 Jun 2016 12:02:42 -0400, Eric Sosman
> <esosman@comcast-dot-net.invalid> wrote:
> I found nothing at all on the Meiyan scrambler. Does it have another
> name or spelling?
>

Its in the top-list here:

Results, Core i5 processor:
http://www.strchr.com/hash_functions

But when I follow to this link:
http://www.sanmayce.com/Fastest_Hash/

I am little bit lost.

Bye

[toc] | [prev] | [next] | [standalone]

#34520

On Sun, 5 Jun 2016 17:22:07 -0700 (PDT), bursejan@gmail.com wrote:

>Does somebody have Java code for the Meiyan hash scrambler.

I have posted the code for a seven types of checksums
with variants.

see http://mindprod.com/jgloss/checksum.html

Unfortunately, Meiyan is not among them.

[toc] | [prev] | [next] | [standalone]

#34530

Hi Lazyweb,

I have also seen this code already, thanks very much. And
Meiyan is said to be a variant of fnv. But problem with
your code samples is as follows:

     The checksum as you call it, is computed for
     a byte[] argument and returns an int.

But I need a scrambler which is based on the following
interface and still fast:

     The scrambler should take an int and
     return an int.

Now I see different problems with porting the byte[] solution.
Primarily that what looks as an efficient algorithm is suddently
not so efficient.

Just remember the number of arithmetic/bitwise ops:

     Oracle/Java: 2 Operations (>>>, ^)
         return h ^ (h >>> 16)

     murmur: 5 Operations (>>, ^, *, >>, ^)
         x ^= x >> 13;
         x *= 0x5bd1e995;
         return x ^ (x >> 15);

So if somebody has Meiyan AND its even shorter than
murmur in number of operations this would be great.

But a Meiyan which is longer in number of operations
would be also of interest to take a look.

Bye

Roedy Green schrieb:
> On Sun, 5 Jun 2016 17:22:07 -0700 (PDT), bursejan@gmail.com wrote:
>
>> Does somebody have Java code for the Meiyan hash scrambler.
>
> I have posted the code for a seven types of checksums
> with variants.
>
> see http://mindprod.com/jgloss/checksum.html
>
> Unfortunately, Meiyan is not among them.
>

[toc] | [prev] | [next] | [standalone]

#34531

Roedy Green schrieb:
> seehttp://mindprod.com/jgloss/checksum.html
Small side remark, your pretty printer should be
adapted to accept the new Java number notation:

MAGIC_PRIME = 16_777_619

The _777_619 has a different color from the 16.

[toc] | [prev] | [next] | [standalone]

#34532 — Sideremark II ( Re: Java Source of Meiyan Hash Scrambler?)

Is the pretty printer also open source, available
on your web site? Interesting nice rainbow
coloring scheme. Or do you use some IDE?

Did you ever try to pretty print JSP, i.e. a mix
of XML and Java. Or do you have a XML pretty printer
separately, without the Java snippets?

Jan Burse schrieb:
> Roedy Green schrieb:
>> seehttp://mindprod.com/jgloss/checksum.html
> Small side remark, your pretty printer should be
> adapted to accept the new Java number notation:
>
> MAGIC_PRIME = 16_777_619
>
> The _777_619 has a different color from the 16.

[toc] | [prev] | [next] | [standalone]

#34583 — Re: Sideremark II ( Re: Java Source of Meiyan Hash Scrambler?)

On Tue, 7 Jun 2016 15:42:18 +0200, Jan Burse <janburse@fastmail.fm>
wrote:

>Is the pretty printer also open source, available
>on your web site? Interesting nice rainbow
>coloring scheme. Or do you use some IDE?

the source code is posted at http://mindprod/products.html#JPREP.

It has finite state parsers for various languages.
They are very forgiving, unlike real language parsers, so you can
display snippets, not just whole programs.

Ahead of time parsers generate a stream of tokens.

That stream is rendered three ways:
inline as HTML (small)
as an  iframe HTML (medium) 
as an Applet that renders the tokens at a low level on a Canvas.
(large)

It parses:
Bali (my proposed succesor to Java)
Java
HTML
CSV
INI
BAT 
CSS
properties
SQL
vanilla text
manifest files

It is incredibly quick. I generated the parsers manually.

You control the colours, sizes and fonts two ways. with css, and with
Java constants for Applet rendering each attached to a token.

[toc] | [prev] | [next] | [standalone]

#34585 — Re: Sideremark II ( Re: Java Source of Meiyan Hash Scrambler?)

On 6/9/16 7:29 AM, Roedy Green wrote:
> On Tue, 7 Jun 2016 15:42:18 +0200, Jan Burse <janburse@fastmail.fm>
> wrote:
>
>> Is the pretty printer also open source, available
>> on your web site? Interesting nice rainbow
>> coloring scheme. Or do you use some IDE?
>
> the source code is posted at http://mindprod/products.html#JPREP.

Is it?

--Mike Amling
TGV0J3Mgc2VlLCBpcyBpdCBtaW5kcHJvZC5jb20gb3IgbWluZHByb2QubmV0IG9yIG1pbmRwcm9k
Lm9yZyBvciBtaW5kcHJvZC5jby51ayBvciAuLi4=

[toc] | [prev] | [next] | [standalone]

#34586 — Re: Sideremark II ( Re: Java Source of Meiyan Hash Scrambler?)

On Thursday, June 9, 2016 at 8:59:50 AM UTC-4, Mike Amling wrote:
> > the source code is posted at http://mindprod/products.html#JPREP.
> 
> Is it?

Apparently gone, or temporarily down?

mindprod’s server DNS address could not be found.

[toc] | [prev] | [next] | [standalone]

#34589 — Re: Sideremark II ( Re: Java Source of Meiyan Hash Scrambler?)

On 6/9/2016 9:07 AM, Eric Douglas wrote:
> On Thursday, June 9, 2016 at 8:59:50 AM UTC-4, Mike Amling wrote:
>>> the source code is posted at http://mindprod/products.html#JPREP.
>>
>> Is it?
> 
> Apparently gone, or temporarily down?
> 
> mindprod’s server DNS address could not be found.
> 

I was just on the site - works OK.  But the file is not on it.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#34600 — Re: Sideremark II ( Re: Java Source of Meiyan Hash Scrambler?)

On Thu, 9 Jun 2016 06:07:50 -0700 (PDT), Eric Douglas
<e.d.programmer@gmail.com> wrote:

>On Thursday, June 9, 2016 at 8:59:50 AM UTC-4, Mike Amling wrote:
>> > the source code is posted at http://mindprod/products.html#JPREP.
>> 
>> Is it?
>
>Apparently gone, or temporarily down?
>
>mindprod’s server DNS address could not be found.

it has been Pinging mindprod.com [65.110.21.43]
for years.

[toc] | [prev] | [next] | [standalone]

#34603 — Re: Sideremark II ( Re: Java Source of Meiyan Hash Scrambler?)

On 6/11/16 1:17 AM, Roedy Green wrote:
> On Thu, 9 Jun 2016 06:07:50 -0700 (PDT), Eric Douglas
> <e.d.programmer@gmail.com> wrote:
>
>> On Thursday, June 9, 2016 at 8:59:50 AM UTC-4, Mike Amling wrote:
>>>> the source code is posted at http://mindprod/products.html#JPREP.
>>>
>>> Is it?
>>
>> Apparently gone, or temporarily down?
>>
>> mindprod’s server DNS address could not be found.
>
> it has been Pinging mindprod.com [65.110.21.43]
> for years.
>

Try adding a .com to the domain: http://mindprod.com/products.html#JPREP.

[toc] | [prev] | [next] | [standalone]

#34611 — Re: Sideremark II ( Re: Java Source of Meiyan Hash Scrambler?)

On 6/11/16 3:17 AM, Roedy Green wrote:
> On Thu, 9 Jun 2016 06:07:50 -0700 (PDT), Eric Douglas
> <e.d.programmer@gmail.com> wrote:
>
>> On Thursday, June 9, 2016 at 8:59:50 AM UTC-4, Mike Amling wrote:
>>>> the source code is posted at http://mindprod/products.html#JPREP.
>>>
>>> Is it?
>>
>> Apparently gone, or temporarily down?
>>
>> mindprod’s server DNS address could not be found.
>
> it has been Pinging mindprod.com [65.110.21.43]
> for years.

Yes, but DNS regards "mindprod.com" and "mindprod" as different domains.

--Mike Amling
VGhhdCdzIHdoeSB5b3VyIFVSTCBhYm92ZSBkb2VzIG5vdCB3b3JrLg==

[toc] | [prev] | [next] | [standalone]

#34612 — Re: Sideremark II ( Re: Java Source of Meiyan Hash Scrambler?)

On 6/12/16 1:42 PM, Mike Amling wrote:
> On 6/11/16 3:17 AM, Roedy Green wrote:
>> On Thu, 9 Jun 2016 06:07:50 -0700 (PDT), Eric Douglas
>> <e.d.programmer@gmail.com> wrote:
>>
>>> On Thursday, June 9, 2016 at 8:59:50 AM UTC-4, Mike Amling wrote:
>>>>> the source code is posted at http://mindprod/products.html#JPREP.
>>>>
>>>> Is it?
>>>
>>> Apparently gone, or temporarily down?
>>>
>>> mindprod’s server DNS address could not be found.
>>
>> it has been Pinging mindprod.com [65.110.21.43]
>> for years.
>
> Yes, but DNS regards "mindprod.com" and "mindprod" as different domains.
>
> --Mike Amling
> VGhhdCdzIHdoeSB5b3VyIFVSTCBhYm92ZSBkb2VzIG5vdCB3b3JrLg==
>
And well it should, as they *are* different domains.

It's clear to me that "http://mindprod/" was a typo, and should have 
included the ".com".

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web