- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
static private Double getHashString(String string, Integer foundation){
Double hash = 0.0 ;
short [] charsToInteger = getCharArray(string);
double step = Double.MAX_VALUE / 256 - foundation;
for (int i = 0; i < charsToInteger.length ; i++ ){
hash += charsToInteger[i] * step;
step = step / 2 - 1;
}
return hash;
}
static private short [] getCharArray(String string){
char [] chars = string.toLowerCase().toCharArray();
short [] bytes = new short [chars.length];
for (int i = 0; i < chars.length; i++){
bytes [i] = (short) (chars[i] & 0x00FF);
//System.out.println("bytes [" + i + "] = " + bytes[i]);
}
return bytes;
}
Follow us!
> Решать эту задачу обычным способом желания не было
> Я решил попробовать реализовать внезапно возникшую идею представления строки в виде числа, то бишь сигнатуры. Причем надо было реализовать эту идею таким образом, чтобы число зависело от символов и их порядка, находящихся в строке. Т.е. сделать так, чтобы сортировка этих чисел была эквивалентна сортировке строк в алфавитном порядке по всем символам этих строк.
Это охуенно!
Зато в репозитории есть «HashStringService.java», «HashStringController.java» и «public interface HashStringJpaRepo extends JpaRepository <HashString, Long>».
Эквивалетно уже сразу не получится
P.S. Статью рекомендую прочитать, там просто эпического уровня анскилл.
Чтобы решить задачу, нам нужно биекционно отражить множество строк на множество чисел.
Можно представить себе что строка это N-ичное число , N -- количество букв в алфавите.
То есть задача сводится к переводу из N-ричной системы в двоичную (для представления в памяти ПК) или в десятичную (с учетом локали).
Если я верно помню, то для перевода в десятичную каждый разряд умножают на A в степени B, где A это основание числа (в случае ASCII видимо 127) а B -- номер разряда.
Так что задача решается элементарно, правда для сортировки достаточно больших строк может и не хватить сверхбыстрой памяти.
Упомянутый выше hash это по-определеию сюръекция, и значит в общем случае не подходит
Достаточно инъекционно, нет? Можно добавить шаг с умножением числа на два и получить невозможность вывода нечетного числа, но сохранить контракт.
Программист на «Лаже», даже «HelloWorld» не напишет без JPA, IoC и AbstractFactory.
Неудобные строки, это когда у тебя 2 строки килобайт по 10, одна из которых нормальная, а во второй могут быть дефект[ы] OCR, а это вполне себе нормальные строки.
ой бляджь просто идите нахуй
Верхняя часть его состоит из монитора (телевизора) а нижняя из процессора (оперативной памяти)
Я уже объяснил комптютер. Объясни теперь ты что нить
Внешний слой это просто честность (софт скиллы), а внутренний сонаправленность (мыслей программиста и потока байт)
Верхняя часть его состоит из головы (пищеприёмника), а нижняя из ягодиц (точки опоры).
Это небо, плачущее небо под ногами.
Это свиньи плещутся в канаве,
Рядом Чебуратор наблюдает за свиньями,
Что же будет с Родиной и с нами? ааа,
Рядом Чебуратор наблюдает за свиньями,
Что же будет с Родиной и с нами?
Осень, свиньи яблоки жрут,
Только пожрали - сразу насрут,
Только насрали - снова сожрут,
Вечный круговорот.
Что зима такое - это дубо,
Это с дуба помер Чебуратор,
Вместе с Чебуратором поймали дуба свиньи,
Весь колхоз и тётушка Аксинья, ааа,
Вместе с Чебуратором поймали дуба свиньи,
Весь колхоз и тётушка Аксинья.
Лето, осень, зима и весна,
Январь, февраль, март и апрель,
Вторник, среда, ёбаный в рот,
Вечный круговорот.
Это в хрюкни.
Сам знаешь, кому ответил
>Что из этого возможно получить в виде выгоды? Ну, конечно же возможно! Вообще, старший байт , если мы сортируем список строк (слов) , описываемых одной страницей UTF-8 ASCII кодов, можно отбросить.
> Он является лишь маркером для выяснения страны происхождения данных строк.
Теперь мы знаем как отличать дешевые китайские подделки char.
Пхахаха. Дальше можно быдло не читать.
>@SpringBootTest
>@ComponentScan("com.epam.brest")
>@EntityScan("com.epam.brest")
>@Transactional
>@EnableJpaRepositories
Зачем? Зачем?
А вот спринг МВЦ
https://github.com/Helgi-cell/HashStringAlphabetical/blob/main/src/main/java/com/epam/brest/hashstring/controller/HashStringController.java
зы: он троллит, конечно
https://github.com/Helgi-cell/HashStringAlphabetical/blob/main/src/main/java/com/epam/brest/hashstring/jparepositories/HashStringJpaRepo.java
Додик знает, что любое приложение состоит из
* веб контроллера
* базы данных
ну и если тебе надо хеллоу ворлд написать -- он и пишет туда JPA, Spring MVC и прочий Spring.
Ну и конечно сервис ради DependencyInjeciton:
https://github.com/Helgi-cell/HashStringAlphabetical/blob/main/src/main/java/com/epam/brest/hashstring/service/HashStringService.java
Гологубчик, перелогиниться забыл?
Я кстати, только что по путинскому мосту проехал.
https://avatars.githubusercontent.com/u/71282399
Хоумворк.
https://github.com/Helgi-cell/HomeWork11October
https://github.com/Helgi-cell/HomeWork11October/blob/main/src/main/java/DataModules/PriceShipping.java
Там вот этих пиздушных геттеров, спрингов и JPA ещё нет, не научили ещё погромировать.
https://github.com/Helgi-cell/SteelJob/blob/main/src/steelworks/MyInterfaceHat.java
Статические массивы в интерфейсе, очень мило
Ну есть же картинка известная, типа нуб
Мидл
Сеньйор
...
А как появились ``public BigDecimal getPriceLargeMore()`` так сразу стала какая-то хуйня там про строки
зы: хотя я бы наверное не рискнул пользоваться водосточным коленом, в расчете которого учавствовал дабл
Не-не-не. Это слишком просто.
Эволюция Июнь, Мыдл, Синьор там всё должно только усложняться.
The Evolution of a Haskell Programmer.html
ГЦ-блядь никогда не думает, где лежит объект: она просто пишет new, и течет.
С++ блядь конечно думает: лежит ли объект у меня на стеке, или в векторе? Или может на стеке, а в векторе ссылка? Или я его мувнул в вектор, и больше не могу им пользоваться? А может, я его туда скопировал (что долго)?
Для джаваёба все эти вопросы не существенны.
И вот жаваёб пришел в Rust, где всё тоже самое, что и в плюсах (ну только ничего по умолчанию не копируется а мувается, и еще ссылку надо явно задавать).
У ГЦбляди пухнет маленький мозг, и ГЦ блядь начинает хуярить всё в кучу с RC (atomic он для передачи между тредами) а если что-то не компилируется (ибо всё мувается по умолчанию и оно мувнулось) то тупо клонирует
В итоге получает говнецо похлеще джавы, и скоро начнет ныть, что нифига это чото не быстро.
Ну да.
Йажа она конечно тупая, но хотя бы реордеринг в OoO будет.
А тут атомики наделают фенсов и вообще перепитушня страшная.
ЗЫ, там растухи рекомендуют Rc.
Unlike Rc<T>, Arc<T> uses atomic operations for its reference counting. This means that it is thread-safe. The disadvantage is that atomic operations are more expensive than ordinary memory accesses. If you are not sharing reference-counted allocations between threads, consider using Rc<T> for lower overhead.
Чем не зашло?
В рустне есть:
* Box это некоторый аналог юника
* Rc это шарик, как ты понимаешь. Но шарик не потокобезопасный (потому что ты не можешь с двух потоков крутить счетчик) и потому его нельзя между тредами.
* Arc атомарный шарик, который можно между тредами (там трейт специальный реализуется, позволяющий между потоками копировать)
Если ты будешь всё хранить в куче и со всем работать через Arc то будет малость не так перформансно, как могло бы быть